The slides used for this session are available to download from here.
We have spent years building up software teams aligned to frameworks like scrum and kanban so we can tackle multiple delivery streams across multiple products, shipping code at least every 2 weeks. Teams are long lived, self-organising and cross functional. They write code in a safe environment, are aware of customers' needs, able to use the latest tech and fire nerf guns at will.
But in 2015 we realised that something didn't feel quite right, particularly when we wanted to launch a new product, service or feature with lots of unknowns, at its riskiest into a new market. When we assigned a scrum team to it (because having focused sprints with clear goals suits new product development), many of the team were left idle as research was required, and lots of conceptual work.
We grumbled for a while that as a cross functional team they should embrace the opportunity to gain new skills. After several sprints it just wasn't motivating the teams, so we used dual track scrum so that team members focused on the conceptual side could feed their learnings to those focused on delivery.
For some teams this worked, but for others still it seemed a little inefficient. We then worked with a consultancy to understand the problem a little deeper. We were made aware of the disciplined entrepreneurship approach, and as we were already aware of lean startups (due to having internal startups) this sat quite naturally with our mindset.
We now had a way to assess the problem and whether a long lived team, a dual track team or a small entrepreneurial team was required. This new type of team often started with just a product owner and perhaps UX/research, and built up the skills it needed based on what it learnt about the problem it was trying to solve.
We had a really positive mix of results: some quickly transitioned back into more typical scrum teams, some used platforms like Wordpress to interact with the marketplace in a low risk, low cost way; and others (using lean and value proposition canvases) just stopped - the risk and cost was deemed too high at that current time.
Teams were starting to think not only with a customer focus, but also with a business stakeholder focus.
I will share examples of the ideas we put to market and those we stopped. Being able to stop an idea is so empowering - it's about no longer being judged by delivery of features but being able to make decisions about the value of continuing to invest in solving a particular problem.
Our use of the balanced scorecard has also encouraged teams to have a balanced view of customer value, business value, internal process efficiency and how we learn and develop as individuals and teams. I will talk a little about how the balanced scorecard helps with decision making, measurement and motivation.
Having this approach to solving problems makes us more flexible and increases throughput of idea validation. It has eased the frustration that things weren't moving quickly enough.
Having spent 14 years in digital teams in a number of different roles both on the business and IT sides, David is now Head of Agile Practice at Reed Online, leading the lean and agile coaching team.
He runs the meetup Agile in Covent Garden and co-hosts London Lean Coffee.