November 2020 was the launch of the Scrum Guide update. It seems like only yesterday but was over 3 months ago. Over those three months, I have talked a number of times about the changes, using the update as an excuse to talk about Scrum. As Ken and Jeff highlighted at the launch event,, Scrum has not changed, but the changes provide an opportunity to reconnect with the intention of Scrum.
I must admit that I’ve enjoyed the opportunity and have learned many things during this journey. I wanted, however, to share one theme that was both surprising and not at the same time. The title I have given this observation is ‘Scrum is about value not work’.
Ok - so let’s provide some context.
The Scrum Guide 2020 really made a lot of progress in positioning Scrum as a lightweight framework that connects empowered teams to problems and creates an environment that allows them to solve them. Yes, this has always been Scrum, but it was easy to get lost in the details of how that happens in previous versions of the Guide. The 2020 Guide went back to its roots and actually added a new commitment to the Product Backlog that provides a description of the goal. It also doubled down on one team focused on one goal with the update to the accountabilities and the removal of the Development Team.
Scrum = a self-managed group of people focused on a goal, making incremental progress in an empirical manner with the ability to adapt as they learn stuff along the way.
Now, for many of you reading this blog this is NOT a surprise. But actually, the reality of many Scrum Teams is they do not have a clear view of value. In fact, their Backlog is really an ordered Backlog of work. The Product Owner really is a manager of the work. Scrum provides them with a fantastic foundation to frequently check with their stakeholders they are doing the work and a daily mechanism to ensure that no one is slacking off. And, it even accounts for ensuring that the team has time to improve how they are working. But the currency is work. The Backlog is work. Success is not outcomes, but output. The whole process starts with ‘this is all the work we should be working on, what should we start with?’. Sprint Goals, if present, do not describe customer-centric, outcome-oriented, measurable outcomes, but actually a summary of the work. Goals include ‘finish Phase 1 of the roadmap and get it signed off by the boss’.
Sound familiar?
Of course not, well only sometimes, well we are just a small team in a bigger machine, well..
I get it. I am also guilty with my teams at Scrum.org sometimes focusing on the work. Work is important - right? You can not achieve goals without work, and sometimes by focusing on the work we can ignore the complexities of value and the ambiguity of the customer. And Scrum can help a team that does not get anything done to get stuff DONE. And when I say Done, I mean Done because the Definition of Done provides us with a commitment that allows us to inspect and adapt what it means to be Done. It makes Done transparent for the increment. Add to that success criteria for each Backlog item and a team that cares about learning and you get focus, discipline, and a set of tools to make sure you are getting stuff DONE.
So, what is the big deal? Surely if you are getting work done, and the work is valuable, and the Product Owner is making good choices on what order to do the work and accepting that we learn and need to update the work. Isn’t that enough? Yes and No. Yes, you are doing good and if I were working with you I would be super happy. Progress is a nice feeling, but I worry about three things.
Firstly, does the work really add value? Is it really blending the needs of the customer/user, the cost of doing it, and the constraints of the context it is being executed in? Or is it in fact a list of needs from the person paying you wages without any clear connection with the customer/user? And if the Scrum Team knew more about the value being delivered then could they think of more creative, less expensive ways to deliver the same value?
Secondly, we have learned from Daniel Pink with his book ‘the surprising truth that motivates us’ that motivation is linked to purpose. And purpose apparently, for most people is not doing the work, but instead affecting other human beings. Delivering value to someone else. Purpose is tied up with this being a ‘human’ thing. Of course, we all care about doing a good job and making our team and boss happy, but the real gold standard is thinking we are making the world a better place.
And lastly, the idea of self-management. The idea that we tap the team to decide how they work, the solutions they create and empower them to remove roadblocks. A key ingredient to self-management is a clearly defined purpose statement. This allows the Scrum Team to say ‘hey could we do X to get Y?’. It allows them to step away from how the work is described in the Backlogs and instead focus on why they are here and what they can do. Of course, if the Backlog is written in such a way each PBI describes something in the context of the goal and purpose then it is even easier to self-manage. If instead the Backlog items are described in terms of tasks then it is much harder.
Scrum is all about delivering value in a complex and complicated world. To do it, you have to work. However, if you jump too quickly in describing everything in terms of work then you miss a great opportunity to connect with the team and deliver unique innovative solutions that amaze your customers and users.
Here are some tests that might be ‘tells’ for being a little too work rather than value-oriented.
- Do you have a Product Goal?
- Does everyone on the Scrum Team know who the customers/users are and what the problem is that you are solving with this work?
- How challenging is the creation of the Sprint Goal?
Of course, many of the challenges about value are outside of the control of the Scrum Team and in fact, speak to a fundamental problem on how the teams are aligned to the customer/users and the outcomes of the business. For many organizations, the adoption of Scrum focused on how the teams worked rather than who they worked for. The industrial mindset is still strong in most organizational structures. From experience, when you are faced with such a challenging situation it is best to do as my Grandmother would say ‘slowly, slowly catch the monkey’ (I have no idea why she would say this as she never to my knowledge caught a monkey or lived in an environment where there were lots of monkeys). Incrementally move toward thinking about the product, customer, outcomes, and goals. Slowly refine the Backlog to be describing the value delivered and put in place measures that make that transparent. By making those things transparent to the customer you may start to influence the organization in how it structures the work. It might allow the team to slowly move up the proxy customer chain, or at the very least it makes sure that everyone knows what the focus is.
I hope the changes to the Scrum Guide are helping everyone have these conversations and reminding everyone that Scrum Teams are here to deliver value. The only question is to who and what is it that they value!
Scrum On.