Agile software implementations – get back to the basics

‘It may quack like a duck and walk like a duck, but is it a duck?’

Many of us are familiar with the above anecdote. My take on it, especially when it comes to agile implementations, is usually the opposite. It may look like agile, the right vocabulary is being used and the events of scrum or some other framework may be happening, but alas, it is not agile.

What objective test can we use to determine if our agile implementation is authentic? It should be framework agnostic and help us to understand if implementing agile was an exercise in implementing a new rule-based system or a new delivery and thought paradigm.

My answer to this question is so simple you would think it would be completely self-evident. Well, as you will see, you would be wrong; simple perhaps, self-evident not so much.

The journey

A couple of years ago I started playing an instrument. I have a good teacher and what my teacher did was start my journey in learning, and hopefully, one day, mastering the instrument, with the basics. In fact, my teacher went on to tell me that mastering the basics was the very core of learning to play this instrument. That no matter how “advanced” I become, a solid foundation in the basics and regularly revisiting those is the key to being a great or even masterful musician.

Paul Gray, Head: Development Technology Solutions, DVT

---

It may seem self-evident and even logical that being solid in the basics is key; however, why don’t we stick to the basics when we implement agile? Why is the focus always on the framework? Are most practitioners completely oblivious to the basics? Perhaps.

Here is a test for you, the discerning reader. If you are in an organisation that calls itself agile, ask yourself or your colleagues if they can state four principles of agile and two values. There are 12 principles and four values, so this really is an easy test. I have done this test many, many times and, on average, about 10% of people can answer the question.

That would be like going to speak with a symphony orchestra and asking the musicians how many of them know what the circle of fifths is. I can guarantee you that if an orchestra only had 10% of musicians know the answer, they would be the worst orchestra on earth. No one would be listening to them play because at the most basic level, they simply would not know how to play together. They would not be able to align their various instruments or disciplines without an underlying foundation to hold them together.

The foundation

So, as agile organisations, our foundation must be the principles and values as detailed in the agile manifesto. At the risk of making this article overly verbose, I have included all the principles and values of agile in this article.

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity – the art of maximising the amount of work not done – is essential.
• The best architectures, requirements and designs emerge from self-organising teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Then the values:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

So when we are asked to audit or evaluate an agile implementation, this is where we start. Let’s start with principle one. If our highest priority is to satisfy the customer through early and continuous delivery of valuable software and we are not doing that, are we agile? In 95% of cases, this is where most audits end. Principle number one is not in place. If we cannot get the very basics right, how can we continue implementing frameworks, customising frameworks and hoping that, through processes, we can overcome a basic misunderstanding of agile?

Dark scrum

Most companies have implemented scrum. It is by far the most popular agile framework. I am personally a big fan of scrum done right. There are myriad ways to do scrum wrong, so much so that Ron Jeffries has coined the term Dark Scrum. If you Google 'Dark Scrum', you will find the articles by Jeffries, who just happens to be one of the original agile manifesto writers. Ken Schwaber and Jeff Sutherland, who also happen to be members of the original agile manifesto, were the creators of scrum. Scrum at its very heart has the principles and values of the manifesto ingrained. If one were only to diligently follow scrum according to the guide, you would still see that the delivery of working software to the client is the core tenet.

Organisational legacy

Looking critically at agile implementations, whether they be scrum or another framework that fails to deliver the expected results, one thing becomes immediately apparent – the inability of the organisation to self-organise around the new agile way of work. Management wants to keep the incentive structures that have proved useful in the past and the command and control mindset around budgets and costs remain fully present and ingrained.

The problem in most cases is the incentive structures are counter to the agile principles and values we have discussed. Managers are still being rewarded for getting their little piece of the puzzle implemented, often at the expense of other teams and their deliverables. Value is a word that is used extensively, but there is no standard organisational definition. The product vision is vague – if it exists at all. If it does exist, it is just pretty words marketing put together to make striking visuals either online or on posters placed around the office.

It bears reiteration that if your company’s incentives and policies run counter to the core of agile then you are not implementing agile. Your organisation will remain the same at the core, except for having a nice new shiny skin to possibly attract developers to their doom.

Agile coaches are not…

There is truth to the assertion that agile implementations done with some form of professional coaching succeed at higher percentages than those that do not. However, that should not be taken as proof that all coaching is equal. This is decidedly not the case. What is being passed off as scrum mastery or agile coaching at times borders on the criminal, essentially being tantamount to fraud. When these implementations of agile inevitably go wrong, it is agile or the framework that is blamed. The true culprits are the very people we as a community trusted to implement agile in a way that serves both the organisation and the agile community.

How to spot the fake

This issue to me can be oversimplified. Are the teams in the organisation delivering working, production-ready software at regular intervals that add business value to the organisation they serve?

If not, then do we have a plan to get there? And should we be calling ourselves agile until we do?

There are too many organisations that plead agility and have not delivered production software in a year or more. That is simply disingenuous of the moniker agile. It sets a poor example within the organisation and it gives agile an undeserved black eye.

As an agile community, we have to do better. It is up to us to hold onto the truth of agile and not be swayed by organisational politics. If we will not uphold the very principles and values we purport to serve – you can be sure that the implementations of agile we are involved in will fail.