« Whistle-stop tour of Agile events | Main | Is Working Outside-In Always Better? »

28 March 2010


Feed You can follow this conversation by subscribing to the comment feed for this post.

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.


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


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.


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).



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.

The comments to this entry are closed.