There Is No Agile

15th Jun 2014Aaron

I spoke at Agile Yorkshire this month on a topic that I have touched on in my blog a few times.

“There Is No Agile”

When I talk about this topic, I am referring to the fantastic Riftwar saga (“There is no magic”) as well as the late, great Bruce Lee, who saw all martial arts as one and did not artificially split those arts into multiple schools and divisions.

I love Agile. I run an Agile business. But I see so much bad Agile. So many people (and sadly consultants) these days have read the book and watched a few videos, but have never run an Agile project and have never stopped to think about what they are doing. I guess a lot of this comes from having something to sell. A lot of consultants, coaches and trainers out there are simply trying to pedal their preferred falvour of Agile (Scrum, DSDM, XP etc) rather than trying to find a deeper truth about the workings of a team.

In the last year or so, I’ve seen a few symptoms of these kinds of problems with Agile transformations.

Problem 1 – Dogmatic Adherence To A Method

“Because that’s what it says in the book” and “That’s how we’ve always done Agile” are stupid and counter-productive. The soul of Agile is change. Not unrestrained, purposeless change, but change for the better. Trial and error or changes based on theory – it doesn’t matter. Agile teams are like scientists. Agile teams are open to questioning everything. Agile teams understand that the things that they hold true today (“The Facts Of Agile”) will change over time as they learn and improve. Authority and Certainty are very attractive to organisations. They give the appearance of low risk. Authority and Certainty are illusions. Just because someone has written a book or delivered a keynote (and I’ve done a few!) about Agile doesn’t mean they know about how Agile should apply to and work on your team. Authority also allows an organisation to delegate responsibility for its software development efforts to an external party which means that no-one in the organisation will accept responsibility when it all goes wrong! Agile trainers, coaches and consultants should be focussed on (apologies for the cliche) teaching people to fish for themselves. Finally, remember that Agile is supposed to be the key to unlock your cell door. It was never supposed to be a prison to contain you.

Problem 2 – A Single Rhythm For All

This is one of things I find most puzzling about Agile processes that are in place at organisations. Scrum in particular plays a role in establishing a single rhythm for all activities. Consider a typical Sprint / Iteration / Timebox:

Day 1 – Sprint Planning
Day n – Do some work
Last Day – Sprint Review
Last Day – Sprint Retrospective
Last Day – Measure Velocity
Last Day – Deliver Increment Of Software

I guess ten or fifteen years ago, this kind of idea was revolutionary, but haven’t we learned anything in the intervening time? Why should you only do one Review per sprint? Maybe you should be doing a daily demo to your customer. There is no reason in principle why we should only deliver a single incremement every Sprint. Why not deliver every day? Or twice per day? If you can’t manage a daily delivery, discover the problems preventing you and solve them! The measure of value we are interested in is working, delivered software. More frequent delivery equals more frequent feedback equals “insanely great” products!

Problem 3 – Agile Teams Don’t Include My Job

Thankfully, this is a little less prevalent than it used to be. There was a time a few years ago when testers were being told that they had no place on an Agile time because “the developers do their own testing on Agile teams”. Terrifying nonsense. Agile teams need professional testers more than ever. See Agile Testing by Janet Gregory and Lisa Crispin if you are interested in this topic!

The second most nervous group of people in Agile are Project Managers. Other people love to tell the PMs that they are redundant in Agile teams. However, experience shows us differently! Agile teams need PMs more than ever, especially when working at enterprise scale. Simply put, the PM can be the most effective shit shield that the team has. At the enterprise scale, teams have a large number of third party dependencies to deal with. The classic Agile solution of “eliminate the third party dependence” is not going to work at this level – there are simply too many dependencies! PMs regularly talk to and manage

Senior Managers
Hosting
Partners
Deployment
Client IT
Suppliers
Technical Authors
Trainers
Marketing
Sales
Commercial
Contracts
Facilities

and many more. The team simply don’t have the resources to manage all these people themselves.

Problem 4 – Unhappy Teams

I hate to see unhappy “Agile” teams. In fact, unhappiness is a sign of a lack of Agility in a team. Agile methods do not fully address the creation and maintenance of great teams. Teams need the classic Purpose, Autonomy and Mastery to function. They also need to be a tight cohesive unit. This means that their skills and personalities need to be complementary and compatible. A little bit of psychometric testing can go a long way to explaining why a particular team is miserable and sick.

Unhappiness in teams most frequently comes from a feeling of being ignored and constrained. The team may not feel that they have room to be creative. Interesting, the Ferrari Formula One team is struggling a little at the moment and their solution has been to give their teams more freedom to be creative. All too often, when projects are going badly, the prison walls are thrown up and the creativity to solve problems is restricted!

Problem 5 – Declining Velocity

Increasingly, I am working with Agile teams whose velocity has started to slowly creep down. The teams will relate anecdotally that they are feeling less productive than before, but they can’t work out why. There can be a sense of fatigue on the team from the relentless cadence of Agile delivery. It is important to recognise and combat this. Your team is going to need some down time occasionally, regardless of whether this is part of your formal method or not. Since it’s a World Cup year this year, my team all had an afternoon in the pub with a hundred packets of football stickers each. We also have some snazzy new CTU mugs (thanks Jack Bauer)! Other clients of ours have run Engineering days where the whole team gets together our of the office and runs their own anti-conference. Another team opens a branch office in Portugal and team members can go out there to work. It’s all about celebrating our success and taking a few hours to relax and draw breath. I think knowledge workers need this kind of relief periodically to avoid burnout and cadence fatigue.

Nick is the CEO of McKenna Consultants Ltd, based in Harrogate, North Yorkshire, UK. Nick is 1 of only 6 Certified Scrum Coaches in the UK. McKenna Consultants are a professional team of computer programmers delivering the highest quality software specialising in a broad range of technologies for windows, web-based and mobile applications, including apps for the iPhone, iPad, Android and Windows Mobile. McKenna Consultants also deliver Agile coaching, consultancy and training to organisations of all sizes. For more information on the services that Nick and McKenna Consultants provide, please visit:

Share: