It was a nice problem to have: the Scrum team was performing well, but stuck on a plateau.
At each retro they’d consider what had been working well and what hadn’t, and take some actions to address the problems - but nothing moved the needle very far.
Then the Scrum Master (Chris) tried something new, with dramatic results. You could say it was a 14-fold increase in Agility, in that they went from getting customer/stakeholder feedback once a fortnight to at least 7 times per week. Customers and sales people were delighted to be getting software that really met their needs much more quickly, and relationships improved all around.
How did that happen?
Well, Chris tried out a new type of retrospective, based on the “Solution Focused Brief Coaching” approach. It goes like this:
- What are our strengths? What’s been working well in the last Sprint? What makes us a strong team in general?
- What would the perfect Agile team look like to you? (“the kind of team that books and articles would be written about as a great example of a self-organising, continuously improving team.”)
- On a scale of 0-10, where 10 is that perfection and 0 is the worst it could be, where are we now?
- What would one step up the scale look like?
- What small steps could we take to move in this direction?
They rated themselves at a 7 - and were keen to improve on that.
When Chris asked “what would an 8 look like?”, one of the things that emerged was a desire to be closer to the customer – to make more decisions based on the customer feedback (rather than developer intuition, ease of implementation, or any of the other considerations we normally use).
The team decided to move away from “pure” Scrum, to a process that was still very much Agile, somewhat Kanban, and definitely tailored to their needs.
They decided on a weekly cadence, each week focused on solving a specific customer problem. Day 1 was about “what could we do?” – looking at options, assessing them and checking them with customers/stakeholders. Days 2-5 were about developing and delivering. This enabled them to elicit and respond to feedback more quickly, and have more iterations on any given topic - typically looking like:
- Week 1 - Solve x problem
- Week 2 - Solve y problem (while feedback is gathered on the solution to x)
- Week 3 - Refine and amend x now we have more information (y gets feedback)
Built into this cycle were 3 formal check-in points – but the team didn’t stop with that. Because it was their idea to be so much more focused on the customer, they were motivated to get even more input from them. Whenever they had a significant decision to make, they would seek out customer/stakeholder input: “Should it be A or B?” “I don’t know, let’s ask Jenny downstairs” would be a typical dialogue – followed by actually going and asking Jenny!
What difference did this make?
With a 14x tighter feedback cycle, the team really was tackling the most important problem every week. Everyone starting see quick changes, and they were producing a product based much more direcly on the “Voice of the Customer.” That led to many more benefits:
- Sales teams loved it - they were able to show customer things they mentioned just one week before.
- Customers noticed that their feedback and views were being listened to - and they started engaging more with the business
- There was a large boost to morale within the development team, they could see that the work they were doing was having an impact. (This had been quite a sore spot for the team....)
- Internal stakeholders also become more engaged, and relationships improved across departments. For example, the culture between the development team and the sales department had been somewhat ""them and us" - and instead it quickly became a much more flowing dialogue. Instead of of viewing the development team as a bunch of coding geeks who talk another language, the sales team started to see them as valuable and helpful partners. The developers had been seeing the sales team as "just wanting commission" - and instead they quickly realised that the sales people really did care about customers. The result was a much more collaborative relationship, much better for all concerned.
How long did all this take?
The process was implemented very quickly, and impacts were felt within 3 weeks. By week 5, the relationships had been built to a point that the developers would happily go and speak to the stakeholders.
What’s the moral of the story?
Firstly: When a team is already performing well, don’t just focus on resolving problems – that can only take you so far. Instead, invite them to build on their strengths, think of how they’d really like things to be, and move step-by-step in that direction.
Secondly: if you want a team to really take on Agile Principle and Practices, invite them to consider how they’d like the team to be, what the perfect Agile team would look like. When they’ve done the thinking themselves, they’ve got real ownership and thoroughly engage.
About the Authors
Roy Marriott is an Agile Leadership Coach, with a speciality in Solutions Focused Brief Coaching. He regularly leads workshops at Agile conferences on topics like “Generating Change without Generating Resistance”, Coaches leaders at organisations like ARM, Display Link and VW, and trains ICF-certified coaching skills for SolutionsAcademy. Outside of work you might find him mountain biking, taking photographs, or just enjoying the beauty of nature. You can connect with him directly by email, or come to one of his meetup events.