The Agile Suit
Differences between Agile and Waterfall
Theoretically, it shouldn't make a difference which process you use, so long as you stick to it, are good at it, and get everything right along the way.
I'll summarise how both of these models look:
Waterfall - you say what you want. I work it all out in excruciating detail, cost it up. You pay. By the end I'm under a lot of pressure to deliver. I do my best to deliver and then you get something. By the end it gets a bit tricky as you might not have understood what you wanted, or I might have run out of time and will, therefore, have to work hard to attempt to meet the schedule.
Agile - you say what you want me to do in the next couple of weeks. I make something coherent which is a couple of weeks' worth of features and then show them to you. You fail to grasp that this is both complete and incomplete, but have a go at scheduling the next few weeks. We continue until you consider the work totally complete.
In fact in the best case scenario when everyone understands what's going on, both should deliver the same results in about the same time. Human nature suggests that misunderstandings creep into the equation and so the iterative approach of agile seems to discourage those misunderstandings. Equally, it seems that some of the implementers in the waterfall model might be using crystal balls to guess what they have to make, and so may make a load of incomplete stuff along the way, overengineering, and misunderstanding how it should all connect up... integrating at the end, things then don't hook up and all hell breaks loose. Agile is supposed to fix that with constant integration and iterative end-to-end development.
The arrogant assumption of Agile is that it doesn't introduce problems of its own into the process. While iterative is good and keeping things working is also good (and I will never debate the usefulness of automated tests, which should be put to good use in all methodologies), Agile has some project planning issues. In fact to call them issues would be a bit like calling the elephant man, "a little bit plain".
In the world of waterfall, when your bosses commit you to a fixed scope, fixed resource project, by the end you deliver something approximate and pray it's good enough. If you learn from your mistakes, you eventually should be able to deliver something that's practically the same as the requirements and useful in the extreme... provided you know your customer and do a good job of the engineering.
In the world of Agile when the product you deliver is, again, too simplistic, the response is to deny that the customer had any right to expect anything to solve their actual problem. Instead, they should be thankful that they've got another increment and shouldn't be fussing about the big picture. What's all that about? Never mind the cost. We just add the next most valuabl feature - it's your fault if we can't add something large enough to meet the next block requirement... and so on.
If buying a suit worked like this, people would go naked.
The Agile Suit
Day 1 - get measured. Agree to see what a paper cutout of the suit might look like.
Day 3 - see paper cutout. Discuss material. Are told that the material is a refinement. Perhaps see a paper 3D mockup of the suit?
Day 5 - see 3D mockup - it doesn't fit and is too flimsy to go on. Argue with tailor about not cutting any cloth and are told that cutting cloth would be a chunk, not a slice.
Day 7 - the tailor made a couple of pockets - stitching them neatly and attaching them to the paper mockup.
Day 9 - the tailor added a belt and a carnation.
Day 11 - the tailor shows you some samples of cloth and explains that you could have a sleeve.
Day 13 - a sleeve has been made and stiched into the paper suit
Day 47 - the suit is now made of cloth for the most part, but is too baggy. It has no lining. The pockets are working, but can only be accessed with the suit off. The tailor argues that the suit has been usable since Day 3, but not under all circumstances.
Day 59 - the tailor goes out of business, the suit is never worn.
Theoretically, it shouldn't make a difference which process you use, so long as you stick to it, are good at it, and get everything right along the way.
I'll summarise how both of these models look:
Waterfall - you say what you want. I work it all out in excruciating detail, cost it up. You pay. By the end I'm under a lot of pressure to deliver. I do my best to deliver and then you get something. By the end it gets a bit tricky as you might not have understood what you wanted, or I might have run out of time and will, therefore, have to work hard to attempt to meet the schedule.
Agile - you say what you want me to do in the next couple of weeks. I make something coherent which is a couple of weeks' worth of features and then show them to you. You fail to grasp that this is both complete and incomplete, but have a go at scheduling the next few weeks. We continue until you consider the work totally complete.
In fact in the best case scenario when everyone understands what's going on, both should deliver the same results in about the same time. Human nature suggests that misunderstandings creep into the equation and so the iterative approach of agile seems to discourage those misunderstandings. Equally, it seems that some of the implementers in the waterfall model might be using crystal balls to guess what they have to make, and so may make a load of incomplete stuff along the way, overengineering, and misunderstanding how it should all connect up... integrating at the end, things then don't hook up and all hell breaks loose. Agile is supposed to fix that with constant integration and iterative end-to-end development.
The arrogant assumption of Agile is that it doesn't introduce problems of its own into the process. While iterative is good and keeping things working is also good (and I will never debate the usefulness of automated tests, which should be put to good use in all methodologies), Agile has some project planning issues. In fact to call them issues would be a bit like calling the elephant man, "a little bit plain".
In the world of waterfall, when your bosses commit you to a fixed scope, fixed resource project, by the end you deliver something approximate and pray it's good enough. If you learn from your mistakes, you eventually should be able to deliver something that's practically the same as the requirements and useful in the extreme... provided you know your customer and do a good job of the engineering.
In the world of Agile when the product you deliver is, again, too simplistic, the response is to deny that the customer had any right to expect anything to solve their actual problem. Instead, they should be thankful that they've got another increment and shouldn't be fussing about the big picture. What's all that about? Never mind the cost. We just add the next most valuabl feature - it's your fault if we can't add something large enough to meet the next block requirement... and so on.
If buying a suit worked like this, people would go naked.
The Agile Suit
Day 1 - get measured. Agree to see what a paper cutout of the suit might look like.
Day 3 - see paper cutout. Discuss material. Are told that the material is a refinement. Perhaps see a paper 3D mockup of the suit?
Day 5 - see 3D mockup - it doesn't fit and is too flimsy to go on. Argue with tailor about not cutting any cloth and are told that cutting cloth would be a chunk, not a slice.
Day 7 - the tailor made a couple of pockets - stitching them neatly and attaching them to the paper mockup.
Day 9 - the tailor added a belt and a carnation.
Day 11 - the tailor shows you some samples of cloth and explains that you could have a sleeve.
Day 13 - a sleeve has been made and stiched into the paper suit
Day 47 - the suit is now made of cloth for the most part, but is too baggy. It has no lining. The pockets are working, but can only be accessed with the suit off. The tailor argues that the suit has been usable since Day 3, but not under all circumstances.
Day 59 - the tailor goes out of business, the suit is never worn.
0 Comments:
Post a Comment
<< Home