James Shore wrote a great post about the problems he is seeing with agile adoptions that start with Scrum called the Decline and Fall of Agile. Please please please (pretty please) read it before you read what I am about to write here! I agree with what James is saying 100%.
Now, let’s hear the truth:
Scrum is really really hard! Doing Scrum well is like quitting a heavy, long addiction (I think). Don’t ever make the mistake that because Scrum is simple (lack of complexity) that it is somehow therefore easy (lack of effort).
Doing Scrum properly takes:
sacrifice – sacrifice of our ways of thinking, our habits, our comfort
wisdom – wisdom to see the small improvements while struggling with the humongeous ones
and most importantly,
truthfulness – honesty to see and say the truth, integrity to act on the truth, detachment to avoid believing in what you want instead of what is real, courage to continue even when things aren’t perfect or easy
Scrum depends heavily on commitment both at the small scale of an individual committing to a small piece of work, and at the large scale of an organization committing to real deep cultural change. Without that entire spectrum of commitment, it is unlikely that adopting Scrum will be anything but the latest fad imposed by management or done stealthily by staff.
But Scrum isn’t the only “agile” method. As James points out, the engineering practices of Extreme Programming such as pair programming, test driven development, continuous integration, evolutionary design and refactoring are all critical. Do they have to be done and perfected first? No. But eventually, if you are using Scrum to build software (not everyone is), they do have to be done.
As a Certified Scrum Trainer, I have always emphasized how Scrum is hard, and how being a ScrumMaster is very very very hard. This is why my training class is three days instead of two. This is why I don’t encourage anyone to come to it, only people who will be ScrumMasters. This is why after the first day of my course, most students are actually feeling quite discouraged!!! It takes three days minimum for people to understand and process the incredible shift in mental model. And of course, even after three days, it is oh so easy to revert back to our normal thinking habits.
So what should people do? Do Scrum by the book. Yes that means putting a whole team in a single room. Yes it means that you have to really remove obstacles, and fast! Yes that means that your teams actually have to be cross functional (and not just in the weak sense of multi-skilled developers). Yes that means that it – will – take – a – long – time – to – get – it – right!!!!
And please, it is so worth getting help beyond just the training! If you think that I’m just trying to promote my own coaching services, please go check out:
They all have great coaches and I would absolutely way rather see you succeed than believe that I am just trying to promote my own business.
Affiliated Promotions:
Please share!
I appreciate that you make it clear in your CSM courses that while Scrum is simple, adopting it isn’t easy. I see too many teams who come back from the CSM course thinking it’s going to be easy. By about sprint 4, they’re often struggling and frustrated and don’t know where to go next. As a coach, I’d much rather help teams get started right than fix the problems that emerge three sprints later when their expectations were set wrong.
I agree that the “Agile” moniker is getting a bad reputation because it’s not a silver bullet. It’s unfortunate that it got associated with the idea of a silver bullet, but that seems to be the case for any new, widely adopted and talked about approach to developing software.
If Scrum is so hard to learn, it strikes me that even three days isn’t sufficient. In my experience, learning something difficult takes at least two weeks of intense study. Perhaps some of the bad reputation comes from the seemingly truncated learning sessions.
The trouble with “getting started right” is that even that is hard with good support. Scrum, in and of itself, is just plain hard! Not because it is complex, but because it exposes problems. There’s lots of stuff we do as coaches that isn’t part of Scrum… we do it because we’ve seen these things work to help teams before. For example, in a large organization where only some teams are using Scrum, it’s most often a good idea to get the PMO and audit and process people involved early so that they aren’t surprised when you talk about how their X-Y-Z Checkpoint is actually wasteful and needs to be done away with. But for most teams, reaching out to these amorphous parts of the organization that aren’t directly related to building software is not easy. It’s not easy because for one thing, they don’t even think of doing it!
Anyway, I fully agree that even three days isn’t long enough. I still get feedback saying people would like more time learning. In fact, I have about 10 or 12 days of training material including exercises, workshops, advanced topics, etc. Hmm… Makes me think that perhaps an extended boot camp training exercise might be worth trying! Cover “everything” (like that’s possible (I need a smiley for “sarcastic joke”… anyone know what punctuation is used for that?)).
I couldn’t agree more with both articles. However, I don’t think the length of time studying makes much of a difference. Without experience you will never get it right the first time no matter what you’ve learned. I found that after my CSM training we were using Scrum horribly wrong. All the while I was being made fun of for being “anti-agile” because I had legitimate questions about the process no one could answer. People were hiding behind Agile out of ignorance and THAT is what is damaging. Anyone who decides a 3 day course is the be-all end-all of learning how to apply Scrum is sorely mistaken. I’ve read my course material numerous times since my training and make it a point to get involved in discussions to further my knowledge and help others.
I was actually pleased to see how bad we were at Scrum and met with management to tell them why things were the way they were. It took over 5 months to re-iterate (no pun intended) what Scrum was and how to use it. We’re just now getting on track with XP practices and high performing teams but there is so much technical debt and mistakes to correct that it’s going to take a while to fully recover.
Good points, all! I think your comments about commitment are dead-on, but I’d go even further, based on my own experiences.
I think, for Agile to succeed, the commitment level has to be such that every part of the organization is being measured on how they’re contributing to the overall success of your new processes. We suffered mightily from having key components of our company (customers and product owners, most especially) who weren’t fulfilling their responsibilities and yet were allowed to continue operating that way. Requirements were incomplete, product owners were missing from planning sessions, and conflicting priorities were often set by different parties. Despite a good show of support and commitment elsewhere, this failing (among others) undermined everything else, as you can well imagine.
I believe people need to fully grasp just how critical it is for EVERYONE involved to be committed to adopting an Agile methodology, and that metrics be put in place to measure and report on how each area is doing in that regard. Without something like that, you may experience what we had happen, in which case success will be an elusive creature, indeed!