In the old days we had a factory floor where assembly line workers assemble the parts into a product which before has been designed by clever researchers wearing white lab coats. There is a thin line between experimentation and actually producing something
We often run into situations within organisations where the development department is adopting Scrum, enabling teams to conduct small experiments and test assumptions. However, elsewhere in the organization, separate teams have been doing this for years usually in an research and development departments. What we see is two worlds colliding and putting pressure on the entire organisation.
We often encounter the following difficulties:
- Decisions made within the prototype are not viable for the actual product due to limitations of the current platform, architecture or time constraints.
- ‘Hidden decisions’ within the prototype. Some choices are made by the R&D team in conjunction with the customer, these are however undocumented. They are bound to cause discussions.
- The R&D team is not bound to deadlines and can spend time to perfect the prototype before actually testing the assumptions made.
- The R&D team does not have the same quality standards as the Development team.
On the other hand in the Development Department, Scrum teams are enabled to continuously inspect and adapt on the outcome they produce. This transforms this department from assembly workers (producing that what has been created in the R&D department) to creative software developers, crafting high quality software with maximum added value.
This challenges the status quo of traditional organizations and puts pressure on established communication protocols, procedures and processes. Basically, the question arises, who is in charge of innovation? Where does Prototyping end and Productizing begin.
The answer is twofold, ideally you would like to have a team that is able to produce new feature in the current feature branch and leaves room to experiment with new products, services and features. Everybody in a team should be able to introduce new ideas and test their assumptions without any handover and clear quality guidelines. This drastically reduces cycle time from idea to product. If a new product or feature becomes so successful that it is impossible for a team to support this, a team will split up into two separate entities so knowledge, mindset, culture and quality focus is established and no handover is required.
Within a current organisational structure Rome cannot be built in one day. Some steps can be made, however, to move closer to aforementioned situation. When it is an improvement to an existing product, make the Development team responsible for the implementation. Create a hybrid team which consists of the development team and the R&D team. Make sure they are co-located to reduce communication overhead. The role of the R&D team is merely knowledge transfer. They are not allowed to be involved in the actual implementation of the product. This idea is illustrated in the figure below.
This will enable a step by step integration of R&D activities and product implementation into the Scrum team, and gradually move to an Agile organisation.
So when should we end prototyping and start productizing? In the end prototyping will be productizing.
This article was co-authored by Martijn Dehing
