For some time my focus has been on global product strategy and transforming a global enterprise to evolve a learn fast culture combining the principles offered by the communities of Lean Startup, Agile and Lean. I’ve be fortunate to be part of a team at Pearson who are centrally positioned to work with product teams across the globe and together we have harnessed our efforts around a global Product Lifecycle. The product lifecycle framework offers extensible practices and governance, coaching, training and a community which shares learnings and experiences to help others innovate and develop products. I hope this post is the first of many exploring this topic.
Product teams have their own unique combinations of skills and experiences which result in similarities and differences. This might be in the form of language, frameworks, constraints, market conditions, training, roles, product types and more. Despite the differences, at a high level, all products start with an idea. From that moment the idea is captured and moved through it’s stage in a lifecycle. Traditionally these took the form of BRUF (Big Requirements Up Front) and this was followed by big budgets and long delivery times. Those days are behind us in most cases as we have come to realise better ways of launching, testing, producing, delivering and supporting products focused around customer needs.
Combining Lean, Lean Startup And Agile into a product lifecycle offers significant benefits to learn quickly if you’re building the right thing, reducing waste, improving the opportunity to meet customer needs and adapt quickly to change and meet these needs or respond to competition. During a products life and it’s stage in it’s own lifecycle, there are key questions and behaviours to focus on which change over time.
Recently I undertook a course with Scott Ambler which brought in these questions and observations within the context of Disciplined Agile Delivery (DAD). DAD covered the Inception, Construction and Transition phase of releasing a product to market. At first this concerned me somewhat as this gave me the impression of BRUF. However further insight revealed this was referring to specific delivery models that require it and was re-enforced by continuous delivery and lean startup which might have no inception lengthy transition period. Almost all projects at their first stage have an inception period and Scott re-enforced keeping this light and focused, following lean principles. I also learned that from the inception phase there was an emphasis on Lean thinking and principles and didn’t prescribe a singular delivery lifecycle. DAD expected the delivery practices to evolve over time from Inception, Construction to Transition to just Construction and Transition through rapid continuous delivery models. Scott covered four product delivery lifecycles including :
- The Exploratory lifecycle (Lean Startup)
- Basic Agile/DAD lifecycle : Extending Scrum (Scrum)
- Advanced Lean/DAD Lifecycle (Lean/Kanban)
- Continuous Delivery DAD Lifecycle (Lean/Kanban)
We have been working on practices within the Global Product Lifecycle team at Pearson which looks into the most appropriate practices during different stages of product investment and it’s position in the product lifecycle. However although key questions are asked at stages of a product in it’s lifecycle, delivery methodologies are not prescribed. They do evolve though as described in DAD ranging from Lean Startup to Continuous Delivery. Teams can choose which are the most appropriate for them accordingly wherever they are depending on their needs, constraints and capabilities. However awareness of different methodologies is key for the right decision is made by the product teams. To simplify this, I have tried visualising this in the following diagram using empirical evidence from digital product teams.
Why would you consider different Agile/Lean methodologies over time?
A product has different needs over time where different methodologies can offer key benefits. Building a product too early can be wasteful and by the same token, waiting too long for releases in a live environment can be wasteful. This obviously depends upon your product, domain, team, organisation and many other factors. There is no hard rule of what should or shouldn’t be used. However awareness of where you are with you product and the changing needs and environment can help select and evolve practices accordingly. In reference to the diagram above I’ve tried to explain at a high level why certain frameworks might be better suited and considered at different stages of a products life.
Sitting above all the agile and lean frameworks are lean principles. These core principles offer benefits for products and organisations from their very idea until their end. Such principles will help reduce waste, focus on value and evolve the system to improve overtime accordingly.
Lean Startup ( DAD : Exploratory Lifecycle)
Lean Startup is best placed at the beginning of a products life. These practices offer key insights to help you take your idea and break this into small, learning focused hypotheses and experiments to test assumptions about your product idea. Such practices help you whether your product idea solves a customer problem, discovers and tests and discover potential business models and get to the point of product market fit. These practices can continue as long as you are adding features to your product and can work well with all Agile methodologies such as Scrum, Kanban etc. Lean Startup practices will not only help you define your success criteria upfront, but will allow you to structure feedback continuously to inform your growth model.
Is well suited to product teams with incremental feature additions and structured learning. Being iteration based, Scrum can support the practices of Lean Startup, ongoing development, change, team development and improvements of products. Through iterations, teams can measure the outcomes of each delivery (sprint) and asses change against expected success criteria. Scrum offers significant benefits for teams beyond the explanation of this post. In a product lifecycle I would commonly advocate this as a practice after you have discovered a viable business model through to product maturity where the team is mainly BAU.
Scrumban/Kanban – (DAD : Advanced Lean)
Depending on a teams maturity with its practices, Lean and Kanban practices can be used as I have described Scrum above and beyond into BAU if you are looking for quicker response to customer needs. I enjoy the offerings of both Scrum and Kanban and am not going to specifically say one should be used over the other. Often this is where I observe Scrum teams evolving the practices into what is more explicit in Kanban, where teams can release during sprints if they so choose or having no sprints and continuous flow as in Kanban and there might be practices such as limited WIP. The main point here for a team to consider whether it has mature enough practices so that can include BAU and additional product features, but they have the capability to release sooner than iterations end.
Continuous Delivery – (DAD : The Continuous Delivery DAD Lifecycle)
This usually requires mature agile practices which allows teams to take on work and release on a continuous basis. You could technically use such practices at the beginning. I placed this in the mid to latter stages of a products lifecycle as usually it takes teams some time to advance into these practices. I don’t just mean development capabilities, but for the whole business to support this way of working. When a product is in the marketplace having the capability to ship on a very frequent basis is advantageous in most cases. This capability combined with your success criteria and growth model is a desirable behaviour for most organisations. However you must have an environment where you can release often for the true potential to be used here.
If you have feedback on the above, please comment below. I really enjoy learning from others and sharing experiences.