chapter 2

Work faster and better with agile

“If you don’t know where you’re going, you’ll end up someplace else.”

Yogi Berra

A sneak preview of Chapter 2

At the heart of agile is an innovative approach to managing your workload, the mechanics for operating more effectively:

• Define the end in mind: Be clear about where you’re going to avoid getting side-tracked or lost.
• Set out the stall: Visualise the bite-size chunks needed to deliver your dream.
• Choose what’s most important: Separate the essential must-haves from the bells and whistles.
• Pin down the starter pack: Work out the bare minimum set of features needed for launch.

Brighter days ahead

Working our socks off is admirable but it counts for nowt if we’re side-tracked into doing things for no clear rhyme or reason – especially poorly thought out projects or management whims with dubious business value. Sadly, this happens too often and it’s not only a waste of effort, it’s a lost opportunity to make better use of our precious time. How mad and maddening is that?

What we do and how we do it is centre stage with agile. It provides a comprehensive, end-to-end framework for managing our work and makes sure we’ve thought about where we want to get to – which stops us from wandering aimlessly. Then once we’ve set out our stall, it guides and drives us through the nitty gritty with our target firmly in mind. It’s all about delivering end results. Stuff that’s fit-for-purpose, delivered on time and at a fair price.

Agile guides us into doing the right things and in a sensible order. Quite a heady cocktail that adds up to working smarter without having to graft any harder. Getting more out of limited resources and achieving far better outcomes. It provides a highly effective framework for defining and managing work and, as you’ll see, it’s blissfully easy to get started.

Know where you’re going

Starting any new piece of work can be daunting, and it is surprising how many journeys begin without a clear end destination in mind. It can happen with an individual focused on a specific task, a team working on a big project or even when the Board of Directors is pinning down their corporate five-year plan. Sleeves get rolled up and people crack on before there’s an end in mind and a final destination to work towards.

All agile endeavours are geared towards an end goal and this is referred to as either the Vision or the Product Vision. The Vision statement is an elevator pitch, a snappy summary of what the product is all about. Don’t get this mixed up with a traditional Mission Statement which can be cliché-ridden and detached from the real graft going on in the organisation. A Product Vision is never vague or ambiguous.

The end goal is rarely achieved in one single leap. Normally it comes about in a series of smallish steps. Effort along the way must keep us moving in the right direction and that will be a primary measure of our success and of business worth. It’s like in a chess game where every move is another step towards checkmate, even when it’s necessary to take a sideways step before moving on again.

It always makes sense to start from a clear idea of what you want to achieve. It might be argued it’s just common sense. It’s a recurring theme that agile draws heavily on sound judgement, and that is certainly the case here.

What, why and who’s it for

The first step is to pin down what you’re trying to achieve in a way that’s easy to communicate and validate progress against. Get the ball rolling by identifying What’s Wanted, Who’s It for and Why Is It Needed. It’s important to resist the temptation to just get on with doing stuff without first thinking about what, who for and why. The end result should be pithy and strike a chord with everyone involved in the work and your target customers.

• What is needed?: It can be an end product or a consumable service, but it needs to be specific and measurable. It can’t be a series of activities like discussions or meetings. If this can’t be articulated, then alarm bells are ringing.
• Who is the customer in mind?: Whether it’s a commissioned job for an individual punter or a launch into a new market, there will be someone in mind. If not, it’s most probably a vanity project or a management whim.
• Why is this needed?: Either it solves a specific problem or there’s some other compelling way the customer will benefit. It doesn’t matter whether the target market is niche or if the appeal is wider, the same applies.

These might seem like simple questions, but far too often the temptation is to plough on with real work without pausing for thought. In a study of more than a hundred start-ups, a venture capital organisation found that the number one cause of failure was that there was no real market need. Close to half spent years building a product that no one was interested in.

This is another running theme of agile – check the obvious stuff that too often gets overlooked. The end result removes any doubt about what, who and why even to a casual observer.

The AgileParcs Product Vision provides a wealth of information about what’s going to be on offer, the potential customers and what will set it apart from the local competition. The end game is set out, including a pivotal declaration that high standards are vitally important and the reasons why. The big picture is there for the internal business team, investors and potential customers too. Plenty for everyone to hang their hat on.

Within the fixed end point there’s plenty of room to manoeuvre regarding the detail of what will be delivered. Based on the Vision, it will be easy to pin down individual pieces of work and to measure progress towards the end goal. A bit of effort up front sets up a solid foundation for everything that follows and will, without doubt, pay back the time investment in spades.

Set out the stall

Any undertaking of consequence involves more than just one simple task and is typically made up of numerous discrete steps. Whether this is executed by one person or by a gang, it adds up to what’s commonly called a project (an individual or collaborative team effort that’s carefully planned to achieve a particular aim). In the simplest sense, a project is a set of connected pieces of work. We all work on projects of some sort from time to time.

An agile project is defined by the Product Vision and can be broken down into a series of moves towards the end destination, with each one delivering its own specific business value. Every step is plainly described in business-speak, not technical jargon, in a way that those interested can relate to. The expected outcomes, the stuff to be delivered in each case, is clearly specified and is the primary measure of a job well done.

Once lumped together, this collection of linked steps is widely known in agile circles as the Backlog. More jargon. Without wanting to get bogged down by terminology, it certainly helps to know a few key terms, and this is one that will constantly crop up. It is sometimes pointed out that it’s nothing more than a sophisticated to-do list. Quite right, and all the better for being easy to explain and understand.

When the Backlog is first created, don’t overthink things. It’s an opportunity for the business team to brainstorm their hopes and dreams, to get everything down on paper for further reflection. It’s perfectly fine for the first pass to be a stepping stone, a collection that moves things in the right direction strategically, pinning down all and everything necessary from the off.

There’ll be occasions when a comprehensive Backlog can be pinned down up front. But this is very rare and more often the first stab only gets us travelling in the right direction, especially with big endeavours. One of the selling points of agile is that it’s not necessary to pin down absolutely everything before setting off. Ensure that the essential requirements are identified – the core nucleus of the Vision – and throw in some nice-to-have luxuries for consideration too.

Things are bound to be missed; don’t lose sleep about that either. It’s not normal to be able to think of everything up front. There’s an expectation that items will be added in and that the Backlog is not etched in stone, but on the contrary is constantly evolving. Agile is especially strong when it comes to changing your mind and it’s easy-peasy to make tweaks and adjustments. Change is embraced, not frowned upon.

Once the initial wish list is identified, the next step is for each individual slice of work to be written up as a business requirement like a job card – drilling down further into the detail of what exactly is wanted, who it will appeal to and why it will appeal. This is widely referred to as a User Story, another piece of much-used jargon. Not the most descriptive tag but easy enough to understand and remember.

Each User Story must have a specific outcome that delivers business value and builds towards the Product Vision. If there are any other considerations, they can be specified too. Get down all the known requirements and constraints without going in detail about how the work will be carried out.

Put it all on show

Openness is a pillar of agile and all forms of transparency are vigorously encouraged. There’s plenty of upside to keeping everyone in the loop and with that in mind, choosing where to keep our Backlog of User Stories is an important consideration. Writing everything in a notebook and locking it away in a secure drawer isn’t in the right spirit. Far better to have everything on display, the higher the profile the better.

Loading User Stories on to a physical wallboard in a central location is a very popular option. It serves as a hub and an information radiator. Expect curious interest and encourage feedback. The wider the engagement, the greater the validation of intentions, with the possible added bonus of new ideas being generated. A wallboard is an invaluable way of promoting interest and feedback. Last but certainly not least, there’s no better way of advertising intentions.

It’s increasingly popular to work from home and a physical wallboard isn’t practical in those circumstances. The same applies when the project team is dotted all over for some damn good reason. This isn’t a major problem as agile is blessed with a number of digital task board options that make remote sharing very easy. They may lack the high profile and visibility of a physical board in a central location, but they do everything else brilliantly well.

Prioritise stuff to be done

The final step in assembling the Backlog is to organise these chunks of work into a sensible sequence reflecting their relative importance. This is never an exact science and debates – occasionally heated – are part of the process. Begin by shuffling the User Stories into the order of perceived business priority, the most important at the top and least critical at the bottom. Of course, when doing this there’s always a degree of beauty being in the eye of the beholder.

Although there’s never a right answer when it comes to putting things in an order of importance, it’s prudent to be able to walk before trying to run. So, a good variety of accommodation plus a check-in facility is always going to be higher up the wish list than a communal hot tub. There’s no need to fret about getting the priorities spot on up front because the running order can be easily changed, with items promoted or demoted when necessary.

The AgileParks Backlog is a living thing and it’s a healthy sign if stories are added and priorities change. Early on, the management team may realise it’s impossible to operate without an office and a small temporary portacabin becomes a new requirement with a higher priority. Or customer surveys may indicate cosy lodges will be much more popular than anticipated and that gets moved up the pecking order too.

Sizing is important

An important think-piece when assessing relative priorities is the comparative size of each piece of work. When a job that delivers high value is up against one with little return then the decision is an easy one, but life is rarely that simple. Usually it’s a choice between something with higher net worth that will cost more versus a quicker win that’s less useful but cheaper to deliver.

This can be a minefield and tangible costs are usually the main things considered – basically any hard cash involved and number of hours of graft required. Predicting the fixed costs and anticipating the number of person hours to deliver certainly helps in deciding what to do first. However, there’s a tendency to get bogged down in the calculations. This approach is time-consuming and the costs are only indicative anyway.

Agile estimation uses a different approach. Rather than chase the impossible goal of predicting exact costs, the aim is to get an indication of the relative size of work within the Backlog. Is User Story X bigger than Y? Is Y larger or smaller than Z and the size of each is described in a non-financial way. A very popular way of doing this is by assigning T-shirt sizes: XS, S, M, L, XL, XXL and even XXXL if you wish!

Crucially, with agile, estimates are always produced by the people who’ll be doing the work. Elements considered do not include the potential effort required but also the complexity of the story and the number of unknown factors surrounding it.

When there are differences of opinion it usually points to misunderstandings about exactly what is involved or highlights unknown factors. Is it best for AgileParcs to deliver the caravans, mobile homes and wooden lodges one at a time or in batches of two or three? Are the lodges going to be handcrafted from scratch or shipped in as a package and then assembled? If the admin block is bigger, can it incorporate a convenience store, general storage and even a coffee shop or bar?

The generalness of the T-shirt assessments avoids prolonged debate about minor points of detail. Once User Stories are identified as S, M, L or whatever, then this assessment is a useful factor in juggling priorities. Business value is the primary driver but there are occasions when an XXXL valuation may tip the balance in favour of other low-hanging fruit.

Deliver in bite-size chunks

Before agile came along, the most popular approach to project planning was to spend ages detailing a huge long list of requirements and then insist they’re all essential from day one. This included endless deliberation about all the bells, whistles and other nice-to-haves which could take months or even years in extreme cases. Many great ideas died a slow and painful death this way even before any real work started.

Of course, everything isn’t really needed up front. But in the bad old days, anyone with any nous knew that the first delivery was probably all you’ll get apart from fixes to any glaring snags. There was little point in hoping for anything that wasn’t very clearly specified in the contract signed up front. To make matters worse, there was a long, long, long wait for anything to turn up and hell to pay if any changes were asked for along the way.

In stark contrast, agile delivers smaller chunks regularly. Starting with the most important stuff first and then working through the wish list, with plenty of opportunity to change track when necessary. A constant stream of smaller deliveries with plenty of scope for a rethink whenever needed. This is referred to as Incremental Delivery, with each bundle building on the previous one.

Build a foundation

The first no-frills package that goes out is the foundation stone of the Vision and is known as the Minimum Viable Product, usually abbreviated to MVP. The jargon is a bit mind-boggling but the underlying concept is simple enough: it’s the bare essentials needed to get going, with the intention to kick on from there. Using this approach, it’s cheaper to get started and easier to change direction if things don’t pan out quite as expected.

The tricky question is what’s the minimum needed to get started. Defining the MVP isn’t always plain sailing and is often a hot potato. Of course, the smaller the MVP, the earlier the first usable chunk arrives. But it must be fully functional too and it must be viable as a standalone product or service. It’s certainly fine for AgileParcs to start with only tent pitches and mobile homes but there would be no point in launching with an admin block but no accommodation.

With a fully functioning physical or digital task board in place, it’s much easier to stand back and reflect on the minimum requirements. It easy to shuffle around the User Stories and discuss permutations with others. When doing this, always bear in mind that once the MVP is launched, other stuff will be coming soon afterwards. Normally it’s better to keep the MVP slimline and accept some short-term pain to get off to a fast start.

The final word

Managing work is a massive challenge and too often people just muddle through. Doing the right things and in the optimum order might sound like child’s play but is never easy in practice. Agile provides a comprehensive approach to handling the workflow that’s easy to grasp and implement. It’s an end-to-end framework for getting off to a fast start and delivering regularly from there.

The agile piece-by-piece approach revolutionises the relationship between the doers and the receivers. No more waiting for The twelfth of never as it provides regular, concrete evidence that things are on the right track – far more reassuring than any project status report. In fact, it’s a sign of things working well when the business starts to complain because they must wait weeks for what they want.

This brave new world does have its own special terminology and it helps to learn a bit of agile-speak. A handful of words and phrases are enough and already we’re comfortable with shaping our Product Vision, writing up our User Stories and adding them to the Backlog. We’re even thinking about what’s in our Minimum Viable Product and looking forward to the Incremental Delivery of the rest.