Agile is consuming itself

The biggest threats to wholesale agile adoption within our business society don’t come from a counter proposal, they come from within. The failings of previous approaches are well known and well documented and in fact have been since their inceptions, but everyone muddled through for lack of alternative. There isn’t going to be resurgence in support for the “Good old days”, too many people can prove it wasn’t that good. Nor do I imagine a new way, a utopian enlightenment to dawn upon us, from which point all programme delivery becomes risk and issue free, there just aren’t sufficient unexplored paradigms in our approach.

If the agile movement is to die, to collapse, it will do so inwards, on itself and from within. It will suffer the fate of Robespierre, the French revolutionary who rose to power through a fervent belief in equality and support for those that had been excluded and repressed under royal tyranny. His passion and success made him increasingly blind to the consequence of his unyielding beliefs and the presence of those that coveted his position. Eventually those that would usurp him turned the populace to revile the fanatical dogma that had wrought so much terror in the name of social progress, and he met the same end that he had brought about for the late king, a short drop from Madame Guillotine.

I suggest the dangers lie in three areas, the ignorant, the exploitative and the manipulative. In all cases the issue is misinterpretation of sound decent values, either innocently or more malevolently.

The first case is ignorance. This is a hard truth I had had to admit to myself, and I am reassured to read postings from other thought leaders I admire, who have humbled themselves in a similar fashion – see here, that has given me the confidence to come clean. Years ago I probably was this person, the well-intentioned but ignorant zealot; armed with too little understanding or experience of Agile Values and human politics, and too much theory and process definition.  I was that guy howling into the wilderness standing on Dunning-Kruger’s mount stupid. You’ve may relate to these kinds of transformation attempts; process and terminology centric backed by dogma and rhetoric that is applied through contextless retrospective coherence. Trying to change behaviours and practices through process, like trying to turn the quiet shy girl at the back of the class into the lead cheerleader by tossing her a costume and couple of pom-poms.

The second case is where the revenue generation consequence of those talented individuals working in organisations to support an agile transformation becomes a motivator for themselves and others. When the Agile philosophy becomes a commercial opportunity, then predictable but none too pleasant behaviours start to emerge. Pyramid style certification schemes, and an attempt to commoditise processes and supporting tooling for the purpose of revenue rather than stakeholder value. The worst excesses of this can be seen in those offerings that do little more than relabel existing familiar enterprise operations with new “Agiley” terminology with a supporting license fee. This undermines the Agile principles by dragging it down to something much closer to the status quo for the purpose of profit.

The last case is the most dangerous, those that speak in our name to further their own agendas. The butt of many a Dilbert joke – “Welcome to Agile – stop documenting anything and now you can work faster”. This is the wrecking ball of Agile, or more usually Scrum, wielded by paranoid power-hungry, non-technical managers who feel they now have a weapon to use against their intractable, awkward IT colleagues. Teams have been made to work longer, harder, with less control, fewer standards and more interference all in the name of Scrum. New developers have been born into this environment and are left believing that this is normal, and the more experienced developers resent the dumbing down on their industry and rage against the framework because they are powerless against their management. There are hundreds of comments on blog boards of people decrying Scrum through valid complaints about business practices that bear no resemblance to Scrum.

Now imagine all three together, well-intentioned but ignorant scrum masters being manipulated by untrusting and overly ambitious management to deliver the impossible, at the expense of the developer workforce, being cheered on by a process, tooling and certification industry laughing all the way to the bank. The end result will be a profitable industry of failing projects and people in a slightly different way to twenty years ago, and critically no real improvement in the enterprise project success rate.

So what is to be done? As a consultant working on Agile Transformation; are we like a few conservationists, trying to save what is left with the grim knowledge that it won’t be enough against the rampant consumerism, selfishness and apathy of humankind?

We have to continue, to give up would be dereliction of duty, and most of us have skin in the game ourselves now, we are part of the problem even as we try to point the finger elsewhere. Firstly we should point out misrepresentation of Agile wherever we see it. We need to stop preaching and learn a little humility, for those that teach Agile theory and concepts end each class with this statement – “you now know  a lot less than you think you do and are now capable of a lot more damage than you can imagine”. For those that are working in environments that are Agile in name only, then call this out, transformation to Agile may be beyond your means but at least stop calling it Agile so as to not further tarnish what was once a noble ideology. We need to focus on delivering value, on return for our clients not for ourselves. Be honest and ethical about the contracts we take and the companies we work for.

I like the proposition that someone attributed to McKinseys (I don’t know if correctly) that we should focus on delivering value to our clients rather than to ourselves and through that the money will flow anyway.

About me:

I am Phil Thompson, an Agile Consultant, have worked at many places in many industries and with many people, mostly in Europe, mostly in the UK, mostly in London. My opinions are my own, shaped and challenged by the people and companies I have been fortunate to work with over the past fifteen yrs.

You can reach me at @philagiledesign or LinkedIn


Mini Waterfall in your Agile sprint – Consider your testing role…

How many of you are running Scrum but struggle to get the burndown to be anywhere near the target – more often than not it sits flat and then drops down (to hopefully zero) in the last couple of days. I have even seen teams whose “target” burndown is a similar shape, they’d given up ever trying to get close to that constant gradient.

This is because the teams run mini waterfall inside their sprint. Each team member has their own role and the work is passed person to person (with a note saying, “done my bit, your problem now”) just like a whole project would be in a waterfall SDLC.

The most critical of these handovers is from a Developer to a Tester. This seems perfectly sensible, we know developers, we know testers, there is a natural flow of work. However this approach is fundamentally rooted in the past, reflecting practices and technologies which should now be dim and distant memories.

Firstly the tester role used to be more of an operations role, an experienced user trying every permutation they could think of to check it works. Now we are asking them to be more technically capable so they can test pieces of a flow, stubbing out inputs or outputs.

With an incremental delivery everyone has appreciated the importance of an automated regression test suite and as that has the word “test” in it –well give it to the tester. So there are teams out there with developers writing code and the super technically capable testers writing automated test scripts around it.

Stop everyone! This is taking the traditional siloed waterfall practices and hammering them into SCRUM until they almost fit. It is inefficient and enables individuals in teams to avoid ownership of delivery.

SCRUM is a reasonable approach for work management in iterative development but it has little to say on the technological approach other than the team members should be cross functional, to really get an Agile delivery to work you need to support it with XP – and inside that is the answer to the burndown gradient issue.

Within all the other good stuff in XP is the concept of TDD, Test DRIVEN development, where we write tests inside the code before writing the actual code. The important consequence of this for this piece, is that it is the developer that writes it. So the developer writes the code AND the tests. Horror screams the testers, for two reasons:

  • “What about me, am I just redundant now?”
  • And then secondly – after calming down for a moment – “we don’t trust the developers to check their own work, developers think differently to us, we consider all the options etc”

The first is an issue, the second a valid point and the solution to the first. If we change the focus of the tester to assure the work of the developer rather than the code (with focus on the coverage and approach of the automated tests) then the role brings genuine value to the team without necessitating an awkward handover.

I’d support renaming this role to be Quality Assurance, giving assurance to the team about the quality of the work done, this frees up the term tester for where it belongs and originated from. Genuine users in operations that can use the system to ensure that it does what is needed, ensuring there is no gap between what was designed and what was needed.

Operating with this approach will ensure that all team members are equally busy over the duration of the sprint and stories are pushed to “Done” consistently over the sprint rather than being pushed to a separate Test function who then close stories out at the sprint end.

As always happy for comments edits suggestions etc. @philagiledesign

Hello World

Something to open my blog site with…

What is scaled Agile. Well we know what Agile is, been enough books on the topic. I have often said that “Agile Doesn’t Scale” – but that is just a glib throw away remark aimed at those that think they can put a process in place, and, like a clockwork mouse, just let it go.

If we run on the premise that a small scale Agile (assume SCRUM) team is effective then multiples of that team would also be effective. However this will only remain true if the inputs and outputs of each team remain true to the original team’s principles. So you know what you want, you can deliver it in the team and what you do is put into production to gain learning for future work. Having multiple teams able to operate independently and a Dev Ops capable of deploying each team’s work is a rare situation – but if you have it then you have a wonderfully scaled agile project running with the same processes and governance that you had in the original small project.

And….. back in the real world where you have features that are being delivered by multiple teams, maybe over multiple sprints (moving to a multi-sprint release model) with dependencies in all directions, well then the original process and governance model doesn’t cut it any more. Now we enter the hot topic of the moment – how to apply processes and governance to enable Agile delivery at that scale without killing the goose that laid the golden egg.

So if you are going to ignore some of the basic principles of Agile Scrum projects by not immediately releasing and adding external dependencies then you are going to need some manner of process to compensate – if you don’t then you are in a world of anarchy. It is those processes that shape what we all know have come to accept as “Scaled Agile”. There is no right way to do that (although there are some wrong ways) and I hope to give (and learn) some thoughts on that topic in future posts.

Phil Thompson

Follow me on @philagiledesign