Overlapping: Designing Fast Development Process
Even though software development primarily involve technologists, one can strongly argue that development is an art in itself. In the last couple of decades software development process has evolved drastically to provide value to the customers at a very faster rate. Most organizations, who wanted to survive in the market, have successfully migrated from traditional waterfalls, tollgates, stage gates, and checkpoints to agile development methodologies.
For many the journey was smooth and others it was a huge cultural change as a result it was pretty painful. On a retrospective, even I wonder sometime, what were we thinking when we were collecting all the requirements in one cycle, followed by design in another cycle, then development and then testing and so on. But then I comfort myself by saying "well, we did have a rotary phone just couple of decades ago that looked far different than my iPhone". We evolved!!
I started of this article, by saying that software development is an art because I strongly believe in that concept. The development process may be different (Scrum, Kanban, XP, Crystal, FDD, DSDM etc.) but unless we understand the art of breaking down the mountain into rocks into small rocks into pebbles we cannot get our product to market quicker. This requires an artistic mind (like a Maestro) to orchestrate this entire list of pebbles in an orderly fashion to build a monument.
Overlapping is one concept I have most effectively used in many of my projects to either mitigate risks or to increase the momentum of the project. Recently I came across a similar topic from a book "Developing Products in Half the Time" and thought it would be valuable to share some tidbits from it.
Overlapping - working on multiple activities simultaneously - is a basic tool of rapid product development. This is easily said than done because every project have unique challenges and depending on the size of project it gets hard to coordinate multiple activities simultaneously. However, it can be done and the key is to breakdown your project goals into logical units and to cautiously manage the dependencies and interfaces. Team communications is also key here!
Overlapping requires a cultural change and it is a paradigm shift - this mindset helps the developers to pick any item (rightly prioritized) from the backlog and it also brings agility to the team. Additionally, it can also be used to mitigate risks proactively by doing some ground work (prototypes) in earlier phases before actual work begins. This also helps to develop, build and ship minimum viable features to end customers pretty fast.
Credits: Developing Products in Half the Time by Preston G. Smith and Donald G. Reinertsen
Overlapping work style demands multitasking, which comes at a cost. http://mass-plc.com/blog/419/multitasking-vs-task-switching
While I am too a firm believer in overlapping work style, putting it into practise might become a challenge. Needless to say it not only needs right people with right mindset, but also organizational culture to have tolerance towards resource time.
Good insights Antro, I closely relate to the concepts in your article as I am responsible for the delivery of a lot of our projects with several customers, the only way for me to manage and continue to deliver is by using an overlapping approach. I definitely agree it takes a different culture, mindset, discipline and right people around you to make sure this approach works in the right way. If not, I have seen many companies take on heavy technical depth and then spend several years in unraveling it.