Agile is not Scrum
Most people who read this blog will not find the title of this post a revelation. I know firsthand, however, that this is not the case for many.
I recently had the privilege of facilitating a Birds of a Feather session at PDC. The title of our discussion was “Agile – Triumphs, Teams, Trials, and Tribulations” and really just provided an opportunity for attendees to share stories. The session was extremely popular. So much so, in fact, that a fire marshal showed up to remove a few people from the room.
Cool, eh? Here is that not-so-cool part.
About 35 minutes into this discussion, I realized I hadn’t heard a question or comment that wasn’t related to Scrum. I asked the room, “How many people are on an agile team that is NOT using Scrum?”
5 hands. Seriously, out of about 150 people of so. 5 hands.
What in the world?
Is this simply a sign that Scrum won in the marketing wars? Is this just because some people have heard about Scrum? What’s the root cause of this?
Is it the C-word (certification) that goes along with the 2 day CSM course proving you didn’t die midway through class? Is it the fact that there are some MS Press books on the subject? Is it the fact that there is a soon-to-be-released Scrum Developer course endorsed by Microsoft?
I am not bashing Scrum, but it certainly isn’t for everyone. In fact, I find that Lean with a Kanban system is typically far more effective in medium to small organizations. I am just incredulous that Scrum is so ubiquitous in the Microsoft-stack enterprise.
Scrum does not define agile software development. It drives me crazy to hear someone say, “We are doing Agile. We have Sprints and everything.” I assure you, dear reader, 2 week time boxes does not an agile team make.
The other thing that really fries my chips is that something south of 20% of people who profess to be using Scrum actually are doing so. I have seen so many ScrumBut implementations I have started to expect it in any company that claims to be using the process.
My standard advice for any team is to implement a process without modification for at least 3 months before they think they understand it ell enough to tune it to better fit their needs. Of course, no one does this because “we are different”.
Yeah, sure you are.
The bottom line was stated perfectly in the BOF session by Simon Bennett.
“Don’t tell me by-the-book doesn’t work without at least reading the entire book.”
Hi David,
I think the reason scrum has “won”, is because the business/project management side of the team can understand it. It talks about things they care about.
My experience of methodologies is that folks know about a bunch of stuff Waterfall, Spiral, XP, Scrum…and from that pull out different bits to form a process appropriate to their circumstances.
Over time you get an incremental change in methodology. Your in a place, you want to get better, you try out scrum time boxing say, things are improved, everyone’s happy, and you now say “we do scrum”.
The reason folks take an incremental approach changing their process, is because change is difficult. You need buy in from a good fraction of the team, you need to persuade and explain, you need to practice and learn – it takes time and it’s emotionally draining.
That’s why ScrumBut is much more common than Canonical Scrum.
To me incremental improvement is one of the key ideas of agile. Should we be surprised that it applies to the methodology itself, as well as to the construction of the software?
Cheers
Mat
Thank you for the post David. It is true that Agile is a set of principles as listed in the Agile Manifesto, and that Scrum, XP, and other process frameworks are implementations of the Agile principles. I feel the reason that many companies do Scrum, or start with Scrum (before going to Kanban or something else), is that many people are looking for something by a name that they can grab onto and say “we are doing that.” The same goes for any project management methodology, marketing or business technique, or whatever. People can point to it and say, “this is what we’re doing.”
Scrum happens to be, in my opinion, a great doorway to the implementation of Agile principles in a company. Certifications, valuable or not, help make that happen.
So what’s wrong with 145 of 150 saying they’re doing Scrum? Scrum is simple. It’s a great starting point and even if it’s technically ‘scrumbut’ in some scenarios, if those organizations are delivering value, does it really matter what they are or say they are using?
I don’t disagree with what you have all said here. The thing is, many teams are failing with ScrumBut. I think Scrum is great when actually practiced well. I also think it is only a gateway drug to actually making your organization perfrom well.
@Robert, see this:
https://elegantcode.com/2009/02/21/how-scrum-is-like-marijuana/
@Jason, why is it bad? Simple. Lack of diversity tends to be harmful to the body of practice in the industry and the fact that Scrum is NOT the silver bullet people treat it as.
Scrumbuts can be pretty annoying environments. My agile experience started with XP where we chose to try it “by-the-book” for about 2 months, then modified it. The only change we felt was necessary was to use pair-programming when new team members were brought in. After, we used a form of pair-analysis where teams of 2 would be assigned stories, break them down and discuss them together, implement them separately, then swap to do reviews. It wasn’t that PP didn’t work, 2 people can write better code, even a little bit faster than 1 person, but we found by pairing the important part (analysis) and keeping the fundamentals of TDD, CI, and continuous improvement vis standups and the coach, we could squeeze a bit extra out of it. This also avoided it “appearing” to management that it was twice as expensive where with PP, 2 people would be doing the job as one.
The scrumbuts unfortunately just seem like a mess. maybe it’s because I was involved in the XP-but from the beginning, where I’ve been brought into existing scrumbuts. The silliest instance is where a team says it’s scrumming because they do a stand-up meeting in the morning. Not even two week iterations. :/
There is quite a bit of frustration in this post. You say you’re not bashing Scrum, but you are bashing something, I can’t make out what exactly though.
Are you saying people should try to do more/better/canonical Scrum? On the other hand, you mention using Kanban/Lean as a toolkit, so should people improve their process based on stuff from the whole Agile knowledge base and not meekly adopt Scrum?
You are exactly right. It is very hard to cut through the marketing “fluff” of scrum. Don’t get me wrong, scrum can be great, but it is not agile and it is not the “end all be all” that many consultants would like to pitch it as. One of the major problems I see with people not understanding the difference between agile and scrum, is that they think by doing scrum they will automatically get the benefits of agile, which leaves them with the single biggest problem, IMO, that scrum teams face.
How do we get shippable code in 2 weeks?
Well if you don’t focus on things like, software craftsmanship, best practices, TDD, continuous integration, (many of the XP programming type of methodologies) for actually building your code, you won’t be able to incrementally build shippable code.
Hi David. I came across your post and I like it. I think that this is a common mistake that they become synonymous, even though they obviously are not. It’s a shame that this is so widespread, because it causes some dangerous confusion.
On another note, I wrote a blog post on the topic of Scrum as well, which you can find at this link, if you’re interested: http://www.softwarepurist.com/blog/index.php/scrum-agility-and-practical/
It might have been interesting if you’d enquired further, to see how many of those 145 people were *really* following Scrum, as opposed to doing something they called Scrum. It’s my feeling the term, like agile, is greatly misused by those who have adopted ideas they’ve heard about, often missing the point of why those ideas should be practiced…