chapter 5

Where to start – try Kanban or Scrum

“Be stubborn about your goals and flexible about your methods.”

Anon

A sneak preview of Chapter 5

Get off to a very fast, totally stress-free launch by using one of the perfectly formed frameworks on offer.

• You’re spoilt for choice: There are several excellent varieties available, but Kanban and Scrum are up there with the best.
• Kanban is simple yet powerful: Easy to get to grips with, yet powerful and flexible. Getting started is a breeze.
• Scrum is popular and fully featured: More effort up front but massively worth it. Especially fab with bigger missions.
• Two great options: Kanban is very safe and surprisingly flexible, while Scrum is a feature-rich, comprehensive package. Look no further.

Getting started

Once the decision is made to go agile – or to at least give it a whirl – the big question is simply where to begin. There are plenty of excellent routes in, but without doubt the quickest and safest way is to utilise one of the popular agile frameworks. There are several choices and the good news is they’re all fully formed, tried and tested and a very fast start is guaranteed.

We’re going to concentrate on getting up and running with two excellent options: Kanban and Scrum. Both are hugely popular, and rightly so. Both provide everything you need in one handy box. Kanban is brilliantly easy to get to grips with but there’s more to it than meets the eye. Scrum is probably the most widely known agile framework and although there’s more to get your head around, there’s nothing to fret about. Both can be used pretty much anywhere.

We’ll step through the essence of Kanban and Scrum and help you to pick the best fit. Each has its own nuances, but both do the job superbly well, plus they’re backed by extensive resources and support networks. Having to choose between two excellent options is a nice situation to be in.

Kanban basics

Kanban 看板 means signboard in Japanese and it came to life as a method to fine-tune and improve the production line at the car giant Toyota. Partly to help balance customer demand with build capacity and partly to improve the handling of assembly bottlenecks. Over time it has been taken up in a variety of other business sectors to improve their workflows and is now one of the fastest growth areas in the agile arena.

Kanban hasn’t strayed from its 1950s roots. The simplicity and ease of executing the underpinning ideas remains a big attraction. Although there’s a built-in respect for how the job gets done at the moment, there’s also an implicit determination to pursue incremental change – to make current work processes better, little by little. Kanban is about evolution, not revolution.

It’s easy to grasp, simple to implement and has negligible running costs. The launch pad is whatever you do right now, so there’s no blocker to an immediate start. There are two main steps for pinning down the status quo:

• Picture the current workflow: Begin by producing a visual representation of the flow of work, from when things are ready to go right through to job complete. Define the key steps along the way but don’t be tempted to go overboard with detail. It must be easy to comprehend.
• Control the workflow progress: How work progresses from step to step in the workflow must be clear, with a check at the end of each one to validate it’s fine to move on. It includes specific guidance on how to judge whether a piece of work is ready to start and how to confirm it is complete.

This analysis of how things are done now is at the epicentre of Kanban. Usually it’s not hard to do and it’s reasonable to expect it to be drafted within hours. If it takes days then that’s food for thought in itself. Let’s see how it’s done.

Visualise the workflow

When mapping the flow of work, don’t get hung up on the detail. Think big picture for the basic end-to-end format. What are the generic states along the way applicable to everything you do? By far the simplest, most popular and arguably the purest workflow consists of just three: things to do, those in progress and finally work done. When first launching Kanban it’s well worth beginning there and adding more if you feel the need:

• To do – when what’s wanted is clear and ready to go.
• In progress – once work is assigned and actively progressing.
• Done – finished and ready for the business to use as they see fit.

Once the workflow is visualised, it can be mapped directly onto a Kanban board. The board is a graphic representation of the end-to-end flow and can be held electronically but as discussed before it’s very effective to start with a physical wallboard, located in the heart of all the corporate action. Either way, a series of columns represents the flow of work from to do through to done.

In many respects, agile work management is similar across the leading disciplines and we’ve already covered end-to-end delivery mechanics in detail. However, there are subtle, yet vitally important aspects of Kanban that make it unique:

• Jobs are allocated dynamically: This is one of the most distinctive points about working in a Kanban environment. Teams adopt a ‘what’s next policy’. The work item with the highest priority is pulled into play when the next person becomes available. Priorities can change at any time and that’s fully embraced in a Kanban environment. Thus, the team can respond rapidly to changing business demands.
• Work-in-progress is capped: Trying to do too many things at the same time is counterproductive, so with Kanban there’s a limit set for the number of things on the go at any one time. For practical reasons, it’s best to allow for a couple of concurrent tasks per person, three at the most, but the aim is to prevent anyone accumulating a treasure trove of half-finished jobs. This encourages everyone to be a finisher, not a job hoarder.
• Backlog reviewed frequently: By definition Backlogs are never static but with Kanban they’re even more effervescent. It’s not unheard of to review it on a daily basis and even last-minute negotiations are possible when there’s an emergency. Even so, it’s important to avoid a culture of responding to half-baked ideas and whims. User Stories must always be adequately formed even if they’re desperately urgent. Regular assessments underpin the mood of a dynamic yet controlled environment.
• All work of a similar size: As a general principle it’s a good idea to keep User Stories lean and mean. Breaking work down into smaller chunks wherever possible avoids huge, long-running jobs and Kanban actively encourages slimmer, similar-sized slices. This helps regulate the flow of work, thus making it easier to predict end-to-end cycle times and the availability of resources. Of course, whatever size, all packages must still deliver business value in their own right.

A huge selling point is the ramp-up speed from a standing start – no more than a couple of days if enough effort is put in. There’s no risk of waiting for months before finding out if Kanban is a good match. Days, or a couple of weeks at the most, is enough to get a gut feel. In the very unlikely event of it turning into a total debacle it’s easy to revert back to the old ways, so the overall risk rating is extremely low.

Introducing Scrum

Scrum is an extremely popular option for going agile. It’s in fashion for a host of excellent reasons but the best one is simply that it’s easy to use and works brilliantly. Its framework provides structure without going overboard, which is no mean feat. Roles are clearly defined, yet come with enough flexibility to avoid stifling creative thinking and innovation. The package is fun to work within and brings the best out of people, which is an enticing combination.

There’s a bit more to Scrum but it’s still easy to implement and has the advantage of being well suited to projects, even big ones. Within the framework there’s detailed guidance on all aspects of who-does-what but it’s with a deft touch that doesn’t stifle innovation or creativity. It comes with a fully formed support network, and an unprecedented generosity and willingness to help abound.

As would be expected, Scrum is firmly focused on delivering incrementally in a series of useable chunks. The very first of these is the absolute minimum to get going and then the rest is layered on top from there. Every one of these increments is effectively a mini project, known as a Sprint – a fixed-length time-box of one, two, three or four weeks.

A very popular option is two weeks, and although there’s no recommended duration, many people feel one week is too short and four is far too long. Sprints provide a regular flow of product to the business team so don’t be tempted to vary the duration apart from in exceptional circumstances. Get into a groove and maintain a regular cadence. With the timescale fixed, the only variable is what can be delivered in that period of time.

But before we take a closer look at how that pans out on a day-to-day basis, let’s look first at how the roles and responsibilities within the Scrum team are set up.

Let’s get self-organised

It will come as no surprise that Scrum keeps it simple when it comes to responsibilities. There are only three roles: Product Owner, Scrum Master and Team Member. There are always several Team Members but only one each of the other two. The defining traits of a Scrum team are self-organising, self-starting and self-governing.

There are different opinions about the optimum team size, but the recommended min/max is between three and nine. A much more important consideration is for this unit to have all the skills needed to get the job done. There’s a collective onus on the gang to pull together and deliver, whatever it takes.

Product Owner – the business eyes and ears

The Product Owner (PO) is the business representative in every respect and looks after their interests on a day-to-day basis. This covers everything from shaping what’s needed, to confirming that deliveries are as expected. It doesn’t stop there either as the PO also represents the needs of the end customer too. They’re responsible for delivering business value to both their own organisation and to the end users.

The Product Owner will be lobbied by everyone about priority calls but ultimately, what they say goes. It’s not only about being decisive – the ability to balance off conflicting views and being tactful is important too. In addition to everything else, wisdom and negotiation skills are both needed. This is a pivotal role that is measured by the quality of the list of prioritised requirements (the Backlog), which is the spine for any Scrum team.

Even when the Backlog is in good shape, the team will have plenty of questions and the Product Owner needs to be freely available on a day-to-day basis. In parallel, it’s important for the PO and the team to build up a buffer of requirements to avoid living from hand to mouth. Ideally, the aim is a Backlog with a depth of at least a couple of Sprints at all times.

Scrum Master – a facilitator and enabler

The Scrum Master does everything imaginable to help the team perform to the best of their abilities. Part of the job involves practical day-to-day stuff such as facilitating team gatherings. Part is about overseeing the run-of-the-mill logistics such as getting the right people in the right place at the right time. Part is about removing blockers and greasing the team wheels.

The Scrum Master provides vital support to the Product Owner and helps promote a culture where the Backlog stays in good shape at all times. When the PO is thinking ahead and the rest of the team are focusing on the Sprint obligations, the Scrum Master helps maintain the tricky balance between short-term commitments and future aspirations.

The Scrum Master is ultimately responsible for maintaining the best possible environment for the team to operate within and to help their work lives run smoothly. But not at any cost, as the Scrum Master is the custodian of the Scrum process, making sure that things are done the right way.

The Development Team – the engine room

The rest of the squad is usually referred to collectively as the Development Team. Each individual is known by the rather bland title of Team Member, but the role is rich and diverse. They’re all multi-talented, multi-disciplined and ultimately in control of their own destiny. Once the Product Owner sets out their stall in the Backlog, the Development Team works out how best to do it.

Within the confines of each Sprint, the team are self-managing and focused on delivering end results – taking prioritised items from the Backlog and turning them into working artefacts. They are trusted to operate as sensible grown-ups who can get on with it without needing micro-management.

Scrum in action

At the epicentre of the Scrum framework are four key events properly known as Scrum Events, but very often referred to as Scrum Ceremonies. All play a vital part and each one is totally indispensable. Fully assembled they form the end-to-end structure of each Sprint:

• Sprint Planning: This happens at the very beginning and does exactly what is says on the tin. This is where the final decisions are made about what business requirements – usually in the form of User Stories – are going into the Sprint. The Product Owner comes armed with prioritised requirements and the team forecast how much they can handle in the next Sprint.
• Daily Scrum: This is where the team huddle together and bring their colleagues up to date on what they’ve been doing, what they plan to do and report any roadblocks. This happens every day without exception. This enables the team to be on the same page and have a joint plan for the next 24 hours. It’s certainly not a status update to the Scrum Master.
• Sprint Review: This takes place at the end of the Sprint when the Product Owner with support from the team showcases the business-centric work to the stakeholders – when things pan out as expected, this is whatever the team forecasted they’d deliver during Sprint planning. This is primarily a final pre-launch check and really keeps the wider business in the loop.
• Team Retrospective: This is a look back on the Sprint and highlights the things that went well and anything that could be improved. Whatever the outcome, there’s usually a mix of recommendations to take forward to the next Sprint. It’s important to focus on the big winners and quality is more important than quantity. The Scrum Master facilitates, and the team drive the recommended improvements.

There are no nice-to-haves in this collection. Each Sprint must start with planning and end with a review topped off by a team Retrospective. Every day there must be a Daily Scrum (or Daily Stand-Up as it’s commonly referred to). If any of these appear surplus to requirements, then something’s going seriously wrong.

Sprint planning – setting out the stall

As each Sprint is a mini project in its own right, it will come as no great surprise that it kicks off with a planning session where the team agree what’s to be done. Planning in this context is an interactive event to review the prioritised User Stories that are ready to go and decide how many can be delivered within the next Sprint.

The Product Owner brings along a wish list that is invariably more than can be achieved in one time-box and the team decide what can be done based on experience. The end target must be challenging but achievable and the team always have the final say on when they have reached full capacity. The sum of the parts is expressed as the Sprint Goal, a pithy declaration of immediate intent which is a step towards the Vision.

There are times when planning goes very smoothly, usually when the Backlog is rock solid, and the team is clear about their projected capacity. Then it’s a straightforward case of the team selecting stories, one by one, that they’re confident of finishing to done status. It isn’t always straightforward though and usually there’s a sympathetic negotiation between the Product Owner and the team, with the Scrum Master facilitating.

The end result is the team forecasting delivery of a subset of the prepared stories which is then dubbed the Sprint Backlog. At this point the team must be clear about what they’re getting themselves into and the Product Owner must be satisfied with the intended outcome. There’s a mutual interest in getting this right and ensuring the contract is a fair one.

Once the User Stories that make up the Sprint Backlog are finalised, then it’s over to the Development Team to get on with it. The thinking and preparation are over – all systems go!

Daily Scrum – keeping in touch

The Daily Scrum or Daily Stand-Up, as it’s popularly referred to, is a time-boxed, mini-meeting that lasts no more than 15 minutes and happens every day without fail. It’s an opportunity for each Team Member to update their colleagues and report anything blocking progress towards the Sprint Goal. The backdrop is the Sprint task board which should be prominently available for reference.

The recommended format is blisteringly straightforward with each Team Member in turn answering the same three questions:

• What did you do yesterday? A summary not a blow-by account.
• What will you do today? Again, only an overview of intent.
• What impediments do you have? Anything obstructing progress.

Sprints rarely run totally smoothly, and hiccups are to be expected. Therefore, an important aspect of this assembly is to get any blockers out in the open. Issues are tabled but not normally solved on the spot – the Scrum Master has the responsibility for sussing out a way forward. The plan is to line up a helping hand and avoid issues becoming a damaging distraction.

Despite the simplicity of the format, even in a mature Scrum environment these sessions don’t always run smoothly. Occasional detours are to be expected. Ditto for overruns. But if they’re regularly dysfunctional it’s a serious warning sign.

Sprint Review – delivering the goods

Keeping the stakeholders permanently in the loop is a massive part of the agile ethos and this happens on a day-to-day basis because of the constant involvement of the Product Owner. But there’s wider business contact at the end of each Sprint when the Product Owner shows off the fruits of the team’s labour to the business stakeholders. This is another Sprint Ceremony, called the Sprint Review. It’s open to all stakeholders and interested parties within reason.

This session is facilitated by the Scrum Master, but the team and the Product Owner are very much centre stage. They showcase their wares in whatever format makes most sense to the audience, preferably demoed as the end product will eventually be used. Each individual User Story is laid bare, warts ‘n all if necessary. Full disclosure is what’s expected in this context.

It’s about much more than showing the stakeholders what they’re getting. When executed well, the Sprint Review brings everyone together with a sense of collective ownership and a common goal. Not only the final nod on whether the deliveries are fit-for-purpose, but also confirming they’re another step towards the promised land. This is a sea change from long waits and a you-get-what-you-get culture.

Most of the time, this leaves everyone with a warm satisfied feeling which is excellent for building confidence. It’s normal for minor issues and small oversights to be revealed under the spotlight but with agile a problem shared is a problem solved. And if a bit of fine-tuning is urgently needed, the next delivery is only a matter of weeks away.

There are times when Sprint Reviews are very straightforward and over with little fuss, but these are few and far between. Even when the team sets out their stall clearly during planning, there are bound to be questions and niggles when the stakeholders run their final pre-flight checks. It’s normal for minor tweaks and future improvements to be suggested. Quite often there are debates about points of detail and that’s absolutely fine too.

The Sprint Review is when everything comes together. The journey started with the Product Vision and then a slice pops out at the Sprint Review. This is a great litmus test and when all is going well generally it’s obvious during these sessions. Conversely, if things are not so rosy then this is when the tell-tale warning signs appear.

Retrospectives

Before jumping onto the next Sprint rollercoaster, the team gets together to reflect on how things panned out in the current one. This is called a Retrospective and it’s the final non-negotiable ceremony. It must take place whether things went well or badly, as there’s as much to be learned from good practice as there is from a debacle. Never be tempted to give this a miss and plough straight on.

The groundwork begins early on as the search for improvements must be at the back of everyone’s mind at all times. Encourage the team to note down their thoughts whenever they occur – no need for chapter and verse as a couple of sentences will be enough as a memory jogger at the Retrospective itself. Less is more in this respect.

Getting the team to open up is never easy and translating their comments into realisable actions is a skill that takes time to fully master. It’s true to say that most observations are going to be about learning from mistakes but it’s important to keep an eye out for good behaviour that can repeated too. For Scrum, this is the epicentre for process improvements and we’ve already covered how important that is to the agile lifestyle.

Maintaining a regular heartbeat

With Scrum the days of waiting around for once-in-a-blue-moon deliveries are long gone. Instead of endlessly anticipating the arrival of all and everything, smaller chunks of business value are delivered based on a set schedule – fixed-length increments set at one, two, three or four weeks. The regular arrival of another piece of the jigsaw is invariably a breath of fresh air.

A reliable delivery cadence is the trademark of a performing Scrum team. There’s nothing more potent for building business confidence than when there’s an understanding about what’s coming next and when it will arrive. It gets the business into a habit of expecting product and is a big factor in keeping their buy-in. It does put a degree of pressure on the team but it’s a positive challenge.

The timing isn’t a vague commitment, it’s very precise. For example, every two weeks means exactly that, let’s say every other Wednesday. The number of User Stories delivered each time may vary but the arrival dates are guaranteed and can be plugged into diaries up front. The Vision is delivered in pieces that are useful in their own right.

Although weekly deliveries are exciting, there’s a limit to what can be done in such a short timescale and the business team barely have time to pause for breath. Every four weeks permits meatier content, but it can seem a long wait. No surprise then that the most popular format is every two. It’s a perfect balance.

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

A complete end-to-end solution

Scrum guidance is concise without being constraining, with excellent specialist advice widely available in many formats. It’s extremely easy to get started. Sticking to the events and operating within the recommended team structure are non-negotiable and the rest flows from there.

Scrum is a fully formed agile bundle for transforming what the business team wants into end product. The only word of warning from experienced practitioners is that getting the best out of the framework requires a deft touch and the right mindset. So, for exceptional results, remember to stick with all the advice we’ve covered.

There’s something reassuring about a framework which can be perfectly summed up in one diagram:

Various variations

When it comes to ways of working, there are many intriguing variations to be found in the agile world. The community has been debating various blended and hybrid approaches recently and ScrumBan (a combination of Scrum and Kanban) is one of the best known. However, there’s a range of opinions about how effective these fusions are and it’s one of the hottest of hot potatoes.

As part of our more targeted focus on Scrum and Kanban, it’s worth mentioning there are plenty of practitioners who draw on the intent of the other framework with great success. In particular, when Kanban teams reuse elements of Scrum:

• Retrospectives: Essentially, inspecting and adapting the work-flow. The timing of sessions is not fixed with Kanban but it’s equally valuable to ask the same questions: what do we do well and what can we do better?
• Daily Stand-Up: If nothing else, raising the profile of any impediments justifies a daily get-together with Kanban too. It also underpins the sense of teamwork and general collaboration that’s important to preserve.
• Planning: Kanban is more focussed on just-in-time activities but there are times when it pays to think ideas through in advance, with input from representatives from all the relevant disciplines.
• Reviews: There’s no set-piece show and tell events with Kanban, but timely feedback is part of the ethos. Pre-launch mini reviews make good sense whatever framework you use to do the work.
• Roles: Kanban doesn’t specify roles but it’s worth thinking about what the Product Owner and the Scrum Master do. There will still be a need to involve the business, and the team will have blockers to resolve.

Kanban versus Scrum

Both are brilliant. Both are steeped in agile thinking. Both have their pros and cons. Spoilt for choice is the phrase that regularly comes to mind. More importantly, it’s quite likely one will suit your world better than the other. Contemplate the options before jumping in but don’t overthink it.

It would be a mistake to simply see Kanban as a soft option, or as a stepping stone to Scrum. There are pros and cons, but both are rich in their own rights. There are times when there’s a migration from one framework to the other but it happens both ways. It’s certainly not one-way traffic.

The final word

Making the leap into the world of agile doesn’t need to be risky or costly. Using a framework means the methods are crystal clear and allows everyone to focus on getting the implementation spot on. There are plenty of options but if you want a fast, seamless start then look no further than Kanban and Scrum. It really is a no-brainer.

Kanban is a great way to get a foot in the door. It’s easy to understand and simplicity itself to use. It’s nigh on impossible to get wrong, so there’s no good reason for not at least having a crack for a few weeks, is there? And even though it’s an easy, low-cost entry point, Kanban isn’t a compromise solution and is perfectly capable of sparking a revolution.

Then there’s Scrum, a veritable tour de force that is close to being perfectly formed. Although it can handle pretty much anything, it comes into its own with projects. There’s a bit more to mastering the how-to-do mechanics and it pays to prepare but it’s nothing to worry about. It’s a comprehensive package that will not let you down.

If there are any lingering doubts about agile, then trying out one of these two is an inexpensive, low-risk way to test the water and dispel those fears. Even contemplating an implementation is guaranteed to generate rich material about how your world functions right now.