How Did Scrum Become a Straitjacket?

The ideas behind Agile (before it was a buzzword) largely arose from practitioners looking to eliminate painful or silly management practices between them and their craft. When I first did Scrum, it was more fun than any way I’d worked before. As a member of a self organizing team, we negotiated Sprint Goals with the PO and collaborated to meet them our own way. Scrum’s freedom from micromanagement opened the door to learning Agile technical practices that kept the code enjoyable to work on. So the autonomy, the social environment, and the state of the product itself made it fun. If it’s not fun, it’s not Scrum. This is the way I try to teach it in my classes anyway.

It makes me sad to see that Scrum and Agile are often implemented as just another way to constrain people and squeeze work out of them. Innovation, intrinsic motivation, teamwork, and employee retention do not thrive in those environments, so eventually the companies that do this won’t be able to compete. But in the meanwhile, they’re sure causing a lot of pain in the name of Agile. One person with strong feelings about this wrote the following to me via LinkedIn:

Michael,

I like what you said, I appreciate the way you said it, and I am glad you were the one to respond to my comment on xp and scrum. In the agile world (and I demoted the “a” a long time ago out of frustration) all the pigs are the same. Only in the way scrum has devolved, some pigs are better that others.

I was hooked on XP after reading my very first agile book (…Embrace Change). Almost a decade later I am jaded, confused, saddened, and have lost the will to challenge the status-quo in agile. In one company I left, the scrumlord actually enforced the waterfall method for project management. (Rally lists and charts were far more important in the presentations to the client than our application or hearing their feedback.) And the company was proud of their “agile” teams. And pair programming, refactoring, TDD, revision control, version control, continuous build and all the rest was forbidden by the scrumlord. “Waste of time,” he always told the CEO.

Why has this happened?

My first guess is that the professional manager found a way to insert themselves into agile — in a particularly contrary move to the spirit of agile. My second guess is that to be a good scrumlord, you really do need to know the technical side and there are too few middle managers who are capable of that. Lastly, I would say that no practice, no methodology, and no trend can do away with the ego of the middle manager.

But, as I say, I’m jaded.

I suppose it was the end of me at that fateful job but I knew it was time to go when I told the scrumlord that a team with only XP can still produce a superior code product with few errors and little technical debt. But a team with only scrum cannot. It would have just been an opinion except I was proved correct in my hyperbole and they had to punish someone.

You use words in ways with which I was once familiar. It is the same melody that drew me to agile so long ago. Is it still being heard in some fair corners? Not where I’ve been. And I don’t look for it any time soon. If you truly live the words you write, then your team is fortunate. And your clients even more so.

So long as the command and control business model is more valuable to corporate leaders than their product and their people, I will keep spelling agile in the lower case.

[name omitted]

After I reported on this email, my friend Kane Mar sent another example of a someone who’s been burned by the discrepancy between what we say and what we do: http://www.halfarsedagilemanifesto.org/

One way to check whether your Scrum implementation is anything like what we had in mind is to go through the ScrumMaster Checklist. The items you mark with deltas may be organizational impediments worth discussing with the highest level person in your company who will listen. If they still won’t listen, please make the best of your short lifespan by finding people to work with who are more committed to human innovation.

–mj
(Michael)

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Tagged with:
Posted in Agile

Leave a Reply

Your email address will not be published. Required fields are marked *

*

CAPTCHA Image

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

connect with CollabNet
sign up for emails
conversations

CollabNet: #CollabNet taps #app #dev industry pro @jliband: as VP of marketing, #Agile, #DevOps, #ALM, #Cloud http://t.co/f7e5Za5TbT
Date: 16 April 2014 | 9:16 pm

CollabNet: 2014 #FutureOSS Results Are In! Finds OSS Powering New Technologies, Reaching New People, & Creating New Economics http://t.co/ECtIkdjG9R
Date: 14 April 2014 | 5:05 pm

CollabNet: Certified #Scrum Product Owner (CSPO) Training Course at #CollabNet HQ in South San Francisco April 16-17 http://t.co/ETLXBrxtTr
Date: 10 April 2014 | 10:25 pm