Scrum: Where We Are, Where We Want to Be

Scrum is a hot topic in the project management field. With many projects, especially software development projects, leaning toward agile methodologies, it’s important to understand what SCRUM is, what it means to agile and how it can be used in different projects.

At our most recent Oshyn Talks event, I gave a presentation titled, “Scrum: Where we are, and where we want to be”. For those who could not attend and for those who simply want a refresher, here is a brief overview of my presentation:

What is Scrum?

A formal definition of Scrum says it’s "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" ^[1].

Scrum is related to the agile term and the agile principles described at the agilemanifesto.org ^[2] where we can read, we value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

However, this doesn’t mean we don’t value the non-bold items, it just means we value those items in bold more.

Some readers might ask why nowadays we are hearing about more and more projects that choose agile over traditional (waterfall) methodologies. As shown in the chart, this is because the success ratio of agile projects over the traditional projects methodologies is significant.

^[3]

Why does the waterfall approach fail so often? The reason is simple: we rarely have perfect knowledge at the beginning of a project. In fact, we know less about our project when we are starting out than we’re ever going to know in the future. Today is the least knowledgeable day of the rest of our project.

Complex work, such as software development, implies a great deal of uncertainty and to stay competitive, we need to inspect and adapt quickly.

Instead of using traditional Gantt ideas ^[4], where each phase is connected to the next one and each one has a hand off, Scrum throws all the phases in the blender. All the ingredients are mixed and instead of dividing the work into activity-specific phases, we divide it into fixed-length iterations called Sprints. Every Sprint contains some combination of analysis, design, implementation, testing and planning for the future. Sprints are officially 30 days long and most Scrum teams are doing them in less (usually two weeks).

Right from the first Sprint, a Scrum team tries to build a working, tested, potentially-shippable product increment. In every Sprint they demonstrate what bit of shippable product they have to everyone. Customers often need to see the wrong product before they can specify what they really need. With short iterations and more feedback, we have a better chance of discovering the right product.

To make a shippable product every two weeks, you’re going to want people with skills in testing, in design, in business requirements, in coding, all on one cross-functional, self-organizing team.

As part of its framework, Scrum provides a structure of roles, meetings, and artifacts. The Scrum roles are: the Product Owner, the Scrum Development Team, and the Scrum Master. Two of the most important artifacts in Scrum are the Product Backlog and the Sprint Backlog. There are four meetings defined in Scrum: the Sprint Planning Meeting, the Daily Scrum Meeting, the Sprint Review Meeting, and the Sprint Retrospective Meeting.

If we can easily summarize the framework in a paragraph or a graphic, then why we don’t use it effectively in our organizations? Simple: “Scrum is easy to learn but difficult to master”^[5]

Where we are

So all of this brings us to where we are with Scrum and agile development. Scrum brings challenges to individuals, teams, and organizations. If it’s not disrupting your organization, you’re probably not doing Scrum.

In many cases where groups claim to be doing Scrum, you’ll usually find that they’ve overlooked the parts of Scrum that would provide the most benefit because they’re difficult to implement.

The purpose of Scrum’s strict rules are to reveal organizational impediments that you can start fixing, if you have the courage and commitment.

Where we want to be

So now we know where we are, where do we want to be with Scrum? The truth is, healing the organizational impediments exposed by trying to do Scrum is more important than “doing Scrum.”

-------------------

References

[1] H. T. a. I. Nonaka, "New New Product Development Game," p. 10, 1986.

[2] http://agilemanifesto.org/.

[3] http://www.scruminc.com/story-points-why-are-they-better-than/.

[4] http://www.gantt.com/.

[5] http://cvcedhlab.hypotheses.org/54.

[6] K. S. a. J. Sutherland, "The Scrum Guide," 1991.