Why are people backing away from agile? Theory one – losing sight of craftsmanship

Agile approaches are great and I even tell my friends to use them. But recently I have noticed some organisations backing away from their agile implementations.

It got scarier when I noticed that Ron Jeffries, one of the original signatories to the Agile Manifesto, wrote an article titled “Developers should abandon agile.”

It’s a good read and he makes some good points.  You can find the article here at this link.

Debate is always good, but it is scary that one of the founders of a movement is talking about giving up on it.

So what is going on, are people giving up on agile?  From where I sit there are a lot of people taking up agile approaches.

Are the founders of agile getting nervous because a new generation is taking things further than the old guard were comfortable with?  I don’t think that is the case.

Or is “going agile,” and even “being agile” failing to deliver value for the people who do implement it?

I don’t think the drivers for people going agile have changed, but I do think there are reasons that some of the people going agile are failing to gain the promised benefits.

Here I will look at one pattern of adoption that I believe leads to people missing out on the potential benefits.

This pattern involves the members of a particular team adopting some of the agile practices in order to get better at their work.  They are a bit hit and miss to start with but then they find their mojo and start to see benefits.  Then people in other parts of the organisation decide to help the team and also hope to bring the benefits to the rest of the organisation.

So far so good ….. but I think sometimes things go wrong because the team lose their autonomy and their focus on good craftsmanship.  It is not hard to fix, but failing to fix things at this point makes it very difficult to gain real benefits down the track.

Stick around and I will explain what I mean.  In future articles I might explore some other patterns that seem to lead to people losing their way.

Forgetting that agile is about mastering a craft

If you look up the meaning of “agile” in the dictionary, then you will see that it means “quick and easy of movement.”  But movement towards what?

Agile is not really a goal, it is a toolkit that makes it easier to achieve a goal.

I remember encountering agile a long time ago and then going to a training course to find out more.  But my goal was not to become part of a movement or to develop a new mindset.  I worked with a team of business analysts and we were looking for ways to get better at our craft of “doing analysis,”

This is similar to the pattern I have often observed in multiple scenarios.

The first teams to adopt agile in the organisation are looking for a way to get better at their craft.

Sometimes the team consists of testers, project managers or BA’s.  Sometimes it involves non-technical teams.

Most frequently, it involves a group of developers and so I will explain the journey in terms of people who write code.

But the key is not that they are IT people, the key is that the people who are adopting agile take pride in their particular craft and want to get better at it.

Some people take up a trade or profession in order to pay the rent.  But others are better off – they find work that they are actually passionate about;

• Typically IT developers are in the later group – they are passionate about IT development.
• Potential developers find that they honestly love coding, algorithms and problem solving. They learn to code and then get a job in an IT team and things are great;

For some reason though, organisations seem to develop debris or overhead that distracts and annoys the people who are trying to focus on doing good work.

• Some of the distractions are necessary – expense claims, team meetings and time sheets.  Other impediments are unnecessary – politics, dealing with error-ridden legacy code and having to to code against long-winded and unhelpful instructions.
• Regardless of the reason they exist though, distractions get in the way of people doing what they really want to do – solve problems by writing great code.

Now the people in the team are frustrated.  The company needs them to do good work, they want to do good work and they love the work they are doing, when they can do it.

Then some of the team discover some agile techniques.  These might include team practices like Scrum or Kanban.  More importantly though, the team adopt some good technical practices that help people write better code (or in the case of BA’s technical practices that support better analysis).

As the team adopt better practices, they gain control over their work, impress their customers and show management that, if unleashed, they can deliver real value.

The agile approaches also help because they shine a light on where the organisation’s processes are holding the team back, so the team get permission to remove unhelpful distractions.

As a result, agile practices and the team’s passion soon defeat the forces of evil that are holding them back.  The team starts to write great code and starts to feel real pride as a team.  Times are good and everyone is getting excited.

There are frequent examples of this – you can see one here, in a brief linkedin post from Renlester de Guzman at Fave.

 But now there is a critical point of failure.  The people in the wider organisation notice that the team is doing good work and they decide to help.

“We should apply that everywhere,” say people in the organisation

“They are doing well, but they can do even better if we standardize some of the processes they are using.  They seem a bit chaotic at the moment,” say others

Helping the team would be great if it involved asking the team what they need and then providing some of that.

But unfortunately in many organisations, people see things through the lens of their current operational procedures and so they adopt agile practices that are actually reproducing the current way the organisation operates – just making things faster and more agile.

“When I let go of what I am, I become what I might be,” – Lao Tzu

“This is great – let’s do what we are already doing but faster, with post-it notes on walls and with a lot of meetings,” – some corporate guy

What I mean by this is that rather than really understanding what is going on, or being truly curious, people try to create agile versions of everything that they have already got.

This is when the team loses its way.  Rather than being empowered to focus on their craft, they are forced to comply with new “agile” processes, tools and rituals.

As a result the team are once more inflicted with overhead and distractions.  The name of the new distractions might be “agile” but the impact is the same as before.

The team become a self-managing team with a manifesto, they overthrow the establishment and then they find that they are losing their freedom, their ownership and their passion.

The people in the team have new  role titles and jargon – but, just like in the animals in the book Animal Farm, they seem to be back where they started.

“The creatures outside looked from pig to man, and from man to pig, and from pig to man again; but already it was impossible to say…” – Quote from Animal Farm by George Orwell.

When this happens, organisations might still make some improvements around the team and they might even see an improvement in their culture.  But there is always something missing.

The revolution is no longer driven by small passionate groups at a local level and it is no longer allowing passionate people to focus on practicing and mastering their craft.

Without passion for their craft and without a focus on local improvements made by small, tight teams, a lot of the value of any agile approach is lost.

You can have an agile mindset, but agile is really meant for the artisans in the workshop. If they cannot be unleashed to focus on the work they are passionate about, then the whole organisation will fail to deliver great work.

Naturally, when the organisation fails to deliver great work, people slowly lose faith in making the changes demanded of them as part of the “agile journey” and then they will eventually move on, ditching that journey for a new one.

“Nature does not hurry but everything is accomplished” – Lao Tzu again

So the key here is to unleash and protect the people practicing their craft. Teams will move at different speeds and sometimes progress will be really slow.

But you can afford to scale agile slowly and you can stumble during the journey, if you keep coming back to supporting local teams in their work and ensuring that they can take ownership of their craft.

So spend your money on making sure people have time to work together and time to do their work with pride and quality.  You will also need to ensure that the team can see the outcome of their work, rather than merely completing something that is sent off to someone else to do some work on.

If the team focus on their craft they will do good work.  If the team is forced to focus on practices that distract them from their craft, they will not.

In fact, if the team is producing value, who really cares if they are using agile practices or other approaches.  They are doing good work and they are passionate about it.