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

 

Use Service Design as a tool to challenge

Some would argue that Service Design has been around for ages, for those people that were designing and developing great products years ago, this was what they did, but didn’t take the opportunity to name it, package it and market it. Service Design, as an industry, could be dismissed as the latest reincarnation of common sense – however if it really was so simple and obvious then why weren’t we all doing it, oh how we titter at the common masses for their foolishness, uncomfortable in the knowledge we were just lucky.

Modern Service Design principles and practices are at their most effortless when there is a prevailing wind supporting those activities and their timeline, and there is a very clear vision that focuses on outcomes. Service Design is a structured approach to ensure that users are able to achieve what they need, from their initial desire to the final outcome. Within IT projects it starts with upstream investigations to ensure that what is delivered will fit neatly into the fuller user experience and then manifests more as a user-centric culture from that point on, constantly focusing on the differential between what the user has and what they need. It involves activities such as identifying the users, understanding why they want something, what they are currently doing and how they would naturally approach their need.

My experience with Service Design is less about creating great products but more about identifying and exposing poorly thought through projects. If you follow a service design approach it is very hard to accept a long list of requirements without confidence that they will deliver something appropriately sized in the users’ best interests.

It is more common in a supplier client relationship to feel the need to (and have the opportunity to) challenge the prescribed solution on a table than an in house build. We, the business, have decided we need this widget – please build the widget… This request now usually solicits a slow “Okaaaaaaaaaaaaaaaaay” from me.

The trap in front of you is to ask the obvious question, “tell me about this widget?”. The right question is, “tell me why this widget will solve your problem?” It could be that the response is a full well researched and documented study on user behaviours and needs, with a few supporting usability studies on prototypes which come neatly packaged with a user researcher to join your team. I say ,“It could be…” but really, that isn’t my experience. Careful questioning usually exposes weak assumptions and through pushing a Service Design strategy you can bring everyone to a common path avoiding too much conflict or loss of face.

Projects that proceed without a good foundation on Service Design (or common sense as it was called before it got a name) typically end in one of three situations:

• Successful with substantial changes during delivery
• Successful but over-engineered and expensive – and usually late
• Abandonment

An immediate focus on the widget proposal on the table will typically take you down these paths, I’ve been there, don’t go there.