Agile – A simple guide

Yes it’s another post on ‘Agile’ – primarily because I’m doing some mentoring at present with a PM and really I wanted to remind myself of my own thoughts on Agile, how I’ve implemented it and some of the challenges I’ve faced in Business Units when it came to adoption.

When I’m in front of a client and I ask the question ‘are you Agile?’ I often get a resounding ‘YES’ only to find only the very lightest sprinkling of Agile tenets have been barely adopted throughout the team. They are left stuck wondering why Agile wasn’t the magic bullet they had hoped for and why all their projects weren’t flying out the door on time, and to budget. Usually why I’m there in front of them!

Almost like a magic wand, I see Managers & Dept. Heads bandying the term around with wanton abandon but a team left scrabbling into what it means and how they should deliver it. Not to mention the types of character who don’t interface particularly well with Agile (we’ll come onto this later). It’s a complicated beast this Agile and yet discussed with all the frivolity of how many sugars to have in your tea!

With so much training available now not only in Agile overall, but with the various components within it, I’m still often surprised by how little contextual understanding people have when it comes to Agile. For those that do the training, there’s the issue of then understanding on how it will fit in their own organisation. Agile is moldable, but often it’s used as a hammer to beat staff with.

So this post then attempts to tackle implementation, adoption and some areas of thought into why Agile can be a brilliant way of accelerating what you do but also, it’s not the be all & end all to your business & why you should consider adoption of Agile very carefully.

Why do you need to be Agile?

Let’s be honest with ourselves for just a moment. Speaking from my own experience, very few projects get delivered well and to time & budget schedules. Businesses decide to adopt a methodology such as Agile because their existing processes are super frustrating. Any of these problems sound familiar?

• Budget Overrun
• Time Overrun
• Unmanageable backlogs
• The Project is one which never finishes
• The Client isn’t happy with what gets released
• Everyone’s massively frustrated & grumpy.

In every Project I’ve managed, almost all of these are present, they have been in the past, and they will be in the Projects I work on in the future. Agile can help smoothen some of these issues, but for a good chance of success the first thing which needs to be tackled are the people. People are at the heart of everything when it comes to Agile, in fact Technology and this statement alone represents the core of my entire manifesto when it comes to Digital.

Who hates Agile?

People don’t like change. We’re intrinsically designed as fleshy human beings to be resistant to anything we’re not sure of or have familiarity with. This often slows down the correct adoption of Agile, and in particular there’s a few personality types to be aware of;

• Cowboy Joe’s

You know the types. Those who go off on their own, never update the Project or their team and insist on doing everything last minute. These guys hate Agile because it attempts to change this way of working from the outset.

• White Knight’s

The type of people who create the very same problems they end up solving, because they are hooked on the process of feeling wanted and needed alongside their own capability validated. Agile posits to tackle issues and remove problems in a quick and orderly way, these crisis Junkies can’t get that fix they so badly crave. They hate Agile and everything it stands for.

• Dev Nerds

I use the term ‘nerd’ lovingly by the way! These are the guys who write a billion lines of code, plugged in via a USB cable and a pair of headphones but aren’t that good at talking to people outside of their own. Getting them to do a fifteen minute stand up meeting to tell everyone of their progress would be like asking them to lift their eyeballs out of their socket with a spoon. Or yank a USB cable from their hard Drive without dismounting it first! They hate Agile too. They may understand it a bit more, but they hate it all the same.

Agile – the Peacetime Protector

My recent experience over the last twelve months with a client has taught me people very much like to work in their own silo’s. Their own little worlds. Agile helps bring people into a more collaborative space as the process endeavours to uncover all the dead bodies that may lay within a project early on and deliver a dose of reality to everyone involved.

So what else does Agile do?

Removal of Grand Reveals

The bigger clients I work for love detail. They spend hundreds of hours with happy path journey creation, statistical best practice data & their ‘view’ of the world. Often, the product being built (be that a website or application) gets in front of the end user or client and I can tell you, often met with the sound of a lot of swearing and tearing up of contracts. Agile promises to get even very early stages of the product in front of customers right from the off, making the customer or client part of the team. That way, understanding, investment and expectation are all kept in check as the project moves along. The companies hate showing unfinished product to people, but hey, that’s Agile.

Risk Management

Agile helps get risks on the table at their infancy. We can then tackle them in daily stand-ups whilst they are manageable instead of them being pushed under the carpet & left to fester into more unmanageable monsters. Agile won’t fix monsters already created.

Saving Money

Often not realised, by getting your end product to your users/Client/Customer early, if all goes to plan you can get to the MVP which delights them, without baking in expensive complicated features from the off that you may have *thought* they needed. This helps save time & budget.

There’s lots of other benefits, but I’d be here all day and besides, there’s people online writing about this far more eloquently than me. Read here, or here. The ones above are the ones I tend to notice as major benefits for businesses when Agile is done correctly.

How can I implement Agile?

Don’t hit your team with huge training seminars, boot camps or demands. The trick is to find the soft areas which are ripe for change, and slowly implement change. Stand ups, Scrums, Sprint delivery, you don’t have to do all this at once. Work with the team here. Some may be crying out for Agile, others will be resisting it hugely.

How do I implement Agile?

A question I’m often asked, and some quick wins below I’ve documented as they’ve been pretty successful. These are just a couple of areas, but ones I consider not only key, but vital to getting your hands around the throat of the project.

Stand ups (or SCRUMS)

This is an easy one, especially if I’m being parachuted in. I’ll arrange a daily (or to a frequency suitable for the size/complexity of the project) a daily fifteen minute (max) stand up around a desk (usually mine). Sometimes I’ll facilitate this with a tool such as Monday or Trello, or maybe I’ll just use a Kanban board with Post-It notes, but I’ll ask questions such as;

• What did you work on yesterday?
• What are you working on today?
• Is anything getting in your way?
• What do you need?

I’ll pay careful attention to how people answer these questions. I’m looking for wafflers, those who provide too much detail, those who remain silent. What I’m after at this stage is not only a project update, but also to get people used to communicating in a fashion that’s succinct, to the point & facts-based. No chairs, no bitching sessions, just a short conversation to understand where the project is. Quick Tip: I often use a Google in-browser clock set to fifteen minutes to keep everyone focussed.

Agile delivery

I often get the development team, PM core & business leaders to sit down, analyse the product roadmap and ask what they (the business leaders) would like delivering next. Working with all to produce a map of development which can then be chunked with the PM into sprints. This task of creating the sprint roadmap often involves a giant whiteboard, post it notes & getting the technical teams to estimate what each task is worth in hours. We’ll split these up into small (1/2 a day or less) medium (1-2 days) or large (2 days or more) tasks and work with the team to ensure they are not over-extended and are clear on what their work load is. I then go back to the Business Leaders or the client and advise this is what’s going to happen – then everyone signs off and gets committed.

In Summary

I’m unbiased to methodologies. I’m more focussed on implementing the right thing for the right client and that’s driven by the environment, the project & the people. Agile requires a huge amount of commitment culturally and often a lot of my clients aren’t ready for this. They live in a waterfall world trying to mesh in an Agile workflow retrospectively. I think Agile’s great by the way, like everyone – if it’s done right.

For more information, help or a chat, get in touch with me on Twitter (@mariodc) or via a comment below. I’d love to hear from you.