Author: Cara Talbot

Introducing Agile to an organisation, as with any change program, means significant disruption. The way we do things is no longer the same. We no longer have our traditional rulebooks to clearly define what our roles are, how we’re supposed to engage with each other, or how we should go about our work.

This has heightened anxiety to some degree either consciously or unconsciously for almost everyone coming into contact with it. What’s my role now? How am I supposed to know what I should be doing? What if our team fails? What if I fail?

Most have dipped their toes in the water, and have grown in confidence as successes have been achieved. Some have quite radically removed some of the traditional roles altogether and claimed early successes. What risks might have they introduced critics would argue? It’s all a bit too early to tell. Some have turned into what is being coined as ‘Agile Purists’ where they will argue to the death about sticking to process over pragmatism. Perhaps this is because a natural inclination for some might be to seek new (Agile) rulebooks to replace the old; to firm up the ground beneath their feet and feel secure and stable again.

The irony is that debating at this level stunts productivity and can cultivate fear, uncertainty and doubt within their teams by challenging who should be doing what role instead of simply enabling the team to get on with the business of delivery. Teams can lose sight of their end goal.

My observations in attending the recent Agile Australia conference in Melbourne perpetuated this theory. No matter the viewpoint or appetite for risk, discussion threads resulting from the presentations and workshops were often on the following sorts of themes:

• All design must be done up front/ no upfront design at all; get rid of the Architects!
• Iteration Managers vs Project Managers. Get rid of the PMs; IMs aren’t really needed!
• Business Analysts vs Technical Analysts; Subject Matter Experts vs Business Analysts; get rid of the BAs!
• er… is there anyone left to progress the project?

Of course, there were also the sales pitches about the numerous methods of Agile we should be applying, although Scrum and Kanban seemed to be clear favourites du jour.

Perhaps, it’s a natural evolution of maturing Agile development for organisations. However, there appears to be a tendency to become overly introspective when faced with the challenge of change, rather than focus on what we are trying to achieve by changing. Perhaps we need to reassure people that their base skills are still valid and valued, we just need to work out how and when to apply them to achieve the Agile values of: doing enough to give the best bang for our buck; focussing on delivering benefit to our businesses quickly; being flexible enough to seize opportunities where it is sensible to do so… in other words, projects still need management (albeit there is a heightened, but not new, focus on coaching first, directing second). don’t get mee wrong though we still need to go into design; problems still need analysis; code still needs to be written and tested… and we need to figure out how to do all of this flexibly and collaboratively.

What was most refreshing to me during the conference was to hear the views of Martin Kearns (Agile Practice Lead from Renewtek), Neal Ford (Software Architect from ThoughtWorks) and Nigel Dalton (CIO of Lonely Planet). These three guys appeared to be in the minority in expressing what I feel being Agile is really about –

“…it’s just a guidebook guys, do what works for getting to your end goal.”

With all the Agile methods, tools, techniques and blurring of roles – there are two constants that run commonly between them all – the promotion of genuine collaboration; and of continuous learning. All roles bring value to the way we work. Alistair Cockburn has said: ‘people are highly variable and non-linear’ and as people aren’t software components – it inevitably introduces variability into projects. What’s great about Agile is that it fits process to people, not the other way around. Agile brings a different approach to process: the team is responsible for choosing their own processes, and as such no project will be the same, and no team will be the same.

We need to avoid the trap of holding ourselves up for too long by trying to figure out who does what activity within the project; and instead lift our eyes towards the project’s end goal. What are individual’s expertise – let them get on with it, don’t shuffle activities for shuffling’s sake. What are the team weaknesses? Get the team to collaborate on how to best address any gaps. Don’t introduce any unnecessary complexity. Think – what will success look like, and how can the team best work together to get there?

For those that are still seeking the new rulebook: www.Dictionary.com defines Agile as:

1. Quick and well-coordinated in movement; lithe.
2. Active; lively.
3. Marked by an ability to think quickly; mentally acute or aware.

To me, this means that to be truly Agile you have to be agile! The minute you think you’ve got it right, you’re making mistakes. Agile is ever evolving, and what we see as Agile today is likely to bear little resemblance to what it will look like Tomorrow.