The Scrum Picture is Wrong (#scrumgathering)
Blogging from the Munich Scrum Gathering, so here’s a rare Scrum-focussed blog, though (of course) there’s a lot here that parallels other thinking in the Agile and Lean world. The Scrum Picture is Wrong: well, not wrong, but incomplete. Misleadingly, dangerously incomplete. It’s easier to say it’s just wrong, and this is why.
The Scrum process picture is familiar, and anyone who’s worked in a Scrum team for more than a few minutes should be able to draw this from memory. Here’s the form that’s usually used nowadays (courtesy of Mike Cohn and Mountain Goat Software):
What is missing from this picture? Here’s a hint: the previous version of picture:
Sure, it’s less polished, less glossy, less professional-looking, but at least there are people in the picture.
But there’s more. Even when you put the cheesy clip-art back, the picture is incomplete. The focus in the picture is the product: the two cycles organised around sprint planning and review and daily Scrum meeting provide feedback and steering for product. But in any development process the product (in the sense of everything that the team produce, which includes tests, documentation and so on) is only one of the deliverables. The other deliverable from the process?
The team. As far back as 1995, Jim McCarthy (of Microsoft!) was writing: “The ends of software development is software developers.” (Dynamics of Software Development, and “ends” as in end result, goal.) There’s a parallel process around retrospectives and actions, which is just as important, and which is talked about extensively within Scrum and the wider Agile/Lean community. But it’s never part of the picture. Nowadays, whenever I draw the picture, I draw it like this:
Let’s make the other deliverable explicit: the team, and it’s growing capability.
I’m increasingly interested in the effect that social objects have on the way we work. There’s a growing body of research that demonstrates the ways in which our environment affects our behaviour[1]. The scrum picture has become a social object around which groups form - you see it in books, presentations, printed and stuck on walls, even (here at the Munich Scrum Gathering) on tattoos (the stick-on variety, though I wonder if any of the diehards has gone as far as making it permanent…). I worry about what happens when we surround ourselves with process pictures which (1) don’t include people, and (2) only tell half the story. As soon as we regard ourselves as “means” to some other group’s “ends”, or even worse to some process’s, we are disempowering ourselves (thanks to Ari Tikka in his Scan-Agile 2009 presentation for pointing this out).
Several things follow from this. The picture is frequently used in presentations to managers and executive teams. The visual impact of this picture should not be underestimated: it’s the “icon” of Scrum, and it’s underlining the proposition that simply by following a (people-independent) process you’ll get better software, faster and cheaper. No matter how often we talk about the people, and describe Scrum as an engine of organisational change, what people hear (and buy), is better software, faster and cheaper. Reinforced by the picture.
Within a team, if all you see and understand is the original picture, the role of Scrum Master/coach readily becomes a clerical or secretarial one: make sure the process is followed, run interference and clear impediments. By adding the capability feedback loop to the picture the job - a large part of the job - of the Scrum Master or coach becomes clear. The product owner’s job is the product. The Scrum Master/coach’s job is the team.
People thinking about organisational change have started talking about two models: “theory E” (which maximise economic effectiveness, in practice often by vigorously attacking cost and waste) and “theory O” (which are models of change which seek to maximise organisational capability). One way of looking at this picture is to think about the part above the line as addressing theory E, and that below the line addressing theory O.
Finally, Lean is not immune from this. The focus on value just now seems to be creating a dominant discourse where customer value is the only good (Steve Freeman has dubbed this the “value fetish”). I don’t think there’s anything wrong with valuing customer value, but we do need to be aware that there are many sources of value, and many people and communities besides the customer for whom things may be valuable. Customer value is hugely important, but we’re in danger of losing an explicit focus on team and organisational capability as an end in itself, and once again surrounding ourselves with pictures in which the people have vanished.
A suggestion: what would happen if we started thinking about the picture like this:
[1] For example, Bargh/Chen/Burrows experiment of 1996, where tasks with word lists activating stereotypes and traits of “old”, “polite” and “rude”, and subliminal exposure to racially different faces, result in significant and measurable differences in subsequent behaviour: “Automaticity of Social Behavior: Direct Effects of Trait Construct and Stereotype Activation on Action”, Journal of Personality and Social Psychology 71/2, 1996
I like the way you discuss 2 focus areas in terms of capability and product. I think is potentially a great way of looking at Scrum. As a Scrum Trainer, when I teach CSM and CSPO course I make sure to focus on the learning system that Scrum employs alongside delivery. Without the learning Scrum is just another process.
It is interesting that the first thing I noticed missing in the 1st picture was “Product Vision”. This shows up in the 2nd picture. I think it is important to put the Vision back into your Scrum picture so that it is also not forgotten.
Thank you for the thought provoking commentary.
Oh yeah, one more thing. Your picture may also be missing the daily Scrum meeting. I am not sure how best to fit it into the Sprint?
Re: Lean is not immune to this
“Toyota people speak of “mono zukuri wa hito zukuri” literally “making things is making people” or “building products begins with developing your people”.”
http://www.gembapantarei.com/2008/07/the_lean_journey_and_the_long_path.html
I would also suggest looking at Training Within Industry, Toyota Talent, Managing to Learn, and even 4S as practiced in Japan.
Wery well put. I will definitely start using your two interlocking cycles. In particular I liked how the separate concerns of scrummaster and product owner became clear. With the current community focus on product owner (which is good, their issues have been unadressed too long) there is a risk we forget the really important part of the scrummaster.
Chris, just imagine the daily scrum “loop” inside or above the sprint box.
Jason - agreed, but this focus seems to be missing from “Lean as it is currently being applied to software development”
Nice article Dave! I wonder why in business this principle is better understood in the area of sale and less so in development…
Cool! I’ll start using the human-side-up double-loop immediately. :-)
–Martin
Nice post. My only change (and I’m not sure how to draw this) would be to show that increasing team capability is a continuous activity, not just associated with retrospectives at the end of the Sprint.
Excellent explanation. I will of course claim to have spend many years trying to get organisations to understand the need for and benefits of capability development alongside (actually, integral to) software / product development.
Hence Rightshifting, FlowChain, and much of the other stuff I’ve been working on over the past few years.
Even now, most business folks don’t get it. Maybe that’s because of the short-termism endemic in modern business, or maybe there’s other factors (too).
Just one comment - no, let’s be direct and call it a criticism: I don’t favour the focus on Teams. OK, so this is headlined as being about Scrum, so I guess a Team focus is natural, if dysfunctional. But the real benefit of capability development is to an organisation, or even a value-chain (across organisations). Teams (particularly project teams) are generally just too short-lived, fragile and product-focussed to be able to sustain the learning you proselytise.
BTW Toyota (TPDS) uses “competency verticals” to sustain learning at the organisational level(cf Kennedy, Ward).
- @FlowChainSensei
Excellent post. As a SM I’ve always believed that my “deliverable” is a better, more capable team each sprint. I believe more SM’s out there should become more obsessed about team/people dynamics and less about forcing people into a process. Stop looking for the “violations in the process” and rather at the underlying “tells” coming from the team that indicate dysfunctions, resulting in these “violations”. Improve the team and you’ll automatically improve the value delivery.
Bob, good point. The focus on the team process is another consequence of the ubiquity of the Scrum Picture as a social object, and is (as I tried to say) one of the reasons that no matter how much we say to the opposite, businesses often buy agile as a development bottom-line win rather than a way to improve organisational effectiveness.
Thanks, David - I’ll happily steal your (last) picture for my next presentation on this topic ;-)
In the picture you propose, you link Retrospective to Increased Team Capability. I think all parts of Scrum/ Agile lead to this.
Also, Increased Team Capability will lead to faster/ better software delivery too. Hence, probably that should find a way in the picture too.
Great Post. You inspired me to come up with a new Lean and Agile picture:
http://availagility.wordpress.com/2009/10/21/a-new-lean-and-agile-picture/
Good day David,
I think the Daily Scrum could be another circle. This would be in alignment with the 3 inspect and adapt cycles in Scrum:
http://www.gettingagile.com/2009/05/01/scrum-is-the-vehicle-not-the-destination/
Now there are 3 circles representing them. I wonder if the picture can be enhanced to show how they are interlocked?
Vikrama - thanks, yes. The point I’m making isn’t that none of this is happening, it’s that it isn’t represented in the “iconic” representation of Scrum.
Chris - indeed (and as Steve pointed out, capability improvement is as continuous as product improvement). The sprint and daily scrum cycles are just convenient points in the perform-inspect-adapt routines: I wanted to keep the diagram clear, but if we were to work this into an official new icon for scrum, I’d put the daily cycle in.
Seems like too much stuff. Why do product and team development need to be separate things? Where’s the customer?
Maybe the model needs more than a fix…
Nice work!! I like this picture because it is more complete. Is this a picture we can use freely?
As for your rhetorical question at the end - having the second picture gives the impression people are the most important aspect of Scrum. I like that even more.
Finally someone has explained this in plain english. The focus on team is so important for success of any kind, be it organizational, technical or individual. Thanks for doing this.
Marty, Carlton, Ravindar, thanks.
Marty, the actual work in the sprint is where I see product state and team capability co-evolving, that’s why the loops come together at this point (except it’s not, of course, a point: it’s way longer than all the other stuff).
Carlton, I’d be delighted if this picture, or versions of it, were to become one of the ways we explain Scrum, Agile, Lean or whatever to ourselves and to others: by all means use it for this.
Not to sound cynical, but I feel we have a long way to go with Product Development & Agile.
I agree with your assessment above, however I’d like to add Eric Ries’ diagram incorporating Customer Development: http://www.scrumology.net/2009/10/14/known-problem-unknown-solution/
David,
I perfectly agree with you that people and team improvement are a crucial part of Scrum and Agile. Your own redesigned picture is a great one, and I’d recommend it to anyone with a layer of knowledge of the basic principles of Scrum. But maybe not for a first-time introduction of the Scrum incremental cycle to someone completely new to it.
I think the main point of the “official” Scrum schema that you criticize is to emphasize on simplicity. I guess the Scrum guys’ intention with this picture was to prove that Scrum was a simple, lightweight framework and depict a process primarily focussed on producing value in the form of increments of shippable software.
Scrum requires such a switch of mind that in order to explain it you somtimes have to stay simple at the very beginning so that people don’t get confused with too much complex concepts. It would be great if you could just throw every single aspect of a methodology into one schema and have it all understood by anyone, but it’s just not the way things work. Sometimes you have to sacrifice some amount of exhaustivity for the sake of comprehension.
Of course, this schema isn’t self-sufficient, it’s just a possible starting point in a series of pictures you can draw (the following ones being the scrum roles, artifacts..) Thus you can go in little steps (sounds familiar, hey ?) towards a better comprehension on the vision.
Pictures are all about what you intend to convey through them, and to what audience. In my mind, your picture and the “official” Scrum process picture obviously don’t serve the same purpose, which doesn’t mean that they’re not equally valuable.
Guillaume, thanks for your well considered response.
Simple at the beginning is of course good. My point here is that this simple picture is what gets stuck up on walls, and reinforced in trainings and presentations (and I’ve seen plenty of these, many by people I _know_ know better), both to developers and to senior management. Very often these simple pictures aren’t followed up by a more nuanced explanation (and possibly, for a beginning team, they _shouldn’t_ be). I think capability improvement should be fundamental to any development process (it’s our only weapon against the rising tide of complexity), hence (1) the desire to make it visible - in however simple a form - from the start, and (2) the question about flipping the picture.
I think you hit the nail on the head. Most successful agile implementations that I’ve seen put a heavy emphasis on the team. Perhaps this is why the first point in the agile manifesto is “we have come to value individuals and interactions over processes and tools”
Hector, yes indeed. Given the prominence of individuals and interactions in the Agile Manifesto, it’s mysterious that both individuals and interactions are absent from the “canonical” Scrum picture.
As always, learning is the bottleneck, and I mean people learning, not machines learning. I’d like to think that including people goes without saying, but I don’t feel convinced about that here.
No scope for learning in the original picture, as there are no people. But for me the capability part of the cycle is all about learning - both team and individual.
Including people in the picture makes sense, although it increases its complexity. So you’re making a trade-off. In the end, each representation works well for some people but not others, so just like a good architecture model has several views so does a good process model.
Hi Scott
Agreed, a single picture - indeed any number of pictures - is never going to be enough. My issue though is that this picture has become the canonical image for Scrum - in training, presentations, pictures in books, stuck on walls. With no people, and only half the double-feedback loop, it’s silently reinforcing the notion that it’s all about the product, and that we humans are mere cogs in the machine…
Thanks to Andy Brandt, who commented on his blog here: http://www.andybrandt.net/533/scrum-picture-is-quite-right#comments
Great Post - still love to cite it. But still the “outer circle” is missing - there needs to be (at least) one more circle with respect to the product backlog.
The picture(s) above still show a waterfall in product definition (Initial backlog, no feedback from deliverables to PBL) that only get /implemented/ agile. I’ll try to sketch up a picture of what I mean when (and if) I find the time.
Great Post none the less and I’ll keep citing it.
Michael
Thanks for the feedback, Michael. You’re right, of course: the team/product process in (original and revised) pictures sit inside any number of other circles (I’ve thought about this in the past as a system of concentric conversations, if you see what I mean…). I’d be delighted to see what you come up with for the larger context.
Thanks for this post and bringing the values of the Agile Manifesto back into the picture! As many have mentioned Agile and Scrum is as much about developing teams and organizations as it is about empirical process control on various levels.
When I look at the picture, there are still some things missing on the team & org development side which is present in the product development.
- What is the equivalent to the vision? Is it a vision for organizational change?
- What could be the product backlog for organizational development? Should there be an improvement backlog with prioritized improvement goals?
- On the daily level, should we inspect & adapt teamwork and methods on a daily basis and do we need an extra artifact or an extra meeting for this in Scrum?
If we put high pririty improvement goals on the product backlog and plan for it during the sprint planning, we wouldn’t have to double artifacts and meetings! Just keep it simple but don’t let us forget that we value individuals & interactions more than processes & tools!
Thanks for reminding me of that!