Extreme Programming: The Pyramid
A client approaches your company to build a pyramid, the product team translates his vision into requirements, you ask bunch of questions, things like how tall will the pyramid be? Do you expect it to grow? At which rate?… etc. You get all kinds of fuzzy answers (if you are a software engineer you will know what I mean with fuzzy answers). However you manage to get your head into it at the end, you do your estimates, you pick the team and start building. With the current team velocity (3 bricks a day) you will need 12 days to finish the pyramid that is 8 bricks tall.
You start by laying down the first raw of bricks, which will take about 2.6 days, then you lay down the second raw which will take you 2.3 days, you lay down the 3rd raw which will take you another 2 days. Now it is day 8 of the project lifetime and you have 4 bricks tall base.
People walk by and don’t see a pyramid. The client is still patient. But he is having a second thought, 8 bricks tall might be too much, 5 would be enough.
By day 9 the pyramid is 5 bricks tall, and the client is now talking to the management about changes.These changes are costly, cause it will require removing bricks from the base. We may get to an agreement and the project continues, or we may disagree and the project comes to a complete halt. The community will be left with some structure that no one knows what it is. Coming generations will tell a story about the pyramid that was supposed to be here which cost the municipality $1MM and was never finished.
Now let’s see how someone with extreme programming principles in mind would approach this project. On day one we will create the smallest ever pyramid possible using 3 bricks.
Right on day 2 we will have a pyramid that is 3 bricks tall.
This approach helped the team to test their design principles quickly, and show the client a prototype of the final thing. On day 3 The client comes back with comments, changes can be introduced easily, we only used 6 bricks and spent 2 days of the lifetime of the project.
We introduce these changes and we move on. On day 5 we will have a pyramid that is 5 bricks tall. People walk by, they can see a pyramid, the client is happy, he knows how the money is being spent, he sees progress. And at any moment if the client is short on money, or he decides that 5 bricks tall is enough, we can easily pull the plug, and we will have a pyramid in place.
Few differences between the two approaches:
1- In the second approach, except for few days, the team would leave the project site on daily basis and there is a complete pyramid behind, a smaller one, but it’s still a complete pyramid, while first team never left a pyramid behind until the last day of the project.
2- The second team reached a pyramid 5 bricks tall in day 5 of the project lifetime. The same would take the first team 10 days. The second team were able to test their designs hypothesis and get feedback from the client much faster.
3- The second team minimized waste, and was able to cope with change.
What are these extreme programming principles that we applied here:
Extreme Programming believes in ‘it is better to do a simple thing today and pay a little more tomorrow to change it’ than ‘to do a more complicated thing today that may never be used anyway’.
1- Do the simplest thing that could possibly work
2- Take small simple steps to your goal and mitigate failures as they happen.
3- Never implement a feature you do not need now i.e. the ‘You Aren’t Going to Need It’ (YAGNI) principle.
Every iteration commitment is taken seriously by delivering a working software.
The software is delivered early to the customer and a feedback is taken so that necessary changes can be made if needed. Concrete feedback about the current state of the system is priceless. The value of the feedback is a continuously running system that delivers information about itself in a reliable way.
In any situation, big changes made all at once just do not work. Any problem is solved with a series of the smallest change that makes a difference.
In Extreme Programming, Incremental Change is applied in many ways.
• The design changes a little at a time.
• The plan changes a little at a time.
• The team changes a little at a time.
Through out my career as a software engineer and as an engineering manager, I personally slowed down couple of projects using bottom up methodology. And I’ve witnessed projects with tens of millions of dollars in budget being done bottom up, resulted in nothing or something that no one needed or wanted, and eventually shutdown to become a story that we tell and make jokes about.
“But I was blind and now I can see” John 9:25
Since I read Extreme Programming Explained by Kent Beck, I led myself projects that went extremely successful, only because we decided to leave a working software -that people can actually use- at the end of every day -when possible- and definitely at the end of every sprint.