Learning over Delivery
SCRUM & LEAN UX | Episode 6
Many organisations consider learning to be an activity to ‘do in your own time’ or you ‘should have done in school’. Many corporate cultures don’t consider learning as ‘being productive’ and can only be done ‘when there is time’.
Managing learning and delivery
To value development or delivery over learning is a mindset that is not just native to Waterfall. It also unfortunately thrives in the modern Agile industry where there is a continuous push for ever faster delivery / shorter time to market.
With the onset of “Agile Delivery Managers” as an attempt to rebrand the Scrum Master, the modern Agile industry seeks to stress Delivery even more. Although the specification of the role includes coaching and motivating the team to experiment, this will be trumped by responsibilities such as ‘providing visibility into delivery targets, commitments and progress and controlling operational /reputational risk’.
“In the Agile Delivery Lead role, you’ll ensure your teams’ delivery success”
“The Agile Delivery Lead will optimize team productivity”
— Capital One’s Agile Delivery Lead role description [emphasis added]
This role not only emphasises ‘ensuring delivery’ and ‘optimizing productivity’ but also ‘controlling operational /reputational risk’ and ‘ensuring success’. One could ask oneself if that makes the environment ‘safe to fail’ and if these create the best conditions for quality and creativity to thrive; all being ESSENTIAL to creating great user experiences.
So let it be clear, with Lean UX and Scrum we are uncovering better ways to create great user experiences, through which we have come to value:
learning over delivery
Learning is paramount. It’s a first class citizen. It’s not a prerogative. Learning happens continuously and it is part of the Lean UX Cycle: build, measure, learn.
Naturally learning in Lean UX and Scrum occurs through frequent delivery. Valuing learning over delivery doesn’t exempt learning through delivery. Learning through delivery is what incremental development is all about and is what makes a team adaptable, flexible, agile. Empiricism! YEAH!
Although there is value to the question: ‘How do you learn from your delivery’, also aks yourself:
How do you deliver learning?
In the previous episode we covered why research should be performed each and every Sprint. Doing research is a learning activity. That doesn’t however cover the full spectrum of learning. One could do all the research, but still fail to learn from it and adapt.
Curiosity drives the motivation to find answers and discover new ways. When we dare to journey off the beaten track we can seek new amazing things, find hidden treasures, discover a lost paradise… but… we can also get lost in the woods pretty quickly. Taking risks is a part of exploration. To discover and unlock value we need to have the courage to take risks. But risk can be mitigated. Performing research will help us understand where we are and in what direction we are going, if we are (close to) delivering value or if it is better to track back a little. In complex environments, it can help us sense and probe dangers ahead. One of the best ways to learn fast and validate assumptions quickly is by running small controlled experiments.
Running experiments builds evidence for decisions quickly.
Learning experiments are generally performed (if at all) at the very beginning of a project. They are rarely performed throughout development and even more rarely performed by developers themselves. This is not so with Lean UX. Both Lean UX and Scrum requires Continuous Learning to take place. This occurs in a regular cadence and requires customer involvement.
Dare your team members to go on small expeditions each Sprint as a means to spark their curiosity.
Making Sense of the Research
Learning in Lean UX is about making sense of the research, developing a shared understanding of it and constructing or adapting approaches from it and then validating assumptions made from it. In Scrum this revolves around performing inspections and creating increments. One of the approaches a team can take is by constructing Minimal Viable Products.
MVPs are often misunderstood and it can have different meanings in different contexts, so it requires a little explanation as to how Lean UX actually defines an MVP. An MVP may be considered a small controlled experiment that could answer one of the following questions (from the Lean UX Canvas):
- What is the most important thing we need to learn first? #7
- What’s the least amount of work we need to do to learn the most valuable/important thing? #8
It’s about running an experiment to learn wether our riskiest assumption is true or false.
Paper Prototypes, Feature Fakes and A/B tests are common techniques applied to learn early if an assumption is viable.
Hey, why not try at least one ‘Mythbuster experiment’ each Sprint?
Aks your team what activities they can do together that enables them to learn and adapt from the research it performs.
- What will enable them to get the most value of the research they perform?
- What skills would team members like to develop that further empower the team to create better experiences or to be of better service to customers, how will they go about it?
- Consider aligning on what learning activities to perform as part of the Improvement Plan for the next Sprint during the Retrospective or Sprint Planning.
- Consider embedding learning into the daily routine by answering ‘What will we learn today?’ during a Daily Scrum.
- Consider sharing what the team has learned and how they applied their learnings during the Sprint Review with key stakeholders.
So build together, learn together; and help each other along the way. This is how to continuously improve, discover hidden treasures, reduce dependencies and risk, increase transparency, and improve everyone’s experience.
How Lean UX supports the Product Owner in making better decisions
SCRUM & LEAN UX | Episode 7
Thanks Willem-Jan Ageling for reviewing this episode!