Two Types of Scrum

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.

What I Really Want to Do

I can’t sleep tonight. My mind is racing. I’m getting to what I really want to do.

I’ve been training people in Agile methods and Scrum for quite a few years now. I’ve seen change happen, I’ve seen people regaining enjoyment at their work, I’ve seen people crank out almost error free code faster than ever before, I’ve seen people conquer problems that seem quite impossible. But none of that is enough.

It is not enough because none of that is creating a sustainable change in their environment. The organizations where these things happen still keep promoting a different environment, an environment where old formalities of management reign, where command-and-control and task-oriented mindset reduces people to doing their work instead of solving problems in collaboration with others. These organizations rule the business scene of today.

Or actually, they don’t. But because they are so many and the different companies are so few, no-one really sees that they don’t. Being different and better is a business advantage so great that many companies want to keep it that way. But there is hope that a change is coming.

And that’s what I really want to do.

No Agile transformation will stick without change in the corporate management style. Every low-level success will eventually be stiffled out or will fade as the people involved will leave in a hope of finding a better place to work, a place where they would be appreciated. This is one reason why e.g. so many top-notch IT professionals join Reaktor, because there they are.

I really want to help companies, and particularly their management boards, to tap into the real thing – the innovation and dedication of their people in creating value. In doing so, I’m willing to not use the work “Agile” because so many C-level people incorrectly assume “Agile” is just for development work. I don’t want to create unsolicited hopes for people unless I can also help the management start transforming the whole organization to support those people’s work.

There is actually no secret to this all. I mean, there is no secret because the roots of this change are displayed all over the internet and published in many books. It all is merely ignored by the majority of business management.

What I really want to do is change that. I want to be part of the movement that is trying to wake up the business management layer from its Sleeping Beauty dream (because the ideas are a hundred years old and based on managing unskilled labor). Does that make me a prince? Maybe not :).

I don’t yet know how I will achieve what I really want to do. I know the key things in how the organizations should change, and I know how to effect the change in lower levels of the organization. What I don’t yet know is how to catch the ear of the C-level people so that they would listen. Am I not charging enough money? Or am I lacking the charisma of Jari Sarasvuo? Or was he merely charging enough money?

Sillyness aside, if there are senior executives who are not satisfied with the results they are getting from their leadership and are seeking ways in which they can make the world better for their employees and their customers (and of course, their investors), drop me a note and let’s explore a better future together. I’m sure I have a lot to learn from them as well.