Caroline Clewlow avatar

A Hammerhead Shark versus James Bond in Speedos

A  Hammerhead Shark versus James Bond in SpeedosI’ve often found that most of the questioning about the worth of agile tends to come from the Project Management community. That’s not a criticism on PM’s but an acknowledgement that for them it’s probably more difficult to see how this agile concept can work.

Traditionally PM’s have tended to need their eyes pointing in different directions – one on the day to day development activities of the team, the detailed planning and daily progress, and one on the bigger picture, the long term roadmap and strategic planning side of a project. And, unless you’re a Hammerhead Shark – this is always going to be a tricky feat.

The trouble with agile, or more accurately, the trouble with some people’s interpretation of agile, is that it can be seen as an excuse to just focus on the tactical side of planning which leaves PM’s wondering what happens to all the stuff their other eye is usually pointing at.

So does being agile really mean ignoring the high level strategic side of managing and planning a project? Will the scent of burning Prince2 manuals soon pervade?

Fortunately this is not what agile means at all – in fact Scrum, which we all know and love, is pretty keen to remind us that we should still do release planning, risk management, and all those important things, it just doesn’t presume to tell us how to do them (in much the same way as it doesn’t tell us how to breathe, eat, sleep or do any other number of bodily functions we should still be doing whilst we’re Scrumming). What we are left to figure out for ourselves, as fully capable agile dudes, is how to ensure that we can stay agile for the long haul, which means having a sustainable and scalable approach to agility.

So how does that work? Is it really possible to add the governance, compliance, risk management and high level planning elements of managing a project to an agile approach without losing the agility? (Let’s hope so, for agile’s sake, because it is clearly and undeniably necessary).

Well, yes, of course, it is possible – otherwise agile just wouldn’t work. But it has to be done in a certain way. Let’s face it – you wouldn’t send James Bond out in full suit of armour, a wetsuit, padded ski suit and a parachute every time he went on a mission. Not only would it be a tad cumbersome, it would also be unnecessary (given that sometimes he gets away with just a small pair of Speedos). What you would do is give him exactly the right amount of kit required for a given situation. The same applies to agile. What’s needed is exactly the right amount of governance, planning and compliance for a given project – no more, no less.

So hang on – what have we got so far? James Bond in Speedos and a hammerhead shark. Which one is the PM? Well in a way it’s both, and neither. Confused? Good. Me too.

And I guess that is the point. A PM’s job is not easy and while they would love to be 007 in speedos (figuratively) – agile, unencumbered, able to work quickly and focus on getting the job done, they still need that hammerhead with one eye on all the ‘other stuff’.

I don’t think we can ever get rid of all that ‘other stuff’. It’s necessary and important. But we can minimise it so that only the right amount of ‘other stuff’ is put in place and we do what NEEDS TO BE DONE, building up from a minimal set (should I mention speedos again?) rather than starting out with everything, including the wetsuit and the parachute. This then, in essence, is the key to disciplined agile.

The PM still needs and will always need to be able to look at both the strategic and tactical side of a project, but with this approach maybe they need be less of a hammerhead. With agile self-organising teams the tactical planning side of a project is very much a team effort and, along with release and sprint burn-downs, daily stand-ups and sprint retrospectives, the tactical management is much less of an overhead.

So maybe, now, a normal shaped head will do, with just two eyes and some kind of innovative mechanism that will turn that head, allowing the PM to focus on the strategic but throw a glance towards the tactical when necessary.

Or maybe I’m just sticking my neck out.

Learn more about lightweight essential governance for agile projects.

Read the article: Agile and SEMAT - Perfect Partners.

The Ship of Theseus

Readers from the UK mainly may remember the “Trigger's Broom” scene from Only Fools and Horses. Trigger claims he's been using the same broom for 20 years - but then states that it's had 17 new heads and 14 new handles in its lifetime! Some of the more philosophically aware among you may recognise this as Theseus' paradox or the Ship of Theseus. The question of course being: does an object which has had all its component parts replaced remain fundamentally the same object? What am I talking about you may well ask? Well, whatever your take on this particular paradox there is certainly a way we can apply this to the idea of teams and their agile maturity.

Consider a team of 5 who are developing a product. They are all new to this agile way of working but very much bought into the principles. After a period of intensive coaching they begin to display all the correct behaviours and, as such, demonstrate marked improvements over time in their delivery frequency, quality of delivery and general productivity – not to mention team motivation and morale. This team become, in fact, so good that they are soon completely autonomous (within the constraints and scope of their specified objectives) and are soon left to their own devices. The proof of their ability is, after all, apparent in the satisfaction of their customers and the quality of their product.

At some point, for no specific reason, one of the team members leaves and is replaced. Shortly after this the team lead is moved over to take on a struggling project and a new team lead is brought in. Two out of five of the original team have gone. Perhaps then a further team member is also swapped out for someone else. Now the balance has shifted and less than half of the original members remain. There is no guarantee that these new members are bought in to the good behaviours displayed by the original team but because the team has always been so successful they are left to continue with no intervention.

At what point is this team no longer the original, established and successful team? At what point should someone intervene to ensure the new team members understand and can adopt the previously embedded behaviours? If this is now a different team should it be treated as such and be given the attention and support that any brand new team would be given when forming and establishing its practices? If nothing is done until the effects are seen, for example in a drop in quality or productivity, then this is too late. At that point the bad habits have already crept in and, it's a lot easier to give up biting your nails if you never started in the first place.

Trigger's broom was not the same broom and a team where the majority or all of the team members have changed over time is not the same team. The onus is on good management to recognise the implications of these changes and ensure new members are introduced to the team's proven ways of working, behaviours and culture from the moment they join the team.

Giving Empowerment or Taking Autonomy – Part 2

Read Part One here.

Let’s explore another aspect. Imagine an individual or team where the desire for autonomy or empowerment does not exist. This may sound unlikely but there are more examples of this out there than you can imagine.

In a traditional command and control organisation, dependent behaviour for long standing employees is often ingrained into each employee’s behaviours. In fact, if you are an individual who craves independence and self-determination then you are unlikely to become a long standing employee at this traditional command and control organisation.

This behaviour manifests itself as more individuals, who want to be told what they need to do, when they need to do it, are brought into the organisation. These individuals do not want to be responsible for making decisions about how they should work, when they should work and what tasks they should be performing.  By no means am I condemning this kind of behaviour. The “mechanics” of a team can be very important and as long as they participate to a certain extent in the team “independence” then their ability to complete the tasks they are given can be extremely beneficial. Read More

Giving Empowerment or Taking Autonomy

Part One

I’ve been working as an agile mentor for a few years now. (This is a mentor of agile software development teams, not a mentor of all things bendy – just so we’re clear.) In this role, I’ve built up a fair amount of experience in helping teams overcome technical /process problems and I’ve recently become interested in the softer side of agile software development teams – the psychology behind agility.

It all started when I watched a video on YouTube “The Surprising Truth of What Motivates Us” which is a summary of the book of the same name by Dan Pink.  By pure coincidence, on the same day I watched the Youtube video, I read  some review comments on a paper that debated whether the term “empowerment” or “autonomy” should be used when talking about the goals for true agility. It was an interesting discussion and it made me question some of my previous assumptions.

The first question is – what is the difference between autonomy and empowerment? A colleague said that in the simplest terms empowerment is given whereas autonomy is taken. If you look at definitions of the two words in the simplest form, they are:

Autonomy - the power or right of self-government

Empowerment - the giving or delegation of power or authority; authorization

Read More