When starting a new software project, the number of unknowns is huge. We have learned the hard way that one of the most costly problems in software development is getting our requirements wrong, and by using Agile, MVP, and similar techniques, we have improved this somewhat in that at least we know think we know what our customer wants and are willing to change/improve/redefine this as we go a along.
But in the way, we still have to solve technical problems that are not known to us…
And what is the best way to counter this problems? by building prototypes.
Let’s say you are now developing a new messaging application that lets users share videos in real-time, with the option to embed annotations in those videos (just popped up in my head… is there an app already out there that does this? Do you think it is a good idea?). Anyway, leaving the detailed user experience problems (which are many), this app also has a number of technical challenges that can’t be neglected. For example, we are doing streaming editing of video… this needs a lot of computer power. I actually don’t really know if this is possible. But as developers, we take the challenge and say “no problem, just decode the video on the fly, add a new layer, encode it again, and voila!”. Yea right. You will probably start writing this code and get into so many rabbit holes that you will never get out of them.
So what I propose is that for features that have a high level of risk (i.e. there are too many unknowns, technology is new, having no knowledge of technology, etc), the first sprint of development be used to create a prototype that proves the technical feasibility of the feature. This prototype should be clearly bound to test ONLY the technical problems that we think will block us during development, without doing anything else that is not related to this technical problem.
Once the prototype is done, we can go on to develop the feature in the regular Agile method. What we have earned here is a new level of certainty not only in the feasibility of the feature, but also in how much time the feature will take to develop, how many people can work on the feature in parallel (many times constrained by the technology being used). This in turn gives a sense of security to the team that lets them feel that they are in charge and reduces the chance that things will start slipping from sprint to sprint, reducing team confidence, agility and performance.
| Reference: | Prototype Driven Development from our JCG partner Arieh Bibliowicz at the Vainolo’s Blog blog. |
I agree with you and so does the Agile. Those are called spikes in Agile. This isn’t a new concept.
http://scaledagileframework.com/spikes/
http://agiledictionary.com/209/spike/
Also could you please do a grammar check before posting your article. I have found that the quality of the writing has deteriorated on this site.