Last week, our agile coach Tom met one of his heroes. Not Superman, nor Batman, but Kent Beck. The legendary American software engineer is one of the 17 who signed the agile manifesto and was the keynote speaker at XP2018. This five day conference in Porto started on Extreme Programming but has evolved to a wide area of agile topics. 300 people from all continents showed up to discuss experiences. The theme this year was make, inspect, adapt. Sounds familiar, not?
Tom presented our way of working and the challenges we have by hosting multiple products in our teams. This is written down in an experience report, which you can read here. Below you can find a digest. At the end of the post, you can read some more learnings from the conference!
Multi-products teams in an agency context: combining design thinking, lean and agile
Combining design thinking, agile and lean
Before building a product, we want to make sure that we are building the right thing. To this end we apply design thinking. With this method, a repeated pattern of diverging and converging is applied to 3 steps: first, the user needs are understood and defined. When the needs are clear, different solutions are explored. Finally, the solution decided upon is worked out in more detail, in mockups or a prototype. We try to validate this prototype with users as soon as possible, to incorporate valuable feedback as early as possible. All these steps happen within the cross-functional team. We’ve recently organized a meetup on this topic.
Once it’s clear what solution to build, the team starts developing the product in an agile way, following the well-known principles. Going agile, we make sure we are building the thing right. Currently, all teams adopt the Scrum methodology with 2-week sprints. Even though the process of discovering what to build and then building it may seem like 2 distinct steps, they are interwoven and happen continuously, where the output from the discovery phase is input for the delivery phase. This is what is known as dual track agile.
As the products we build have grown in complexity and are becoming business critical, the lean approach came into play, with a focus on MVP thinking, validated learning and setting goals to check whether the product is indeed living up to its expectations. When we start a new product, that’s the first thing we do together with the client.
Multi-product teams: solutions to the challenges
To accommodate multiple products in our teams, we have 3 challenges: the agile roles are not well suited for this situation, teams have to shift focus, and finally, as not all products are in the same phase, there is room for activities benefiting the company and the team.
Our teams do not have a dedicated scrum master or product owner. Instead, each team has a team lead and a product manager. That’s because we believe the product owner should be at the client side, close to all the stakeholders in his or her organisation. Our team lead and product manager are supporting this product owner. Besides that, the team lead is accountable for the team and it’s delivery, guards the agile processes and is a people manager. In short, they are close to a superhero for the team. The product manager on the other hand is a broader expert in translating needs to solutions that can be built. He oversees the discovery phase, maintains the backlog and creates the product roadmap, together with the product owner at the client side.
Having multiple products in our teams is possible because the teams have a dedicated technology focus. This makes it possible for all team members to review code or assist, even if they are not full time cooperating on the specific product. Furthermore, we make sure that the sprint meetings are tailored to a specific client and as efficient as possible.
Finally, each team is allowed to spend time on ITP projects, such as our big ideas or the competence working, and on team specific activities and products. This allows us to always do valuable things, even if there is less work on some products in the team.
In the experience report referenced above, you can read more on how we deal with budget and how we check and measure the team’s performance.
Learnings from the conference
- Each product phase (S-curve: explore, scale & mature) requires its proper strategy, also with respect to software engineering. Kent Beck came to this conclusion while consulting at Facebook
- Agile on its own is not enough to build great products: besides in our experience report, this was a key point in ‘It’s Not About the Stand Up: Why Agile Isn’t Working for You’ a talk by Kristine Berry, Transformation Leader at IBM. She emphasised that you need product management (to understand the market) and design thinking (to get a good user experience) as well
- SAFe as a scaling framework is not perceived that well in the community (there was an open space session on ‘Is SAFe the new waterfall?’), but there are people doing their best effort with it. See for example this experience report ‘What SAFe doesn’t tell you’
- The Dunning-Kruger effect, how people over- or under evaluate their own experience (also applicable to agile)
- The XP conference is a great mix of technical topics (you can have an all day workshop on Test Driven Development), experiences and workshops to master new techniques: I learned a lot on conflict resolution and liberating structures as a facilitation technique
- All this is topped with an active open space & on point social events