On November 3, 2011 I presented the keynote of the Agile Open Holland Conference in Dieren. During this challenging talk I discussed the current state of affairs in agile organizations and projects and the effects of the recent strong rise in popularity of agile approaches. Let’s put it mildly: there’s a lot of work to be done.
Death by dogma
Almost all organizations, large and small, are turning towards agile to escape failing traditional software development projects. Due to this strong increase in popularity of agile approaches and techniques, many newcomers will enter the field of agile coaching. Of course without the very necessary real-life experience but proudly waving their Certified Professional Scrum Master Sensei Trainer Certificate proving they at least had two days of training.
Going through the hardship of two whole intense days of training becoming a Certified Agile Jedi Knight is worthwhile!
In my opinion, as a result many organizations and projects in the next couple of years will be coached why well-willing consultants who have barely made it through boot camp, and in the famous Shu-Ha-Ri learning model haven’t yet made it beyond copying their teacher. This will lead to very dogmatic applications of the more popular agile approaches, mostly Scrum, especially when the so-called leaders in the field themselves turn to dogma. This dogmatic thinking will block the use of more mature techniques and technology in agile projects, even when these would really improve projects, or would prevent agile projects from failing. “No, you can not do modeling in Scrum” and “Burn-down charts are mandatory” are two such simple real-life example statements that I’ve witnessed some certified agile Jedi Knight make. Due to this lack of experience and the growing dogmatism in the agile beliefs, more and more agile projects will fail. Death by dogma.
During my keynote I discussed many examples of dogmatic Scrum implementations and the drawbacks from being dogmagile, building the story up from my previous posts Scrumdamentalists and Crusaders and Flower-Power Agile Fluffiness.
But maybe even more important during the keynote I also show that there is no such thing as one-size-fits-all agile. Different organizations and different projects require different agile approaches. Sometimes lightweight agile, for instance implemented using Scrum, user stories, simple planning, simple estimation, and one co-located team using post-its on a wall is just fine. But in many projects the way of working used should rather be built up from slightly more enterprise ready approaches, for example using Smart, smart use cases, standardized estimation, multiple distributed teams and on-line dashboards.
What is agile anyway?
Implementing agile in your projects starts with establishing what it means to be in an agile project. As I demonstrate in the keynote, I consider short iterations, collaborative teams, a small unit of work, continuous planning, delivering early and often, and simplifying communication to be crucial to considering a project working in an agile way.
From there you can pick and choose from a wide variety of approaches, techniques and technology. Most of them stemming from the agile era, but some of them can also be related to older (or more mature) era’s. Concluding you might say that to be successful in implementing agile in your organization, you will need to assemble your agile approach from everything that will help you implement these six agile bare necessities. Anyway, enjoy!
I sincerely think you’re right on this matter.
The Certified Courses though are quite nice to learn about the agile ‘framework’. But it’s nothing more than just a training indeed. Instead of Scrumdamentalism I like to call it ‘Wikipedia Management’. Just fill in one simple google search criteria and open up the wiki. 2 days later someone , somewhere in an organisation, has to build some kind of ‘Product Backlog’ and the only thing that person knows is the fact it has a certain predefined format…. That’s quite tricky indeed because such a small sentence called a User Story often does not mention enough functional/product context. What does ‘as an bookkeeper I want to make an invoice’ really really mean. Is it a use case or isn’t it ? That’s why some 5 years ago I started reading books, followed lots of courses, like the one you wrote on UML , some stuff from A. Cockburn about writing effective use cases where there is also a whole chapter on context. Several years later i’m still trying to fine tune my way of analysing although using SMART use cases is a solid approach which has never let me down so far.
In my opinion it’s more than necessary that agile enthusiast take a closer look at the complete story of software development. For organisations who want to think about changing their current way of working to a more agile way of doing things, I have one piece of advice. Get yourselves a solid and experienced consultant / change agent who knows the pitfalls instead of abusing a certified scrummaster in your company to widely push agile all over the organisation.
Because believe me fellow readers of this blog…. It’s not so easy peasy at all 🙂
Really looking forward to your new book Sander…. Let me know when it’s available.
My thoughts on that are more or less the same although I do not have the same credentials and experience like Sander does….
the ‘certified’ courses though are very nice training sessions to learn more about the framework and to have learn some best practices from the coach itself. I myself had the pleasure of being in a session with Lyssa Adkins who wrote a book about coaching agile teams. So there was nothing wrong with but indeed it’s nothing more than a mere training sessions.
On the other hand I truely think there is a great danger in those certificates. And it’s parallel with what Sander calls Scrumdamentalism in general.
I like to call it ‘Wikipedia – Knowledge’, some manager hears a talk about agile and thinks his whole organisation can ‘improve’ by using agile and more in general scrum.
So the manager does a wiki search on ‘agile’ and ‘scrum’ and reads those wonderful two pages and immediately delegates to his employees to start using scrum and make a backlog first you guys…..
Don’t get me wrong on this matter, it’s nice to see there are still getting more people acquainted with agile…. But… and that’s where the problems arise for me. Enthusiams is great but what does filling a product backlog really mean. Much more than writing user stories according to a predefined format. The small sentence that is a user story is not enough to understand where the product is really going to, what is the complete context regarding the product you want to build or are building.
That’s why after following the certified scrummaster course , I’ve started reading books like ‘Pragmatisch Modelleren met UML 2.0’ , ‘Writing effective use cases’, ‘user stories applied’ and much more…. Those are all about creating a clear set of business functionality in the most sensible way possible and useable in an agile environment.
It’s not only the ‘analysis’ part that has much more to do to it than just writing a small user story… think about the planning and the complexity of those stories……
But i’m not going to write ten pages long about all that.
I want to conclude with a piece of advice on that matter. If you are in a management like position and you think your organisation will benefit from using agile, think about it more than once , hire a senior consultant / change agent which has the right credentials, experience and expertise in the agile field and then get started.Instead of sending an employee to a 2 day certification course and hope he or she will be able to make your whole organisation more agile….
So Sander, i’m guessing you’re completely spot on with your blog post. Looking forward to read your next book! Tell us when it will be available 🙂
There’s something about agility that cannot be taught in the traditional fashion. I think this might be a problem in several disciplines, but agile itself requires some specific values and initiatives that cannot simply “be taught”.
I am immensely grateful to Craig Larman that run the Certified Scrum Master Class that I attended: it was 3 days long, it was deep, and the message was “this is just the starting point”. He showed something like a 70 titles book list, that was more or less required to become good scrum masters. Scary but true.
Unfortunately, when it comes to mass trainings, many people on the learning side just want some rules to follow, and keep acting like they are on the novice stage of the Dreyfus model. I guess this is both the effect of people “sent” to trainings instead of genuinely curious trainee, and also of the number of teachers who are not at the same level of the original trainers, some of them are probably not delivering the whole message.
On the other hand, this happened in even worst fashion with different methodologies (RUP ended up being dogma-driven in much shorter time just to mane one) so one might argue that despite the traditional decay curve of any methodology, agile is still doing remarkably well.