I’ve come to realize recently that there are two types of Scrum. One is goal-driven, the other is story-driven.
The Story-Driven Scrum
This approach seeks to identify and prioritize user stories (or any requirements) small enough to fit in the iterations. In these Sprints, the team commits to delivering the selected set of stories. These stories can be estimated and the amount of results can be measured for longer term planning. This approach works best when enough design work can be done in advance to eliminate most significant elements of uncertainty prior to committing to work in a Sprint. I could call this type the Mike Cohn Scrum as this approach is excellently defined in his Agile Estimation and Planning book.
The Goal-Driven Scrum
This approach sets a goal, or a problem or a challenge, for the team to solve during the sprint. The commitment is to solving the problem, not so much on the characteristics of this solution. The goals are harder to measure and therefore it is more difficult to gain information on the team performance for future planning, but the whole approach is geared toward research and problem solving, both of which are by nature impossible to estimate accurately. I could call this type Ken Schwaber Scrum, or maybe Takeuchi-Nonaka Scrum, as this approach was quite prevalent in the original Scrum texts and especially in the Takeuchi & Nonaka article The New New Product Development Game where Scrum was first described.
There is a lot of experience of story-driven Scrum in the world out there. Majority of Scrum implementations are of this type. However, I’ve recently come to perceive this approach as potentially the weaker type of Scrum. I guess I have to explain.
The power of Scrum is in transformation and innovation. The more cross-functional the Scrum team, the greater is its power for said innovation. The more leeway the team has in solving the problem, the greater is its potential for finding breakthrough solutions. The very extreme is the team described in The New New Product Development Game article that was given three months of time, full support, and the goal of developing a new product for the market. The team itself had all the expertise needed to understand the problem, explore solutions and deliver the goal.
The difficulty with goal-driven Scrums is that they require much more transformation from the organization than story-driven ones. Goal-driven Scrums force the involvement of most or all functions in an organization. Much more rapidly, the organization must face redesign of the way it works. I bet it will fail rapidly if the Agile values are not embraced at all levels and functions of the company.
The story-driven approach is much more-forgiving to the organization. In it, the development teams can be pretty much like development teams have been in the past, primarily consisting of software developers of various roles. They can also be fed quite similar problems (just transformed into stories). While doing that well will result in significant improvements in several ways, it still more easily allows sticking to old paradigms. All of this is obviously dysfunction, but that is not so apparent to many organizations.
When looking at most contemporary Scrum teams, they are typically quite homogenous in terms of skill sets and background (e.g. software developers). While there can still be significant differences between team members, we rarely see people with marketing, sales or domain expertise (except in the very good Scrum teams). The “Agile transformation” has been nicely constrained to the development group. As a result, these teams must receive pretty well-defined work. The capability to innovate entirely new solutions is very constrained.
Unfortunately, there isn’t a clear pattern how a goal-driven Scrum would operate. Many Scrum and Agile trainers don’t teach about its existence. I know I haven’t. I should, at least to open up minds to its existence, but I’m really short on time as it already is with the CSM course. There are so many topics already that adding that might prove impossible. Yet I think I should, somehow.
I believe the goal-driven Scrum would be instrumental in transforming organizations beyond product development.
Agilecraft - Blogging and Stuff 
10.8.2010 at 17.14 |
Excellent post, and you pinpoint a very interesting distinction. It is not one I have considered before in these terms, but it makes sense as a way of understanding some important reasons why Scrum sometimes fails.
In a sense, Story-driven Scrum could be considered the happy medium between (dare I say) ‘pure’ Scrum and Kanban, the former being about cultural change and the latter being very much about supporting the current status quo and allowing behavioral change to occur very gradually (if at all).
Most CSTs do indeed teach story-driven Scrum, and I agree it is the kinder of the two (kinder to existing organizational culture). It is also not likely to have impact on the wider organization, which perhaps is why people feel the need to add Lean concepts and practices to their Scrum implementations. Although personally, I don’t believe that adding lean gets any closer to creating a cultural shift, but it does perhaps get management to embrace the empirical nature of the process, and the idea of frequent improvement.
But while Story-driven Scrum may fail to change a culture, goal-driven Scrum may fail for other reasons: it is too much for many organizations to deal with. Scrum is scary, as it is about a real paradigm shift. I guess understanding these two types of Scrum (or rather the continuum they sit on) is important to help us make useful recommendations in the context we find ourselves in as trainers and coaches.
My hope, of course, is that organizations can embrace goal-driven (pure, true) Scrum. To do that a values- and principles-based approach to training is essential.
Thanks for writing this.
31.8.2010 at 9.55 |
I would like to share my perspective of a project manager who uses a mix of agile and traditional methods depending on the project. To me story-driven Scrum seems “safer” to embed in an organization and it basically encapsulates development activity, also limiting innovation within this domain. Goal-driven Scrum would be hard to handle in a traditional organization but it should boost creativity and help solve issues that can be hardly broken down to “user stories”.
21.11.2010 at 15.21 |
I use iterations and always have a goal or a theme (which fit into a larger theme, too). That’s to say, you can easily mix the two, the retrospective should help you tweak your goals. What you call story-driven is v. weak, it’s essentially a tool of production and not improvement. (Team who do this are very often good at the planning and doing in the plan-do-study-act cycle but rubbish at the studying and acting).
Tobias is right about values. If they do not align, the game is up. I sketched this idea a while ago.
http://www.financialagile.com/reflections/9-general/37-beliefs-matter
The reason we fail is because we get caught in a values fight. Real transformation requires real commitment and therefore the guts to redesign – that’s fire and hire – your team.
21.11.2010 at 16.53 |
Hi Petri–
I would suggest that Scrum teams should be driven by both. The goal comes from outside the development team. You mention Takeuchi and Nonaka. In the 1986 paper on Scrum they describe the team at Fuji-Xerox building a photocopier. They were given a goal: you have “two years to come up with a machine that could be produced at half the cost of [today’s] high-end line and still perform as well.” This is the “built-in instability” of Scrum referenced in that paper.
As you know, teams are self-organizing and they self-organize in response to this challenge presented to them by management (via a product owner). In the Takeuchi and Nonaka paper they say that the team “develops an independent agenda.” They are referring there to an approach to solving the problem.
So, I’d argue that good Scrum teams are driven by an outside goal given to the team and they drive themselves towards the achieve of that big goal with smaller ones that fit inside their sprints (which are usually stories). So it’s not an either-or situation; teams are goal- and story-driven.
But I agree with your premise that many teams do not focus sufficiently on the bigger, outside goal. I often use terms outside the Scrum vocabulary to stress this. Jim Collins has the BHAG, or Big Hairy Audacious Goal and Linda Gratton calls it a team’s “igniting purpose.”
22.11.2010 at 20.14 |
What you describe is an age old confusion about requirements. User stories can be goal oriented, but rarely are. What you call a goal, could be also be called a problem and the interesting thing is that people have problems, systems do not. So a us that says: “as x I want a button that does y” you’re leaving out the problem and are actually describing and desining a solution. Thus making the writing of the us the first design step (also known as the requirements or functional desing step in waterfall).
You can stick to your user stories, but try to leave out the design and only state the user problem (or story).
A good read for more background are Jackson’s books on Problem Frames. This is also pointed to by Tom and Kai Gilb.
22.11.2010 at 20.33 |
@Mike: You make me see the goal orientation in two levels – the BHAG and a sprint level goal. I find it a little hard to sometimes combine the latter with user stories (in practice, that is, not necessarily with theoretical cases), whereas the former, as you point out, can easily fit user stories in it (thus, the both-and approach). I’ll keep your insight in my mind.
@Machiel: The user story you mention isn’t a very good user story, as you point out. I think it is invalid in the “Negotiable” of the INVEST criteria. But I can see how some teams might use such stories. I would also advice against such a choice.
23.11.2010 at 19.16 |
Hi Petri
Thank you for an interesting post. What you describe goes hand in hand with my own experience – especially the part about how story-driven Scrum limits organization learning. You have got me interested, now I will read up on your blog.
26.11.2010 at 21.36 |
Hi Petri,
Great post. You express something I’ve experienced with highly mature Scrum teams that function well with their product owner and take on highly complex problems.
I agree with Mike, that teams should be driven by both, but I’d like to add that the balance can often change over the course of a release.
Such teams start with an overall epic release goal (or BHAG) and iterate daily. Establishing an initial set of stories for even a two-week sprint is hard. They are goal driven. Then as they narrow in on the core value of the epic, they are able to decompose the epic into meaningful stories that won’t change in the short term; they become more story-driven.
As mentioned, this requires a mature team and a committed product owner.
Clint