After having promoted agile and iterative approaches to software development projects for over a decade, I finally find that, like Bob Dylan says, the times they are a-changing. And for the better. Many small and large organizations and enterprises are now turning towards agile approaches, often to compensate for years and years of failing projects. You might suggest that all’s well that ends well . But…
With the growing success of agile approaches new patterns and anti/patterns arise. Implementing agile well, although promoted as being easy by many, isn’t that easy. It’s actually quite hard to get it right. Implementing agile well is a learning process, just like learning to ride a bicycle well, or learning how to master a programming language. This is where coaching on the job can and should play an important role.
Pokemon Trainers and Jedi Knights
But good agile coaches are scarce these days. So many companies jump into this growing gap and send of there consultants to far away agile training courses. Inexperienced or at most with little experience these suddenly acclaimed Scrum Masters, Lean Certified Project Managers, Pokémon Trainers and Jedi Knights are now pushed into the marketplace.
Let me predict you that this explosion of these new gurus will lead to massive agile project failure. Allow me to explain. As with most religions, people just entering the new belief tend to be far more fundamentalistic and dogmatic about their new faith than people who have lived in the same religion for years. Newbies will apply the religion’s commandments far more literally than they are meant – as the elders know. And moreover, these newbies will see there new religion as the only true source of knowledge, denying the value in other religions.
In a sense you might say we’re in the Agile Middle Ages. The new agile fundamentalists are like crusaders, full of enthusiasm, heavily armed, not very adapted or open to the new world they travel too, but with an urge to strike down all non-believers.
Agile fundamentalist in the field
This fundamentalism is best witnessed in the Scrum community. Personally, I like Scrum a lot, but too often I see Scrum certified coaches making remarks about what is and what isn’t Scrum, and even worse: what is and what isn’t agile. Let me illustrate my statement with some real-life examples.
In many projects, especially the more enterprise projects, I prefer modeling smart use cases and use these as unit of work, estimation, development and testing way over the more unstructured user stories. At quite a few occasions Scrumdamentalists have come up to me and claim that you must use user stories, otherwise you’re not doing Scrum, but instead you are doing waterfall. Modeling doesn’t seem to be allowed anyway in a Scrum project, if I believe my Scrumdamentalists. Now I haven’t read the little Red Book of Scrum, but I’m pretty sure Scrum doesn’t really push user stories as being mandatory, nor forbids modeling.
Another great example followed a picture I tweeted of my current project’s dashboard during a week when our tester was on holiday. Clearly the list of work items to test was larger than the other columns. My picture led to a remarkable comment from a certified and even experienced Scrum Master that all team members should automatically take over each others work when someone is offline. And if we didn’t do that we were not doing agile, but were doing waterfall instead.
Yes I do consider that taking over each others work is good practice, but to a certain extent. I don’t know about your project, but in my project testing is serious business, with serious techniques, that requires serious expertise. Testers do totally different work than analysts or developers. I don’t see any of my C# developers creating process cycle tests or writing functional test cases. Or even worse, the other way around. Would you seriously consider a tester to learn how to write C# code, just because one of the developers spends a week on the beach? So I guess I’m in a waterfall project.
A non-proper agile dashboard
And if you think this was the low point of my experiences, another Scrumdamentalist overlooked the picture I posted and noticed that my project has different and more stages a work item goes through than the task board he considered obligatory. We had stages such as developer testing, testing, accepting and approving, while he said that you only have to-do, working and done on a proper task board.
And dear people, is it really necessary to call an iteration a sprint, and a stand-up meeting a scrum to make my project successful?
Process fits project
I strongly believe that this agile fundamentalism and dogmatic thinking is going to stop progress and productivity. It ignores on of the basic principles that makes agile such a strong proposition – namely to improve on your process and techniques continuously to make the process fit your project, and not the other way around.
Dear people in the agile communities, please don’t try to become holier than the pope. Being agile means not trying to be dogmatic. We are not looking for the holy grail. There is no one true agile religion I’m afraid, there’s value in all of them. As the agile manifesto clearly states: we are uncovering better ways of developing software by doing it. So go out and explore.
Most parts I agree. But I disagre that a developer should not write functional tests and I disagree that testers should not learn C# or any other language used in the project. In my experience this leads to one big problem: That developers/testers say “That’s not my business, that’s the business of the developer/tester.” Instead of assuming responsibility. Also an arguement for that: Imagine that two testers are in holiday and the other two testers went ill. Do you want to produce more and more WIP instead of eliminating the constraint? If you do, like you’ve written here. You don not waterfall. But you also do not lean. Maybe yoy are agile. But you’re wasting money, because each line of code stuck in WIP is dead money!
Usually a tester in a team is a person with no expertise in programming at all, and no computer science background acquired in a high-school or university, so expecting him to learn C# programming is not something reasonable.. Sure, he can learn it given enough time (months or even some years), but that’s like changing your profession..
Uh.. I don't expect testers to learn how to program, but it can help if they can actually READ the code. Which, if it is written in the language of the domain, can be doable. By the way, most testers I know do have a degree.
@Sven You mean to say that you need to learn more then 1 skill? In other words, why not follow two studies? In my opinion, keep to your profession.; The big advantage of having different experts is that they are experts in their own field. Mixing professions (which is somethimes simply not possible) makes the expert level way lower.
I totally agree with you. Scrumdamentism is also a thing that occurs a lot by all customers who are doing a scrum project for the first time. A week ago I saw the PO starring at our scrum board. He was talking to a couple of project managers and was explaining why scrum was the best. The PO really believes that our scrum board can predict the future. At that moment I realized this: when a scrum board becomes an object of worship, scrum becomes a religion.
Haha. The taskboard as altar.
The white board marker holder can be used for candles. Would be a great picture for one of your presentations 😉