How "Agile" Is The Concept of Scrum?

How would you answer the question on this sticky note?




This question "How 'Agile' is the concept of Scrum?" was posed by Lucy, a business analyst with around six months experience on a team attempting to apply Scrum.

On face value, her question seems to be asking "Is Scrum a member of the Agile family of methods and frameworks?" Clearly, the answer is "Yes!" Jeff Sutherland and Ken Schwaber, the thought-leaders credited with creating Scrum,  took part in the summit that created the Agile Manifesto. Plus, the titles of "Agile Software Development  with Scrum" and "Agile Project Management with Scrum" books explicitly align Scrum as an Agile approach.

I took a deep breath. Before diving into an Agile history lesson, I tried to unpack Lucy's question, to see if I could get closer to answering her. "You seem to be asking "Whether Scrum is an Agile approach. Is that right?"

Lucy's brows creased and she shook her head. "No. I meant 'How flexible is Scrum?' Is anything in Scrum optional?" She went on "Our Scrum Master wants us to do Scrum by the book. That's difficult for us because people on our team come from different departments, we get conflicting messages from our line managers. I'm expected to work on more than one project and it's not working for me."

When I hear about Scrum Masters or teams attempting to "do Scrum by the book" it sets alarm-bells ringing for me. Scrum is a starting point on a team's journey towards agile software development.  Being Scrum is not the real goal. We use Scrum to deliver product increments. No one is going to come along to your team to check up on your Scrum conformance. There are no shiny Scrum badges to give out to the teams who doing Scrum correctly. Besides, Scrum has evolved over the years, you can find one book is at odds with another.

We follow the Scrum mantra "Inspect & Adapt" and fine-tune our working practice through retrospectives. As we become more proficient at delivering product increments, our team can decide to drop initial practices. For instance, they may find maintaining a Sprint Burndown in a spreadsheet is an unnecessary overhead when everyone can see progress on our task board. Scrum is definitely flexible.

However, being able to flex Scrum and not seeing Scrum conformance as important isn't quite the same as opting out of implementing various parts of Scrum because it's difficult.

Scrum is finely-balanced to maximize motivation and productivity. Scrum frees the team up to get on with work in sprints rather than constant churn from conflicting stakeholder requests. Scrum sets the team up for success by positioning a Product Owner, as broker for all stakeholder requests with a Scrum Master acting as Gatekeeper to minimize disruption during the sprint. I drew this picture to show how requests to work on other projects are headed off by the Scrum Master.

My picture could be improved by drawing the bubble around the team as a dashed line. The team is not hidden away. The team gets exposed to stakeholder feedback in Sprint Review and their visible backlogs make progress toward their commitments transparent.

Scrum is not a fashion statement. Make believe that you're doing Scrum by having daily scrum meetings and skip the rest. But be warned, without ring-fencing the team, you'll find it's a struggle.

If Scrum team members are asked to work on more than one project, they have conflicting priorities, which distracts them from working toward a common goal. Stand back and watch how this sucks the energy out of a Scrum team.

If your organization can't commit to putting the starting conditions in place for Scrum, they cannot expect to get the full benefit. Lucy's question came up because she was sick of being asked to pretend to do Scrum without experiencing any of the joy that can be gained from teamwork and regularly delivering useful products.

Agile Coaching is about humane and sustainable development, I hate to see people being asked to use process and tools that waste their time. We need to reach out to management to help them understand the basic principles underpinning Scrum and help teams to make the costs of multi-tasking more visible.

Comments

[Tobias Mayer]

Nice post Rachel. It is sad how many people think that "by the book" means good. Ken Schwaber once said in a CSM class that he sometimes regretted writing the books because they are so many steps away from a conversation, which is what really drives Scrum.

It is important, as you point out, that flexing Scrum, making it work in one's own context, is NOT the same as dropping parts of the framework because they are hard. No two implementations of Scrum are alike. Many are vastly different. And all the ones that work are the ones that stick to the simple rules first, and innovate within those boundaries. Without boundaries, creativity is simply self-indulgence.

> she was sick of being asked to pretend to do Scrum without experiencing any of the joy that can be gained from teamwork and regularly delivering useful products.

Yes, it's the new style of Death March.

[Scott Duncan]

So I'm wondering where you actually stand on the question(s) raised in the article? At the outset, it sounds like a flexibility vs purism issue, but ends up sounding like an issue of an organization not being prepared to even try applying Agile/Scrum ideas fairly.

If an organization puts up barriers to success, shouldn't someone be asking them to be more supportive of the Agile/Scrum approach? What (how much) can be sacrificed to organizational resistance and still expect Agile/Scrum to be given a fair chance?

For some, the statement "If your organization can't commit to putting the starting conditions in place for Scrum, they cannot expect to get the full benefit" is being purist/rigid. For others, it's just being reasonable.

[Bendre]

Good to see I'm not alone facing this problem. This is exactly what we tried to discuss in "What's in it for me" open space during the SGUS earlier this month (Refer @bachananand - http://conscires.com/blog/).

>> I hate to see people being asked to use process and tools that waste their time. We need to reach out to management to help them understand..
Something I tried to find answer to and I believe I will need to pair with a experienced "Agile Coach" to help me address this. Unfortunately - Agile/Scrum are REALLY being used as "fashion statements" by some ppl.

>>If Scrum team members are asked to work on more than one project..
That's what I remember from Jeff's keynote - if you're looking for multitasking, you're NOT really doing scrum. It's focused, dedicated attention to your team and product.

May be it's time to collaborate with Tobias on my action plan on addressing the issue here.

By the way, since Lucy asked the question - I am sure she is ready for the change. It's a positive change! Good luck.

[Rachel Davies]

Scott,

Apologies for not quite answering the questions posed.

Presumably, the reason any organization is implementing Scrum is to improve in some way. If they don't expect any benefits then I'd question why they're attempting Scrum. However, they are unlikely to get much benefit if they don't put the basic starting conditions in place. These starting conditions are often not understood or communicated properly.

When team members have to juggle tasks on several projects then it detracts from getting their work done and decisions about the priority of the work move to implementers rather than according to business priorities.

Organizations need to be made aware that asking people to work on more than one project at a time conflicts with Scrum ethos. I don't think that this underlying principle is clear to all organizations who attempt to apply Scrum. To ignore it in the name of pragmatism is missing the point.

I also recognize that often only some managers are convinced of the value of applying Scrum and others are tolerating it or waiting for it to fail.

[Terra]

A very good piece, thanks for sharing. I would suggest (in answer to Lucy's question) that for a lot of organisations Scrum is not an Agile process. This is not because it is in any way incompatible with an Agile mindset. Just that the training mechanism used by many of the coaches/lecturers demonstrates a fixed template process and then concentrates on how to implement and manage it. This is being brought back into organisations and inflicted on the development teams like a cookie cutter; one size fits all. Any suggestion of tailoring the approach or flexing procedure during exceptional incidents is more likely to get you labeled as "Unprofessional" or "Missing the point" rather than find a receptive audience.

Just to clarify I think is not necessarily a problem in the teaching per se but maybe an issue in the absorbing. For many traditional managers an evolving and flexible process is an unnatural thing, maybe the coaches could spend more time exploring agile itself rather than focusing only on Scrum (might lead to less misconceptions).

Also as an aside I propose starting a movement for scrum masters to be reclassified as scrum directors (or something else). Something about the title scrum master seems to convince people that they are the Yoda of Agile (even when they have no idea what they are talking about lol).

[Ecosystem]

Hi

I sometimes have the same feeling as Lucy? Is scrum really agile??

In scrum I am being asked to give points or size to the stories I pick and many times I don't even know what the story is about or how much effort is needed (I am the only one in the team who can do that work so I am asked to pick those stories) . How am I supposed to give points to such stories? And what is size or points calculated on? It it time or effort or complicatedness? The reason I ask this is cause for me these are not always the same.

Why are investigation points not taken into account? Today my scrum master asked us to remove a story (and hence the points associated with it) since the investigation of the story revealed that it is something that cannot be done for this sprint. But there was considerable amount of time and effort put in by my colleague to do this investigation.

Also I am only managing an existing project that was build on a somewhat iterative development cycle. What I mean is that every time I move to next iteration or to the next stage there is some change that need to be done in the previous iterations. I am not very sure how this fits into the scrum cycle.