Sprints, scrums and kanban - your guide to agile

Do you think your business is working efficiently? Do you believe you’re delivering good value to your customers? Do your products and services delight customers? Are your staff enjoying their work?

If your answers to any of these questions is “no”, then you could consider embracing an agile business approach. That’s according to Ken Rubin, author of Essential Scrum: A Practical Guide to the Most Popular Agile Process, who adds pointedly: “In a world of uncertainty, you need an approach that helps you understand what you’re doing and how you’re doing it.”

Ditch the 18-month, colour-coded wall planner and appoint a product owner who identifies the features required for your piece of work

Having emerged from the world of computer programming – notably when a group of software developers created the Agile Manifesto in 2001 – there are two main agile methodologies for business leaders to consider. Both share core manifesto principles, which Mr Rubin characterises as delighting your customers, getting faster results, having the confidence to succeed in complex projects and having “more joy” in your organisation.

The scrum method

And of agile methodologies, as the title of the book indicates, scrum is the most widely used. It begins with a conceptual shift. Ditch the 18-month, colour-coded wall planner, detailing what will be done, when and by whom for how long. Instead appoint a product owner, the business person or project visionary who identifies the features required for your piece of work.

“I often refer to this as ‘the big blue cube in the head that they want to build’,” says Mr Rubin, who has coached more than 200 organisations in scrum. “The project owner breaks this down into a list of features – the really important stuff that they want to do first is at the top of the list.”

Next comes the scrum master. “He’s our coach,” says Mr Rubin. “He’s expert at scrum and helps the team become expert at using scrum.” Finally, there are the vital people who will produce your product, your cross-functional development team.

These development teams now work in sprints, typically two to four week periods, meaning bigger projects would necessarily take multiple sprints. Crucial to this is sprint planning, in which members of teams should “acquire confidence” that they can actually achieve what they’re meant to during a given sprint.

Once planning is over, sprint execution – that is to say the actual work – begins, typically accounting for 80 to 85 per cent of the overall time. “The intention is to help a self-organising team better manage the flow of work,” explains Mr Rubin.

Each day of the sprint begins with a planning meeting – the daily scrum – so people can update teammates on what they achieved the day before, say what they’re hoping to achieve that day and discuss any blockers to progress. Normally, this meeting is conducted standing up.

Then at the end of each sprint, there’s an ‘”inspect and adapt” workshop to review the work, followed by a sprint retrospective to review the process. “The idea is we try to get better every sprint and as we build something we show it to the stakeholders to get fast feedback,” says Mr Rubin. “My joke about sprint review is you’re allowed to hate what I do, you just have to hate it early.” And then the next sprint begins.

In this way companies have created everything from computer programmes to cars to marketing campaigns. Mr Rubin has even helped a religious group use it to improve outreach methods. Meanwhile, executive teams have used scrum to actually implement scrum in their organisations.

The kanban system

But scrum is not perfect for everyone. What if what you do can’t be planned for? What, for instance, if you operate a support function? Then agile has another solution called kanban.

The kanban method, from the Japanese for “signboard”, emerged from an inventory management process devised by car makers Toyota. At its heart is the signboard, a visualisation of the work of a given organisation or sub-unit, with tasks delineated in rows and columns. The columns describe the states of work and the rows or “swim lanes” the types of work.

“It’s not a process, it’s an overlay,” explains Mr Rubin, who has often seen kanban employed in companies that also use scrum, though for different functions. “The idea is you model how you work today and then you make incremental, evolutionary changes to what you’re doing.” You then keep measuring and tweaking to finesse what you do.

Kanban draws on agile principles in several ways, not least by imposing limits on how many items can be in a given column at any given time. “Limiting work in progress is a core agile philosophy,” he points out. Kanban is also a “pull” not a “push” system so additional tasks only present themselves when previous tasks are complete. This helps people focus.

“Often what I hear is ‘we’re working on so many things that we’re finding it hard to get anything done in a timely way’,” says Mr Rubin, who is critical of corporate cultures that target maximum utilisation of workers. “What they’re missing is the most important point – economic damage in companies is not caused by idle workers, it’s caused by idle work. There’s a cost-delay associated with work being idle and that cost tends to be orders of magnitude greater than having spare capacity.”

Behave in a more agile way

However, if adopting scrum or kanban is too much of a stretch for you, then you could instead think about co-opting some agile habits.

“Agonising about how you become agile is a contradiction in terms,” cautions Anthony Freeling, author of Agile Marketing: How to Innovate Faster, Cheaper and with Lower Risk, and president of Hughes Hall, Cambridge. “The whole point of agile is to get going and to find your own way that works.”

So if scrum or kanban don’t float your boat, try something else. Indeed, Dr Freeling advises companies to consider ways of behaving in a more agile way, such as by conducting low-cost initiatives or business experiments to develop new campaigns or product offerings.

“Get started, run the first tests, measure the results and see if you end up with something better that surprises you. Then try doubling the number of tests you do,” he concludes.