I found my successful project was not entirely developed by the agile process, surprisingly it can go through a key step that reminds me the waterfall process, at least partially. Therefore I’d like to call it AgileFall. In this article I won’t go any detail into what is agile and what is waterfall.
What I want to propose here, or maybe my observation is that, a masterplan needs to be formulated which shouldn’t be anything to do with the agile process. A master plan is something you can rely on to start working.
Planning
The thing I think agile process fail to deliver in the end is that, everything can be negotiated and everything can be accomplished except the end product isn’t anything close to the master plan. And people are ok with it, because they think this is how we deal with the reality.
To me, developing a product isn’t about just living with the reality. Because I don’t want to be number #2 in anything, just kidding. It’s about living through at least one cycle of the product development while sticking with the plan. What does that mean? It means, you need to trust the plan, and do it one round, and afterwards you let people criticize the product or the plan, and then you do a revision if you accept these criticisms.
You might ask, isn’t that too weird? I can say in the current world, that is. But that happens to be my definition of planning a product. There’s no agile involved in this planning. The plan might require you a minute or a day or couple of month. You might have to prototype a bit to understand what you are really up to. You might have to find someone to answer couple of your questions. Whatever the effort is, no one can tell you the amount of the effort, you need to spend as much time as possible if you really love your work. You could relate this to being a detective, there’s no easy way out, and you might not be able to get out either.
What’s the difference between what’s discussed and the agile process? Nothing needs to be adjusted: the number of people who’s involved could be reduced to one people; and you are documenting your work progress without much intervention. To be honest, there’s not a process yet. This is only one step, except this step could take very long therefore it might cost you lots of resources. There’s no negotiation. You can talk to yourself, but you don’t have to listen to another person if you don’t want to.
Negotiation
The outcome of the above step is a plan, and I wouldn’t call it a draft. Because even thought it’s not final. It’s the current plan, so I would rather call it a master piece, at least at this stage of the development.
Now comes to the second step, we deliver this plan to the engineer. What would happen? 50/50, the engineer team would come back with a counter offer. The team agrees with some and disagrees with some. The argument is normally about the cost and technicality.
Isn’t here the start of the agile process? Not really. There’s a negotiation happening right away between the planner and the maker. But you need to think of this as a proposal review. Whoever reviews the plan as a bundle, one piece, not thousands of broken pieces with some pieces here and some pieces there. The negotiation also could take forever, back and forth between two parties, with the goal that both parties can finally agree to meet in the middle.
This is not a process either, instead it’s a negotiation step. If parties can’t agree upon before the deadline, the plan wouldn’t get chance to come to surface. There’s nothing agile about it, basically two parties can talk as much as they want or refuse to talk to each other.
Signing
Yes, finally upon great pressure, both parties agree upon a plan. It’s a contract with emails exchanged to agree terms. The engineer team is reassured that they can at least finish 90% of it without making them look bad. The planner is satisfied that 90% of his plan actually might get chance to be alive in the future. This is the moment of the potential start of the work.
If you think about the above steps, this might reminds you the business side of the development a bit. No wonder no one uses Agile in that world, because either it signs or falls apart, there won’t be any agile about it. Agile is meaningless if the outcome isn’t fruitful. Therefore no one would really put that much thoughts into defining a mini goal along the way. There’s no more goal to be defined except about signing the god damn plan.
Summary
Developing a product isn’t about following an agile process. Instead it’s about signing the contract of delivering a plan. If you don’t have a plan, you would fail delivering the plan? But you never gave me a plan! Exactly, you need to get a plan, agree with the plan, and then hopefully stick with the plan. If you don’t, people would replace it with an agile process.
