There is a vast difference between working on well defined projects and creating a product for the end user. We all understand this, but this gap is often underestimated when we work on a developing a new product. But even if it is executed by seasoned team, a 2x delay is pretty common. Here is a take on how we can understand this trend and use it towards a faster development of a better product.
It is said that development of such products follows the 90-90-20 rule. That is, 90% of the work is completed in 90% of the time. The remaining 10% takes another 90%. And finally, 100% of the work is completed in 20% of the time. If you have worked on a product, you can easily identify with this. Let's understand this in some more detail.
The First 90%
A product is never completely defined. It is ahead of the market and has very hazy requirements. The requirements are in terms of the problem that we want to solve, rather than how we want the code to behave. This translation is usually hazy and often misunderstood down the communication chain.
Because of this, as a team starts working diligently, following the schedule, and documented requirements, it takes a long time to understand that there we have a huge gap in the requirements identified and the real requirements of the product. This usually happens when we have something working, something tangible is available to us, to play with and get a first hand feel of what the product would be.
The Second 90%
At this point, the team is shocked with the understanding that what remains is not just 10%, but we have a lot more in the backlog. If the leaders are strong and capable, if they are empowered by a capable team, they can absorb this shock and move on.
At this point, momentum of the team is pretty high, and so is the frustration. Naturally, the blame game begins. But everyone is in a hurry to complete. Since the revelation is slow, everyone still believes that it is only a little more effort. Often, the leaders are tempted to utilize this state of the team to push them harder, working extra hours - to somehow push it fast.
But this leads to fatigue and shortcuts - naturally reducing the quality of code developed. Eventually, we get a product where there is no gap between the understanding of requirements for BA and the developers. The developers feel they have implemented the requirements. But, due to the way we worked over the last few months, the code is infested with errors.
The Final 20%
This is the final test for the team. It can be the golden period in the development. By this time, people are tired of blaming each other, and they begin to gel again. Everyone in the team understands the requirements perfectly well. Developers have mastered the technology by now.
If the leaders can make sure the momentum is not lost, in this phase, the team ends up rewriting a major part of the code. This time, super fast and with very low defect density. And so much is done in the last moment - if it were not for that last moment, nothing would ever get done
And lo! We get a wonderful product ready to hit the market.
Opportunities
It may be demotivating to see how most products are delayed. But if you think over it, you would be surprised that most of the code was developed only in the last 20% of the time. So in reality, we did the job much faster than the original estimate. Rest of the time was only spent in getting the team to that state of cohesion, and expertise!
When working on a product, one should make conscious attempts on reducing the first two phases. And more important, getting to the third phase as fast as possible. How do we do this? Let us check out some important parts of the process
Respect the POC
Any product development begins with a POC. But this is often a reduced phase of the project. People are in a hurry to get started, so a very minimal POC is accepted as enough to get started. Often the POC is only a way to spend time till we have gathered the team required to start implementation.
Always remember that Earlier you start implementation, more time you take to complete it. Give due respect to the early phase of the product development. Make sure you really prove the concept in the POC.
Discard the POC
Another mistake is that the code developed for POC is used to as a seed for the main application code. Remember that the POC was only a trial. The first attempt is always fragile. The developers had learnt a lot of lessons while implementing that, and those lessons are not incorporated in the POC implementation. If these errors go into the foundation of the application, it is bound to collapse.
Very often the POC is implemented by the elite few - who do not continue far in the real implementation phase. Use this opportunity to pass on their knowledge and understanding to the team that will work on the real implementation. This hardens the core components of the application and drastically reduces the defect density.
No Shortcuts
Never ever take shortcuts when developing a product. It is one thing when you work on a small project of four months (and wash off your hands after that). But when working on a product that has to last, you cannot afford any shortcuts.
This is easier said. But you have to be ruthless about it. Any shortcut is going to be vey costly in the long run. There is no doubt about it.
Enrich the Team
While reducing the first two phases, we have to put in additional effort to make sure we get to the third phase as fast as possible. It is important to enrich the team with the skill and understanding. Just watching tutorial videos is not enough. They have to go deeper.
Something that always worked for me is a small hackathon on the same technology. Let them work on a meaningful application in a short time span. Let them make all the mistakes on that application. This will naturally harden their skills and help them do a better job on the real product.
Kill the Blame
I have seen some leads and managers who deliberately keep the team members crossed - so that they can continue to rule. Such cheap leadership will be costly for the product. Make every attempt to make sure that the team does not get into that mode. Take additional effort to make sure they gel well.
Don't lose Heart
And finally, remember that a product cannot be made without failures. The motivation level of the team depends upon the leader. If the leader is seen directionless or lacking motivation - at any time - the same will echo in the team - very loudly.
So expect the problems, and make sure you have a solution, before it becomes a hurdle.