Dan Bunea

After seeing that there are very many people that find it hard to see how agile handles adaptive planning, letting the customer not know from the beginning what he wants, I wanted to develop a mini sample to show these concepts in practice.

A small agile process practice sample

Let’s consider that we have a new client who wants a new software product to manage and track his sales and customers. He wants the system to go live in 2 months. We meet and establish what is required, then plan to meet the deadline.

After the first meetings we come up with the following feature list, that he thinks he wants, that is afterwards estimated by us:

1. Client management (3p)


2. Product management (3p)


3. Sales leads management (4p)


4. Sales reports (3p)


5. Client activity management (3p)


6. User management (2p)


7. Sales workflow (3p)

Now together with the customer, we make the first plan, dividing the work in two iterations:

Iteration #1: 10 p

1. Client management (3p)


2. Product management (3p)


3. Sales leads management (4p)

Iteration #2: 11p

1. Sales reports (3p)


2. Client activity management (3p)


3. User management (2p)


4. Sales workflow (3p)

After we have a plan to deliver the 21 points features in 2 months, we start working, by starting on the first iteration, at the end of which we deliver features 1,2 and 3.

We now show the customer the first 3 features implemented, but he suddenly realizes that he needs more, then what was planned for the release. We start by adding what he wants to the list of features, which now becomes, after each of the new features are being estimated.

1. Client management (3p)


2. Product management (3p)


3. Sales leads management (4p)


4. Sales reports (3p)


5. Client activity management (3p)


6. User management (2p)


7. Sales workflow (3p)


8. Activity calendar (3p)


9. Forecast reports (3p)


10. Document templates and document merging (3p)

With the client we realize we cannot deliver all in the 2 months term, but we decide that we make a delivery after the two months and we plan another delivery after that will include other features that will make the system more compete. The new plan looks like:

Release #1: 2 months
Iteration #1: 10p

1. Client management (3p)


2. Product management (3p)


3. Sales leads management (4p)

Iteration #2: 11p

1. Sales reports (3p)


2. Client activity management (3p)


3. User management (2p)


4. Forecast reports (3p)

Release #2
Iteration #3: 9p

1. Sales workflow (3p)


2. Activity calendar (3p)


3. Document templates and document merging (3p)

As you can see, the customer considered that is more important to have the forecast reports in the first delivery so he moved the forecast report into the second iteration and the sales workflow to the 3rd iteration.

After the second iteration is over, we have the features 1-7 finished, in 2 1 month iterations, delivering on term what the customer wanted, and deploying it to be used by its end users.

At the beginning of the 3rd iteration, the customer realizes that he wants a few more things, and he would like to have the next delivery of the complete system, in another two months so he can fit his budget. He adds a few new features, having the following list now:

1. Client management (3p)


2. Product management (3p)


3. Sales leads management (4p)


4. Sales reports (3p)


5. Client activity management (3p)


6. User management (2p)


7. Sales workflow (3p)


8. Activity calendar (3p)


9. Forecast reports (3p)


10. Document templates and document merging (3p)


11. Contact communication management (3p)


12. Microsoft Outlook integration (2p)

The plan now becomes:

Release #1: 2 months
Iteration #1: 10p

1. Client management (3p)


2. Product management (3p)


3. Sales leads management (4p)

Iteration #2: 11p

1. Sales reports (3p)


2. Client activity management (3p)


3. User management (2p)


4. Forecast reports (3p)

Release #2
Iteration #3: 9p

1. Sales workflow (3p)


2. Activity calendar (3p)


3. Document templates and document merging (3p)

Iteration #4: 5p

1. Contact communication management (3p)


2. Microsoft outlook integration (2p)

After finishing and showing to the client the resulting product having now 10 features out of 12 implemented, he realizes that there is one more feature he’d like to have, and that can be implemented in the last iteration: sales processes. The list of feature becomes:

1. Client management (3p)


2. Product management (3p)


3. Sales leads management (4p)


4. Sales reports (3p)


5. Client activity management (3p)


6. User management (2p)


7. Sales workflow (3p)


8. Activity calendar (3p)


9. Forecast reports (3p)


10. Document templates and document merging (3p)


11. Contact communication management (3p)


12. Microsoft Outlook integration (2p)


13. Sales Processes (5p)

And the updated plan:

Release #1: 2 months
Iteration #1: 10 p

1. Client management (3p)


2. Product management (3p)


3. Sales leads management (4p)

Iteration #2: 11p

1. Sales reports (3p)


2. Client activity management (3p)


3. User management (2p)


4. Forecast reports (3p)

Release #2
Iteration #3 – 9p

1. Sales workflow (3p)


2. Activity calendar (3p)


3. Document templates and document merging (3p)

Iteration #4 – 10p

1. Contact communication management (3p)


2. Microsoft outlook integration (2p)


3. Sales processes (5p)

At the beginning of the 4th iteration the client says he’d like one more feature that is estimated by the team to be of 3 points. Adding that feature would mean not meeting the second release target, so after balancing the options he decides to drop it.

After the 4th iteration the final product is delivered. The sample above cannot show by any means how any project can be developed, but it shows the agile process at work, iteration by iteration, planning, adapting and delivering incrementally a product to the end customer.

The evolutive process of gathering the client requirements and a burn down chart, showing iteration by iteration the number of remaining features to be implemented would be like:



So after this very small sample do you think it could be useful for you?

When it comes to automated tests the first impression everyone (including myself) thinks that that would certainly increase the amount of time a certain feature is developed in. However as I started to practice TDD, Test First Programming, increasing the number of tests I came to the conclusion that automated tests actually allow you and the team to develop faster then without.

Move faster ahead in development

A simple comparison of programming vs walking on a rope. When walking on a rope, at a height, with no safety net, walking is much harder , much slower, as the risk is higher. Only very experienced people can walk fast. When having the safety net below, the rist of falling suddenly doesn’t really concern you that much. If you fall, you just go back and try again. You do not jeopardize your life.

With programming, the bigger the code base gets, the hardest is to move further, to change all code, being very afraid, that you could mess it up really good. If you have automated tests, they are your safety net, allowing you to see if one mistake you did affects the system, and you have to roll it back just like falling off the rope makes you go back to the start. A little time is lost, but not the system, you do not need weeks to restore it. The fact that you can see the mistakes you do very fast, makes you a lot braver, having the courage to change a lot, adapt, improve, refactor a lot, then when you don't know what you're doing. The safety net, composed of tests gives you that very fast feedback that something is broken. These tests are also called change detectors. When you do a change, the tests will detect very soon if it breaks something.

Faster development by automating the process

In a recent project, we had a business process on a web application that required the user to go, like in a wizard, trough 9 screens to be able to ship an order. When we were developing it, we had to go 9 pages, filling 9 pages of data to see if the order can or cannot be shipped. We had a lot of times, the order being rejected by reasons that we forgot to fill in some field. This process of filling in all the fields until screen 9 took usually 2-3 minutes, so after 2-3 minutes to see an Exception is not really nice because it just means you have to take another 2-3 minutes to refill and hope this time it will be ok. After a few attempts, I realized this was not the way to go I said what about we automate the whole filling process, , and being a web application we used Selenium (http://selenium.thoughtworks.com) a great functional testing tool for web applications, which did the whole 2-3 minutes manual process in under 4 seconds. Now instead of starting the first page, we ran the test each time until we got the process of shipping right, with all the validations. It took 15 minutes to write the test but it probably spared us of a lot more manual testing. And when it worked, it could be retested whenever we felt like it, in 6 seconds. It was added to the test suite and we made sure that it always succeeded, so we knew all the time that even with our 'big new changes' it still worked.

Minimizing debugging time and cost

Usually people have the tendency to think that by adding automated tests the development time increases. They say that if you have something to implement in 4 hours and doing the tests would take 2 hours, you have just lost 2 hour writing the tests. Coming back with our feet on the ground we can soon realize, that that thinking is superficial as it presumes that the code done in the 4 hours of development is bug free. That is bug free and will stay like that even if the system around it changes, gets bigger etc. The sad truth is that most code is not bug free for the first time, and a lot of time is lost debugging it. In many cases the time to debug is bigger then the time it was developed in and this time usually increases as the time goes. The biggest problem is maybe that usually debugging time is not measurable or it is hard to predict how much time it will take. So 4h+??? = ???

If the bug is discovered by the client, solving it is usually not paid, so it's cost just doubles or grows even more. Many times you end up with a negative balance when saying 4h developing=10$ then fixing the bug 4h=10$. The company ends up with 10-10=0$. And this is a good case.

Automated tests, with a good coverage of possibilities, will reduce even eliminate the debug time and if they are kept in a test suite that is run very frequently will make sure they remain bug free. In this case you use 6h, but you're very sure you've done it right.

Automated tests help you get things right the first time, costing less

A similar sample was with my wife. She went to buy paint for our doors. She bought two cans, one with 0.85 the other with 1.55. When we started painting we quickly realized that the 0.85 paint , needed to be put twice on each door, so is actually costed double: 1.7. Now if she bought two cans of 1.55 we would have paid less money and less effort. The very same goes with automated tests. They seem to cost more then developing without them but they usually end up costing less, as you get the things right the first time and not after the deployment, when you fix the bugs from your own pocket.

I hope the 3 reasons above gave you an idea, why I think developing being backed up by automated tests actually help you develop faster, then developing without them .