The Agile Crime Scene

"I am fascinated by crime scene investigating. I swear, I wish I was a crime scene investigator sometimes!" - Kim Kardashian 

Sometimes, Agile transformation can seem like it's 10% maximizing the opportunity and 90% understanding the crime scene. It shouldn't be that way, of course, because an Agile way of working brings great opportunities. There's the chance to harness innovative potential, to improve existing value delivery further, and for people to become better valued and moved towards doing better yet. Any drive for change ought to be well-meaning. So, while an Agile transformation program may not be entirely predictive, you would think it ought to be at least an honest one.

Unfortunately, though, no Agile change initiative is entirely free of the human foibles that can sour any large undertaking. The problem is that the change required is both broad and deep and the organizations concerned are often large ones. There are usually many stakeholders involved, some with vested interests in the status quo, and others who seek to build empires. A failure may be encouraged as much as a success in order to give certain players a personal advantage.

For example, a CEO may wish for a company to become more Agile so that it is not disrupted out of business by more innovative competitors. Is this desire shared by middle-managers, though, who may prefer the established orthodoxy as a known and serviceable platform for furthering their own narrow and immediate ambitions? A manager's interests may not entirely coincide with those of the company. Some could merely wish to sit pretty as they see retirement approaching, while others might hope to stand on people's heads and climb the greasy pole that leads to more desirable positions in the same or other establishments.

In short, Agile transformation is as much a political exercise as it is a technical one. Unless the associated risks are understood and managed, the corrupt body politic of an organization may curdle an Agile change program before it even begins. It's one thing to hear people claim support for "going Agile".

Do they really wish to go through that process of deep and pervasive change, though? If so, why? Does each person truly understand that they must change, too, if the benefits of enterprise transformation are to be attained? Would some rather suppress that change and the inconvenience or uncertainty it would bring? Would they prefer to subvert the initiative or to kick it into the long grass? If they do indeed have that motive, which among them would have the means to do anything about it? What opportunity might there be for them, instead of nurturing Agile potential, to destroy it instead?

Someone's apparent support of "going Agile" may not be as genuine as it appears. All sorts of factors can be at play. Those most outwardly keen on the initiative may have a rather different agenda, and the means and the motive to deceive others. When you arrive on an engagement as an Agile coach, Scrum Master, or other change agent, you are likely to have no real picture of this tangled web or of the events within it. An Agile transformation ought to be approached as if it were a crime scene.

Interviews with management can expose telling evidence. You can expect plenty of bombast and braggadocio about agility and how critical it is to the organization. The first thing to assess is how well the precepts of an Agile way of working are understood at this level. For example, managers could be operating on the understanding that Agile just means doing things faster and cheaper. Yet, as any old hand knows, the real purpose behind Agile practice is to ensure that the right value is delivered at the right time to appropriate quality and that waste is removed and new opportunities leveraged via ongoing improvement. Hence, change may actually prove more costly, at least in the short term until the associated practices are normed. Also, a few artfully placed inquiries can sometimes expose a seemingly hearty and vigorous change initiative as bluster. Try asking managers the following questions, and study their reaction and body language carefully:

• Who here really wants Agile change?

• What is your transformational vision?

• How will you provide sponsorship?

This might be before you've even met with the teams themselves. They may have a very different take on what the transformation program will mean at the coal-face, and of what would be necessary for it to succeed. In fact, they may not even be teams at all, in the sense that teamwork might be lacking or is not understood, sponsored, valued or respected. Indeed, much of the vocabulary of Agile practice can be subject to misunderstandings at a time when it does not yet represent any sort of shared experience.

Interviews can thus only take you so far because the words that are used to describe change can suggest different things to different people. One person's Sprint retrospective, for example, may be another's quarterly stakeholder review. One team's planning session may be a Project Manager's assertion of the commitment that the team is expected to make. None of the terms used may correspond to genuine Agile practice. You must therefore also examine the tangible evidence which an agile transformation attempt might have left in the field.

One very useful piece of evidence is a Scrum or Kanban board (or the attempt to produce one). A brief look at such an artifact can expose some of the uncomfortable truths about a transformation and the constraints that might be sabotaging it.

How much work is in progress? What is the evidence of throughput? What work is blocked, and why? How often is the board being updated? Who is acting to resolve impediments? What evidence is there of ongoing refinement or of replanning to meet goals? What metrics and measures are being drawn out? What evidence is there of team ownership of work, and of team commitment? How is the idea of "done" represented and met and how is quality assured? How is waste being tracked? What is the policy around defects and technical debt? Is planned work being pre-empted, and if so why?

In short, does the team operate under clear Scrum or Lean Kanban rules at all? Many do not and will have fudged their way of working in an attempt to reconcile the contrarian demands which are placed upon them. A fast-track lane may be used, for example, by means of which unplanned work is expedited. The result is that the team is expected to follow a Scrum approach, while the "real" work from an unchanged organization continues to be pushed onto them.

Sometimes, in an attempt to validate this position by giving it a name, it will be mistakenly referred to as Scrumban. This is unfortunate because Scrumban was originally formulated as a means to reduce batch sizes and to improve lean efficiencies, not to hobble teams with irreconcilable demands under the illusion of Agile practice.

Fake Scrumban is nevertheless a useful tool for analyzing the Agile crime scene. It can expose the willingness of managers to promote real change versus a desire to merely spin it and leave employees to pick up the mess. The real appetite within an organization may be for "alternative facts": to claim that productivity has increased when it is story points and not increments that are being delivered; to claim that teams are working in Sprints when there are no meaningful Sprint goals; to claim that value is being provided when there is no clear product owner or business stakeholder to account for it. The real facts can be exposed by a team board even when it represents the most botched attempt at transparency.

In the next article, we'll look at the pathologies of fake Scrumban in more detail and at what can be done to improve an agile way of working so fakery is eliminated. Over the coming weeks, we'll elicit the three types of Scrumban that are most commonly manifested and see how each represents a stage of maturity that can help an organization on its agile journey. Remember, no matter how serious the Agile crime scene, we do not seek to punish but to bring about restorative justice.