Five Recommendations For Successful Agile Lean Digital Product Development

Five Recommendations For Successful Agile Lean Digital Product Development

Written by Ian Greentree, Consulting Partner at MMT Digital


Product management teams across all industries are under increasing pressure to understand their customers’ needs and provide the best possible experience. With customers and teams becoming increasingly global and distributed, experiences need to span “Clicks and Bricks”.  

Companies that tame emerging technologies and implement disciplined lean product management practices give themselves the best possible chance to win market share or even create new markets. During the past eight years, MMT Digital has worked with large global companies like BP, Vodafone and CompareTheMarket.

We’ve worked with high performing Agile teams and teams that are at the start of their journey. However, regardless of maturity, they all share common challenges:

  • Getting to market before their competition
  • Creating a product that customers love
  • Prioritising the development of product features
  • Enabling delivery when teams and customers are spread across the world

Here are our five recommendations to help steer large distributed product management teams whilst maximising value to customers and the company:

#1 – Value Value Value

Ensure everyone on your team understands the value of the product from the vision and business case and all the way through the product backlog to individual user stories. Conduct value stream mapping to best direct investment and measure return on investment (ROI) using hypothesis statements in your epics and features. You should be able to audit value in every user story, which should track back to a step in your value stream. This will ensure you only build what is necessary. Protect value and ROI by releasing it quickly in regular small iterations and avoid large “big bang” releases.

#2 – Decentralise decisions 

Your delivery process will always be inefficient if you rely on one or two people to make decisions regarding most aspects of your product. This is exacerbated if your teams are distributed across many locations. Waiting for a decision will take valuable time. However, accountability is always a challenge especially in large companies but let go and trust your development teams.

You can set decision boundaries in your backlog. Have your Chief Product Owner (CPO) own features and set guidelines through value hypothesis and acceptance criteria. Your teams can then deliver against them and create their own backlog of user stories which they own and make decisions against. Likewise, with experience design, ensure UX wireframes are managed at the feature level with the CPO also owning the UI style guide, but your development teams will have their own UI design capacity to make UI decisions for the feature the team is delivering. Same for technical architecture, your development teams will make implementation decisions within guidelines set in the solution design. This allows story development to flow through the sprint with the demo at the end of the sprint providing feedback and alignment to the Chief Product Owner, UX lead and solution architect. But remember, decisions should be escalated when they may impact other features or teams.

#3 – Develop robust deployment pipelines 

Ensure your developers can write, deploy and test code with minimal (if any) reliance on other teams. Working software, the true measurement of progress, enables product owners to provide timely feedback to developers and make essential adjustments to product design. Through a DevOps culture with robust deployment pipelines, ensure software is built and deployed within minutes with automated test results visible for immediate quality feedback. Establish a code branching strategy that allows teams to deploy value independently and where possible automate builds through continuous integration.

Learn how we empowered Vodafone UK’s egineering teams to deliver digital experiences in record speed.

#4 – Keep teams small

As well as reducing the total number of team members on your program, it is essential to keep development teams between 5-7 members. You will find that less people will deliver more and that throwing people at a problem will have the opposite intended effect, exacerbated when working as a distributed team. The more people that are in your development teams, there more inefficiencies they’ll create. Strive for T-shaped developers with multiple skills and avoid making individuals responsible for specific technologies.

The latter will quickly create bottlenecks. You will engender a culture of “Build it, Run it, Own it” by having small development teams, decentralising decisions and creating automated deployments. This is your path to high performing teams that are engaged and proud of the product. The outcome of this is a product that is loved by your customers.

#5 – Establish a Community of Practice for Product  

Ensure your product management team remains aligned to the vision and value stream. Develop standards for product design and backlog refinement to avoid any misalignment from team members. If you take anything away from this article, then let it be this; A concise backlog will dramatically reduce waste. A user story that seems clear to the product owner may not be clear to a developer, may not be clear to a designer, may not be clear to a tester.

Any misalignment in expectations from any party will create inefficiencies, some more catastrophic than others with days or weeks of work being wrong. You could have the slickest development practices in the world but if your backlog is not clear, then you won’t deliver a quality product to your customers quicker than your competitor. Therefore, define standards for your backlog items and govern these through regular backlog reviews and a Definition of Ready (a set of standards that all stories meet prior to development). More importantly, document these standards in a wiki that is visible to all parties and allow them to contribute to these standards.

Never forget, the product management team needs to improve just as much as development teams during retrospectives.

Have Your Say: