More than a year ago, a group of Scrum Masters gathered at the first 'Scrum Caretakers' meetup to discuss what had changed in the Scrum Guide. The main change being that the Scrum Values had been added to the framework. This was a long-anticipated change as Scrum has become so mainstream that we were seeing a lot of 'cargo cult' uses of Scrum - where all the artifacts, roles and events were followed without seeming to move towards Agile Software Development. The meetings resonated with me because I noticed that many of us were running into more things that the Scrum framework does not fill in. Following meetups went deeper into those gaps, developing the thinking and understanding of those attending and directly influencing how we use Scrum here at Mirabeau.
There is clearly a shared need around how to get Scrum actually running, living in alignment with its values: commited to team goals, the courage to adapt, the openness to inspect, the focus to get the most valuable things 'done' and with the respect needed to allow everyone to maximally contribute.
I need to give a very special mention here to Gunther Verheyen - he is truly the father of this movement - both leading and facilitating what is to come. He is the original 'Scrum Caretaker', whatever the product turns out to be: a community of practice, an open source plugin for Scrum or just a thought in some Scrum Masters' toolboxes.
Scrum has gaps?
Yes, it does and that is exactly the way we like it:
lightweight and simple. Not lots of meetings, documents and pre-defined processes: just three roles, three artifacts and five events. Thin slices, short increments - it is the perfect tool for making complex products in just the same way as two teams, a ball and goalposts are all you need for a game of football. You don't understand football by reading the rulebook - you go out and play it.
Why then do you so often still see:
heavy, cumbersome and not going anywhere? Unable to leave old structures and processes behind? Thinking, designing and making occuring in separate phases? Management of people instead of leadership that delights customers and teams alike?
Why change the perfect tool?
Just because Scrum is fantastic does not mean that it can be used for every job. The idea of a Scrum Studio is still in development and may remain so forever. Common themes seem to be:
- Scrum does not tell you how to implement it, resulting in those nice 'gaps' quickly being filled with bureaucracy and fluff from the surroundings.
- Only the Product Owner seems to represent the 'business' side of the work, all the thinking with stakeholders is not described. If Agile is about customer collaboration, shouldn't we also say things about how to collaborate? Too often do we see Product Owners pushing fully defined requirements into backlogs, or designs that are perfect pictures but not usable by customers.
- Scrum focusses on effectively making things but says very little about why you are making it. Designing and specifically understanding and influencing your customers requires a lot more brainstorming and diverging and converging than the Scrum Guide's 'transparency, inspect and adapt' would suggest. Empiricism is not just doing the experiment - you need to hypothesise, experiment, review results and draw conclusions too.
That last point: end-to-end production, is something that is of special interest to Mirabeau. We're in the business of finding out the right thing, building it right and keeping it right. Here's an example of how we do that in a multi-functional Scrum team:
Scrum Studio @Mirabeau
We called ourselves 'Studio 800': anyone with less than 800k to spend would still be able to afford all the goodness of Scrum. We would keep to the values of 'Individuals and Interactions, Working Software, Customer Collaboration and Responding to Change' whilst keeping our Scrumming as lightweight as possible.
This would allow us to help our customers leverage our very diverse specialists whilst also profiting from our practiced teamwork.
Our studio had to adapt to our value streams quite a lot. We had a few clients who had very large backlogs and ambitious projects, a client who wanted to move from one platform to the other and one who had made functional and technical specifications as well as pixel-perfect designs of what they wanted.
The Scope Illusion
An important part of the conversation with our clients is about 'what will I be getting for my money?'. However, if the proposition is that we will be discovering that together, how are we able to make any promises about what will be made?
The, perhaps disappointing, answer is that we really don't know what we are going to end up delivering for our clients and their customers. Even if we throw a whole group of experts at the problem - our 'secret sauce' remains how well those experts collaborate both with each other, our clients and how well it fits their customers.
That is not to say that all of our clients immediatly understood that their Product Backlog was a series of experiments and not just a list of requirements. In fact, even some of our own salespeople still have some trouble understanding that this is collaborative experience and not a concrete product. Being honest about this from the start helps but there is always a gap between seeing and understanding something.
The key seems to be to bring insights about the product as early as possible. Whereas traditional product creation requires design and planning up front, that has the risk that you will find out that your user/customer hates it after a lot of work has been done.
To support end-to-end delivery we tried out or invented a number of practices:
- User story mapping using a customer journey as underlay.
- Design Studio: a workshop adapted from architecture, aimed at running through the design thinking process in a few hours to a few days to reach a testable prototype.
- Swarming: basically a 'sprint in a day' - useful for things that need close collaboration with the client or are highly uncertain and need continuous reprioritising like complex bugs.
- ScrumBan: Scrum and KanBan with continuous planning instead of sprint planning.
These are all 'keepers', we also tried a number of other things but found that they resulted in unintended results. We saw the emergence of sub-teams that did not feel responsible for end results or far too much preparation that resulted in no working product over many sprints. We had too many stakeholders involved with a team without a single Product Owner to prioritize work.
The key is to keep experimenting with how to work and accepting poor results as a part of learning.
We came to a number of learnings, by no means an exhaustive list:
*collaboration and team work is key - work is only 'done' when someone is using product - everyone: client, stakeholders, developers, designers and facilitators need to have that understanding, must be able to contribute and will thus feel responsible for the outcome. That may involve developers doing design work and designers participating in architecture meetings. Time isn't money.
*release as early as possible and try to increase the speed at which you release. Nothing brings knowledge of your product except people using it - so get it out there and then closely, honestly and empathetically take in the feedback and adapt to that.
*strategize, don't govern. Regard things like your architecture, design, measurement plan, customer journey and even your vision as 'living agreements' - they are never done. You will get a lot more out of collaborating on these things than on 'pushing' fixed plans. Perfectionism is a very serious flaw - no great product was ever made in one go and from a pre-defined plan. Understanding and contributing to why things get made makes teams fly.