Developers are the customers - from time to time. They are the customers for product definition/specification team that is preparing technical specification documents. It doesn't really matter whether you work in an agile or non-agile environment - I'm sure you have some technical documentation and the main goal of it is to answer developers' questions on technical issues (e.g. how to configure some components to work with others, how to map fields from GUI forms to XML message, etc.) It also helps test or QA team to prepare acceptance tests and to verify whether what developers implemented is what was specified (I know it stinks a bit the waterfall but stay tuned - I will say something about agile documentation soon).
I would suggest you reading an article on TAGRI (They Aren't Gonna Read It) by Scott W. Ambler - it's really great. And in my post I'm going to give you real-life example from what I experienced regarding documentation. I will share with you my opinions of what kind of documentation sucks and what documents are really cool and useful (btw. my dream documentation is the one with which I'm able to find accurate information of my interest quickly and be able to put this information into my head in less than 10 minutes - the picture you see is a total contradiction of my dream - it's a waterfall process).
One of the core XP practices is having a Customer Team Member. It means that development teams have access to the newest information from the customer's side and they know about all changes in the requirements very quickly. Having on-site customer (or customer proxy for commercial products with lots of potential customers) ensures that requests change informally, the process becomes flexible, and saves the cost of formal overhead.
In this post I would like to take another look at this practice. I would like to share with you my thoughts why having a Customer Team Member can help the development team win together with their customer. And I would like to take a "social" view on this practice.
No matter who you are, where you live and what your job is you have to make decisions. Some decisions are easier, some more difficult (e.g. which way do you want to go on the crossroad with traffic lights from the picture?). But why making decisions is hard? When you make a decision, how do you know it is the right one? What information (if any) you have to posses to make the right decision?
This problem can be referred as "Defer Commitment" principle. Very briefly it tells you to make the decision in the last possible moment when you have enough information to be sure you are going in the right direction. It doesn't tell to you to procrastinate - NOT AT ALL! It's a wrong thinking. It only tells you that you have to wait and collect the data and as soon as you have enough information, make the decision.
In this eleven minute tutorial I'm presenting TDD with mocking technique using JUnit 4.x and EasyMock library. This is more advanced example of Test Driven Development - video tutorial on basics can be downloaded from here: Test Driven Development in practice.
Source code for this tutorial can be downloaded here (you can find also Eclipse project files in this bundle, so it's easy to import the project directly to your IDE - NetBeans users have to create a new project and add relevant classpath changes). Note that external.jar was built with Java 6 and thus you have to use at least JDK version 6 to be able to compile and run the example.
Last week I had a great fun and honour to interview Janusz Gorycki who is a partner and a team manager in an Agile Software Development company - Spartez. Janusz is also the author of the open-source screen capture and painting utility for Windows named Mazio.
In this interview I'm asking Janusz about how they founded their company and how agile movement helped them achieve success. I'm also asking how they see their agility, what problems they have and how they deal with them. Janusz also answers why you can be CMMI-compliant using agile methodologies and recommends steps by which you can start applying Agile practices in your company.
Is this interview about yet another agile company? Not really - Spartez is an extraordinary company composed of ordinary engineers who were not afraid of making their dreams come true. Their determination, team work, a bit of luck and an extreme agile spirit helped them be and work together and become successful. This is a real-life example how cross-functional team, where each member is an expert in some areas, is able to deliver any software to any customer. And how do I know this? I used to be a part of this team at Intel and know this team as well as each member pretty well, however I'm not affiliated with them anymore in any way.
If you are interested in getting to know how they started, what and how they do now, this article is for you. Maybe you will follow their dreams and ideas - I think it's worth.
In this tutorial I'm presenting Selenium IDE - a tool for recording and replaying functional tests of web based applications. I'm showing how to record a simple test, test for Ajax-enabled application and how to replay such tests in Firefox web browser. I'm not showing how to start Selenium tests from Continuous Integration server in this tutorial - this is a subject for separate post.
I was just reading an excellent book by Josh Bloch, namely "Effective Java, Second Edition" and I was on the optimization subject when it happened. It was funny coincidence but I think it was just a sign for me to write this post.
It doesn't relate to the Agility in any way but it relates to the quality of software so it should be definitely published here. And it all started very innocently - from publishing blog post with the solution to some annoying problem.
In this post I will tell you how easily you can fall into really dangerous and ugly development problems starting optimizing your software too early. I hope you will like the story.
Lance Armstrong won seven consecutive Tour de France races between years 1999 and 2005. Every year there were 21 individual stages and Lance Armstrong won "only" 4 individual stages in 1999, 1 stage in 2000, 4 stages in 2001, 4 stages in 2002, 2 stages in 2003, 6 stages in 2004 and 2 stages in 2005.
As you can see Lance Armstrong was not focused on winning each stage (quite the opposite). He was focused on winning the whole Tour de France - yet he had to keep close to the head of the race. And when you take a look at time differences between him and the second cyclist in the final classification you will be amazed - they were close to couple of minutes (out of 90 hours of total time!) It means that he was focused on winning the whole race - not to be the best and outstanding cyclist (he was not - I know because I watched many of the stages these years).
Speaking with the lean language Lance Armstrong was Optimizing the Whole - and he succeeded seven times winning the most difficult and exhausting cycling race in the World.
"How much software will you deliver in the next Sprints/iterations?" - do you often hear such questions? I do. And this question is really valuable especially for the project/product sponsors. But not only management likes knowing how much software they will deliver in the upcoming Sprints. Everybody (including development team members) likes to know the answer for questions like: "Where we will be in three months from now?".
If you track your team's Velocity you are able to answer such questions somewhat accurately, which is great. I personally don't know better tool for answering presented questions than tracking development team's Velocity.
Let me now explain how you can compute how much software your team will deliver in the next Sprints basing on the current team's Velocity.
In this nine minute tutorial I'm presenting TDD way of developing software i.e. start from writing the test.
Many people often say that you should start from implementing at least interface and then start testing. In this tutorial I'm showing how easy it is to start writing unit test with nothing (not even an interface) i.e. only having the requirements. After couple of minutes I've got an interface, a working implementation and a full test suite.
This is what Test Driven Development is all about - software should be developed this way. Open this article to see the bigger player.
RSS feed