The Agile Developer – “they may take our projects, but they will never take our freedom!”

One of the underlying principles of Agile and consequently areas of activity in an Agile transformation programme is Empowerment. I am a big driver of empowerment in my explanations and preferred implementations of Agile delivery – and it takes time.

 

There are two challenges  – firstly encouraging people that have been micromanaged to step up and take decisions, secondly to encourage people, who until recently have been making decisions, to back off and at most facilitate team discussions to make those decisions.

Enabling those things to occur is a complex and difficult challenge but that isn’t the thrust of this post.

Assuming that this has occurred we now have a team of empowered professionals that are shaping their world and the delivery of their product. They are in some context – free. I have heard Agile referred to as, “developer emancipation”. The teams have gained their freedom and the natural passion this evokes in delivery can be related to the soaring of a bird or the breaching of a whale, an expression of joy within their environment.

 

But consider a caged bird – which sang happily in the cage, ignorant of what lay beyond, or of the feeling of the wind beneath it’s wings. If you set the bird free and encourage it to fly and fend for itself … it will never return to the cage; and if you do capture it and return it to the cage, will it sing as sweet?

 

There is a risk in a non-committed Agile adoption that if you develop genuine Agile culture in a team and then opt (for holistic organisational cohesive reasons) to roll back to a waterfall model, then you are forcing your now “free bird” back into the cage. It is one thing to have never had responsibility or freedom, but to have had it, and then had it taken away can crush the spirit.

Organisations when considering an Agile adoption need to be cognisant of the risks they are undertaking. The change involved is not simple or pain-free, rolling back may suit those that never embraced the values, but for those that did achieve it, rolling back will be even more destructive than the initial adoption. I would warn that those that have tasted freedom, will not accept confinement, and if the organisation cannot sustain, or compensate for it, then they may fly outside to freedom.

How to measure your Agile delivery?

I am often asked what to measure in Agile delivery. The common measure appears to be velocity, which I concede is useful to track and is also readily available (assuming scrum) but, as is well discussed in articles and blogs, it can be dangerous to measure this publically as it morphs into something that is judged. It can end up be held it as a target for the team and then Goodhart’s law kicks in https://en.wikipedia.org/wiki/Goodhart%27s_law and what was useful information is now a manipulated artificial construct to give the desired answer. (Using it internally to help project delivery forecasts is very sensible – just don’t assess the team against it).

So given that, what would be a sensible answer? I would advise digging a little deeper into the question rather than giving a snap answer. Information is only as good as the decision made off the back of it (and by extension information provision when no decisions will be taken is waste). Why do you want to measure the Agile delivery? And there are a few honest answers to this:

  • I want to see how much value the team are delivering
  • I want to ensure the team aren’t slacking off
  • I want to understand how the team are performing / struggling

Each of these really justifies a different approach.

For Value you need a discussion as to where the organisation perceives value – and this usually causes some uncomfortable moments when comparing existing process to fundamental Agile values – Working Software over Comprehensive Documentation and Working software is the primary measure of progress. The real measures should be associated to the benefits the organisation reaps as a consequence of the software but that can be a little unfair on the team (as they are not responsible for the requirements) – but critical for the organisation as a whole. Considering just the software delivery then Cycle Time is probably the best measure. How long it takes from idea to delivered software. Measuring, and by extension managing, this will also encourage the organisation to break their deliverables into smaller units. The benefits of the delivered work should still be tracked to avoid a situation where a highly efficient software delivery outfit rapidly and consistently delivers a stream of valueless changes.

The “I want to avoid slacking off” is a difficult one, and is probably always just under the surface, even if they say value – they may really mean – I need something to beat the team with. Despite what they say, what we really have here is fear of loss of control, someone who maybe accountable but has little influence over delivery. This suggests a structural issue with people put in management positions abstracted from delivery, and it also suggests a culture where trust is lacking. The Product Manager or Project Owners on the engagement should be close enough to the teams to have an opinion on current activities and levels of engagement. They will have a first hand understanding as to the reasons behind delivery ups and downs (reflected in velocity) associated to complications or setbacks identified in development (perfectly normal and expected in a complex industry). I usually suggest these people provide sprint activity information to the programme, which can decrease overtime as the management structure adapts.

The third request is a little refreshing and implies a maturity often lacking. This says we are concerned about value – trust the team and want to know when to try to help to support them. To understand what to measure here requires a little “Genba”, real world observation of how the team copes with adversity. Systems are inefficient when operating at 100% capacity, any change to an input variable that worsens the situation will cause failure, so the more dynamic the system the lower the optimum operating capacity. The difference between the optimum and the maximum could be considered contingency – if you want to give support to a team, measure the use of that contingency. This will give an indication of when and by how much the team is struggling and therefore when to act. This could be overtime, or compromising the Definition of Done, items added mid sprint etc.

As a metaphor consider a racing yacht, if you just record the speed then you may miss the unsustainable efforts the team are making to achieve it. Instead note just how many people are hanging off the side of the boat – and how long they have been there, they can’t hold on forever – and if they are made to, then the yacht will speed along until they drop off, at which point the yacht won’t slow down, it will capsize.