Abstract: Transitioning from projects to products made perfect sense for my client. Much of the business was digital and their websites / online-services would not be “completing” or going away soon. Development was deliberately continuous, and executives embraced this as both inevitable and desirable. However, just because it was the logical thing to do, it did not mean it was easy.
Maybe if we did not have over 100 inflight projects executing simultaneously, we could have picked an easier starting time? Maybe if there were not so many dependencies between teams, work would have been easier to untangle? Maybe if they were not in the midst of transitioning to microservices and new hosting technology, the technology challenges would have been easier to resolve?
Most organizations considering the transition from projects to products have similar challenges. By definition, “transitioning” means doing things mid-process; otherwise it would be “starting fresh with product development” – and where’s the fun in that?
This experience report recounts the story and transformation from slick PowerPoint slides to people problems and development difficulties. We did survive the journey and arrived in the land of continuous digital delivery, but we took some detours and lost some paint along the way. If you are considering the switch from projects to product development, maybe we can help you avoid some potholes and speedbumps along the road. Being forewarned is to be forearmed, but each journey is different, and as they say, your mileage will vary.
Lessons Learned from Your Experience: - An initial lesson learned was that there is never a good time to switch from projects to products. The fact that you need a more product-focussed model indicates your applications and services are continuously evolving. Re-staffing teams for both development and sustainment will have to happen during some development effort, which forces the team to storm and norm again while deadlines still loom. Also, some of today’s technology trends, such as switching to a microservice architecture, can create new cross-team dependencies if you are not careful. For us, a newly formed microservice environment provisioning team became a bottleneck for many teams.
- Finally, there is always a learning process and communication exercises required when rolling out changes to how we plan, approve and fund new work. Switching from annual budget cycles for projects to ongoing micro-funding based on results required a lot of education and change management. Even though people agree, smile and nod in meetings they often return to their desks and continue doing things as before. So we burned all their old desks – not really, we worked with them to take them through the new processes. It worked fine, but we underestimated the effort and frequency required to achieve lasting change.
Attachments:
