Agile (Part 1)

I’m back and sorry for the radio silence everyone, I’ve been absolutely stacked in the office and I have a big business trip to Asia (Japan, China and Hong Kong) coming up which I have been preparing for. I also have two speaking events and a panel next week: Everyday innovation, Virgin Incubator = How to build (and keep) a team and finally a panel on Disruption in distribution!

Now onto the latest blog, I hope you like it and find it useful and as always if you want us to help at The Unit with anything from integrating Agile methods (pure or hybrid for your organisation), creating and running incubators for your ideas, customer or business problems, which we can run for you or with you, or to simply deliver, again with of for you, beautiful and easy to use digital experiences just say the word!

Now onto business.

Doing things the agile way

Huge amounts have been said and written about the agile methodology (the term is way overused, most business people don’t understand what it actually means and it is at risk of becoming seen as ‘old hat’ which it shouldn’t because many organisations I have observed (my own excluded of course!) haven’t embedded it properly. This is the first of two blogs investigating what it takes to be truly agile.

Organisations must look at agile as a philosophy, not just a process. Cherry-picking the parts of the agile process that suit them won’t reap the best benefits.

Agile is a whole way of working, with three core values at its heart: inspectionadoptionand transparency.

These values underpin how agile projects are delivered, and how the people involved work, collaborate and communicate. Embedding them into a project is the only way to gain the full advantages of agile.

Inspection

Genuine agile project delivery – the sort routinely deployed by The Unit – is based on detailed and iterative planning.

This goes much further than deciding what sprints will achieve which milestones, and when. In the ‘agile’ sense, inspection means four things:

1.   Making sure the right people make the right decisions, and work on the right tasks, at every step of each sprint

2.   Stopping at regular intervals to make sure things are going in the right direction

3.   Re-planning according to what you find each time you pause

4.   Setting out how and when the team should communicate and collaborate, so everyone knows where the project stands.

What’s important with the inspection principle is not to look too far ahead. Agile is a highly iterative way of working: planning too far forward, in too much detail, will be a waste of time and effort.

Of course, the project team will need an intrinsic understanding of the end goal. But the point of inspection is for the project team to be hyper-aware of the present: what’s being done right now, why, and how well it’s working.

Inspection should also look historically, however. Retrospective sessions at the end of each sprint will look at what’s been done so far, what’s succeeded, and what hasn’t.

Adaptation

Agile working means continually adapting based on what your inspection activity discovers. Adapting not just the solution you’re developing, but also the process you’re following.

The solution will undoubtedly need to evolve, based on the regular user feedback that’s part of any agile project (see below). And so the process may need to change accordingly.

Which brings me onto another important principle: the scope of an agile project will almost certainly flex during its lifecycle. This is something everybody involved needs to understand and accept.

Transparency

Transparency in agile delivery comes from several sources:

1.   Inspection and adaptation – the cycle described above

2.   Frequent customer feedback – regular user-testing, carried out at strategic points throughout the development process and actually part of the ‘Discovery phase’ of Design Thinking (one for another blog!).

3.   Extreme collaboration – removing conventional agency-client boundaries. Client stakeholders are an integral part of agile teams at The Unit. They join scrum meetings, use the same collaborative tools, and provide constant feedback while solutions are being developed. As a result, they have complete visibility of the project, every step of the way.

4.   The ‘definition of done’ – agreeing what ‘done’ means for each element of each stage in the project. This covers not just completion of a task, but the process for reviewing it and feeding back, where the outputs should sit, and so on.

5.   A common language – clarification of key terminology at the outset, so everyone knows what to expect from a wireframe, prototype or minimum viable product.

The benefits

Agile is much more than running a series of sprints. But taking the time to embed it will pay dividends – in a number of ways.

Firstly, because agile delivers solutions fast. Agile projects launch products and features in weeks, rather than months (or even years), as is typical in some corporate organisations. This speed is vital to competitiveness given the pace of today’s digital economy.

Agile also prioritises customers over stakeholders. This guarantees that what’s being created will meet customer needs, not just those of the business. It also keeps it aligned with these needs while it’s being developed.

Another advantage is that the cycle of inspection and adaption avoids the ‘heads-down’ effect. It makes teams regularly look up to remind themselves of the end goal, and check they’re going the right way about achieving it.

Finally, agile minimises waste. It prevents projects from going in the wrong direction for anything more than a few hours, so very little time and resource is lost. And there’s no risk of ploughing on with suboptimal products, simply because too much has been invested to justify abandoning them.

In the second part of this series, I’ll look at how The Unit uses agile to deliver these benefits for the leading businesses we work with.

Embedding agile

Grounding a project in the agile philosophy involves two simple, but important, steps:

1.   Seek commitment

Before starting, get buy-in for the agile approach from everyone involved. Ensure you have plenty of employees who actually, properly, really understand how to run agile based projects, use them and listen to them and their opinions and voices. Don’t let your senior stakeholders drown them out.

Working to agile values is a high-intensity exercise, where projects can change direction several times a day. It may not be comfortable for all participants.

So make clear what it entails, and why it’s important. And ensure that all parties are signed up, engaged, and prepared for the time commitment.

2.   Roll your sleeves up

Then just get on with it.

Agile doesn’t call for detailed presentations, reams of planning, or a big reveal at the end. There’s no better way of exemplifying the agile way than simply getting on with the job.

Let me know if you’d like to discuss how The Unit can help you reap the benefits of agile or any of the other topics I have covered in this and other posts.

Ian