I can’t agree more with Chris on this one. Get ready for a rant. I’ll try to keep the language proper, though being “PC” is going out the door.
A Bone to Pick
James Turner, a contributing editor for oreilly.com, wrote a post back in December of ’09 about the best and worst tech of the decade. While I agree with most of his list, there is one item on his “worst” list that got to me – the cult of Scrum. James writes,
If Agile is the teachings of Jesus, Scrum is every abuse ever perpetrated in his name. In many ways, Scrum as practiced in most companies today is the antithesis of Agile, a heavy, dogmatic methodology that blindly follows a checklist of “best practices” that some consultant convinced the management to follow.
Endless retrospectives and sprint planning sessions don’t mean squat if the stakeholders never attend them, and too many allegedly Agile projects end up looking a lot like Waterfall projects in the end. If companies won’t really buy into the idea that you can’t control all three variables at once, calling your process Agile won’t do anything but drive your engineers nuts.
Scrum is not a cult in any way, shape, or form. Scrum is not dictating how to run your life or business. It isn’t dictatorial at all.
Granted, I am more that sure that there are consultants that read a book or two and sell Scrum to businesses, only to have a very poor implementation. Perhaps they misunderstood the Agile Manifesto. Here’s a hint: when the manifesto says “working software over comprehensive documentation,” it doesn’t mean no documentation. How do you arrive at that conclusion? By reading what you want to read, not what’s actually written. And who are the people spreading those rumors? Perhaps the evangelists of other methods. I don’t know and frankly I don’t care.
So back to James. I’m sure that James sees companies that hop on every buzzword and managers that try to implement the latest thing they heard about at a conference. “Agile? Better, faster, cheaper? Sounds good, give me some of that.” Hopefully these folks will find a consultant that will show them the correct way, and help them to truly understand what Agile and Scrum are about. Here’s another hint: it’s not just about software.
Don’t F*ck With My Sprint
When I was working with NFi Studios (a great team of people), everyone quickly learned my favorite phrase: “Don’t f*ck with my sprint.” Only the best of reasons were accepted for breaking a sprint – client site down, someone died – things along those lines. There’s a lot of reasons for not changing an in-progress sprint. Here’s two biggies:
- If your team never finishes, over time their morale will suffer greatly, they will hate their work (as they feel they never complete their goals), and your product and business will suffer.
- When requirements continuously change, the cost of context switching increases in relation to the amount of change. The more change, the higher the cost. Ever heard of “the zone”? Pull a developer out of that and it can take 30+ minutes to get back.
We can deal with these issues easily – if you need to handle more change, reduce the sprint length. At NFi, we went from 2 week sprints to 1 week sprints. The deal I made was that in return for having a 1 week sprint, barring an act of god, nothing inside of a sprint would change. This made things run quite well, and we could respond to client requests better than anyone. And we kept a focus on high quality.
It can be done.
So Leave the Agile Manifesto Alone
Again, I couldn’t agree more with Chris on this one. There is nothing wrong with the Agile Manifesto. It is still highly relevant, and there are still a great many companies that can benefit from it. The same goes with Scrum.
Mike Cohn (a big Scrum guy) once told me that he doesn’t care what process people use, just try it in it’s entirety and by the book. Interested in Scrum? Here’s the book – Agile Project Management With Scrum by Ken Schwaber. And while you’re at it, purchase every book that Mike Cohn has written as well; they are all very good.
Don’t change the Agile Manifesto. Don’t update it. There is no reason to.
Over the years business has gotten so far away from the principles that make the manifesto good. At one point I had to turn off the news for days because I got sick of the endless stories of greed, corporate misconduct, and theft. People behaving very badly. Sure there will always be people like that, and there will be people that jump on buzzwords and see silver bullets.
Our Job
It is the job of those that understand the real meaning behind the term “Agile” – focusing on people, building trust, talking with each other, handling change positively and for benefit – to help people and companies understand that meaning. And Scrum? It is one way to implement these principles. It’s a choice. But please understand what it means to you and why you want to use it. And get informed before hiring someone to help you implement it.
The time for hollow implementations of buzzwords is over my friends. None of us have the time for or luxury of doing so.
Other Posts That Might Interest You
This rant could easily cover not only agile but most of good practices out there since there are always people who have the answer for everyone which bases only on their own (possibly bad) experience with this or that.
But, at the end of the day, why should we even care whether someone considers Scrum as abuse of agile or not?
Great article. In my coaching I find there are basically two types of (IT) people. I'll call the first ones “Type D” (D for directive), those who sit back and wait to be told what to do and this would also encompass those who who like telling those types what to do. These types lean towards heavyweight processes that spell out when they will go to the bathroom 3 months from now. When these types attempt “agile” they just don't “get it”, thus #failure ensues. These types don't understand the Agile Manifesto because it doesn't give them enough direction and they can't read beyond it. I'll call the second ones “Type M” (M for Manifesto) as these types can view IT development through the lens of the Agile Manifesto and know that what we do is actually as much Art as Science.
It's the Type D's that desire to significantly muck around with Agile Manifesto and the different agile frameworks. They just don't get it. I intend on blogging soon on a Agile Manifesto Corollary that can provide a little more guidance to help these poor souls without removing any of the spirit or meaning.
Thanks, Robert !
Alistair
It is the sad destiny of all ideas to fall into the hands of men ;o) Agile will (has is maybe more correct) escape this fate and as in many religious case, the followers knows more about rites and laws than what is the original spirit of the movement.
I really push folks to understand the Agile Values & Principles before diving into methods & practices, but the pressure is strong to go for the latter as that's what is taught so much and can be presented more prescriptively (i.e., telling folks what to “do”). The latter works because of the “Shu” salesman factor (thank you Alistair for the whole Shu-Ha-Ri explanation as well as the pun). But I try to insist on the Vs&Ps because, inevitably, esp. as larger organizations pursue an Agile approach, some form of “tailoring” in metyhod/practices happens.
Now this is, at least to me, understandable. But my problem is the modifications are done without understanding the Vs&Ps behind the things being modified. The result is often a practice that misses the point, but seems to go through the same motions or achieve a (seemingly) similar outcome. This moves people further from the Vs&Ps and, generally, produces unsatisfactory experiences/deliveries. This, in turn, leads to statements (or unspoken beliefs) that “Agile doesn't work.”
So, while I feel the Manifesto Vs&Ps are just fine as they are, I would hope folks who train/coach others would make a stronger point of trying to have their clients understand the intent of the Manifesto and what that would imply for adoption before encouraging a specific method or set of practices. Does the strictness some seek around methods/practices comes from concern over harmful tailoring? I would guess so, but would hope effective tailoring could be taught. I believe it is an inevitable part of larger adoption efforts where “eating the elephant whole” truly can't work, but eating it pieces at a time could, finally, get the whole elephant consumed.
Waterfall had feedback loops that would have made it more agile. Just Sayin…
“just try it in its entirety, and by the book” — there is the often rub.
A source of abuse is, hearing only what we want — especially, management, with only a partial buy-in. As in, a 'self-orgainizing team' that is yet micro-managed, or remarkably, whose attempts at collaboration are actively discouraged because of an entrenched schedule driven bias to see the process as fence painters painting a fence, which results in N x 1, not N x N..
I have been in a university-level class where one of the instructors even told the class “you can't have requirements in scrum”! The agile manifesto couldn't be more relevant and provide better direction for the savvy, but some people will just never “get” it.
I also think the most important thing to try and teach people about scrum is the principals of scrum -Transparency, Inspection, Adaption. Otherwise, blindly following the processes -even strictly following them- doesn't really yield much value anyway.
The problem with the “agile community” is dogmatism and rage. The Scrum framework (and XP practices) are defended as if they were directly dictated by God. Nevermind the real life constraints and reasoning! You must do this exactly like Mr. I-Know-It-All-Agile tells you in his book XYZ or you aren't a “real” agile team.
What a bunch of BS. Many people have turned their brain off and blindly follow these manifestos and repeat the blurts of the agile highpriests – whether it makes since in their CONTEXT or not.
The process is not the goal, quality results with the best possible ROI is.
Wake up!