Scaling Lean and Agile DeliveryAvoiding the one size fits all

Tim Field

This book is for sale athttp://leanpub.com/scalingleanandagiledelivery

This version was published on 2015-04-20

This is a Leanpub book. Leanpub empowers authors andpublishers with the Lean Publishing process. Lean Publishing isthe act of publishing an in-progress ebook using lightweight toolsand many iterations to get reader feedback, pivot until you havethe right book and build traction once you do.

©2014 - 2015 Tim Field

I’m dedicating to all those published authors who’ve taken the timepreviously to write such excellent work that has inspired me. Alsoto the bloggers and those with web casts who may not realise how

much impact their work can have.

Contents

Chapter One - Describing the Problem . . . . . . . . . . . 1Target Audience . . . . . . . . . . . . . . . . . . . . . . . 1Principles, Frameworks and Methodologies . . . . . . . . 1Compare and Contrast . . . . . . . . . . . . . . . . . . . 2Measuring Successfulness . . . . . . . . . . . . . . . . . 4Changing Direction . . . . . . . . . . . . . . . . . . . . . 4Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapter One - Describingthe Problem

Why should you read this book? - because it offers answers to thefollowing:

• How you can best set up my organisation to deliver the mostdesirable products and solutions to my customers.

• How you can gather fast feedback about what works andwhat doesn’t.

• How you can focus my organisation around what reallymatters.

• How you can make sense of all of the different frameworksout there and decide which is right for your situation.

Target Audience

This book is being written for people working in software devel-opment who ideally have a basic knowledge of Agile, Scrum andLean. I would recommend you take a quick look at these first if youknow nothing about them, before you start reading.

Principles, Frameworks andMethodologies

Let’s start with defining a few words:

• Principle: A fundamental truth that explains how somethinghappens or works.

Chapter One - Describing the Problem 2

• Framework: A loose incomplete structure that can allowother practices to be included but still providing most of theprocesses required.

• Methodology: A set of principles and rules that help solvedifferent problems within the scope of a particular discipline.In other words we’re solving a particular type of problem andwe’re going to use a suitable methodology to solve it.

Princple Framework Methodology

Compare and Contrast

Many people today want all the answers to how to deliver productswritten down in one neat place. We see this with methodolo-gies such as PRINCE2 and ITIL. Their intentions are good butdogmatically applying them can cause problems. Unfortunatelythese methodologies grow and grow adding layer upon layer ofcomplexity and “best practice” in response to complex problemsthat can’t easily be solved with just one approach. At their coreare principles, such as this one from the Agile Manifesto:

• Responding to change over following a plan.

Contrast this with the PRINCE2 principle usually implementedwith its favoured Gantt plans:

Chapter One - Describing the Problem 3

• Manage by Stages.

If I was being controversial I could even write: Planning overresponding to change. Of course I am aware of “change control” butcontrast this with Agile, which actively accepts change as part of aprioritised backlog. In plan driven development we try to fix scope,and if we can, both time and cost too. Usually we’ve set out oneversion of the truth in a plan and that’s what the customer expectsto get. Here we can see the two triangles:

Cost Scope Time

Agile accepts regular re-prioritisation of features, but more thanthat, it can accept entirely different solutions as to how they aredelivered throughout the product delivery period as long as theyfit the time-scales. In other words it openly accepts and promotesdifferent versions of the truth.

Frameworks suffer from a different problem to methodologies thattry to prescribe everything, these are meant to be flexible and addedto, but often people don’t add to them and treat them as complete.For example why not combine the best of Kanban and Scrum? Thereare benefits to both.

Chapter One - Describing the Problem 4

Measuring Successfulness

To look for one controlled and measurable way to give yourorganisation the power to succeed is a natural response. If everyoneknows exactly what “best” looks like we can mature our processesuntil we become the best. If we’re failing we blame ourselves for notbeing good enough at using the methodology (or blame ourselvesfor not understanding how to apply it). We can train, assess andmeasure our people. This is a simple response culminating withyour latest Agile sponsor trying to measure how “Agile” everyoneis.

Changing Direction

As the news filtered through that the principles of Agile wereeffective and there were statistics to prove it, companies foundit more and more difficult to ignore it. Even existing popularmethodologies were forced to adapt to it in their own way; oftenrefusing to throw their flawed learning out but rather creatinga new hybrid “best” practice guide. Many companies embracedScrum as the Agile framework of choice. Scrum is a lightweightframework, in other words, it is not heavily prescriptive about howyou do everything.

Due to its lightweight nature, organisations began to find it difficultto implement into their existing structures. Exactly how does mycompany change to fit the structure of:

• Scrum Master.• Product Owner.• Team (the classification for anyone else).

Companies were busy building multi-million pound projects in theway they always had and were somewhat puzzled as to how things

Chapter One - Describing the Problem 5

would nowwork. Serious questions aroundAgile and Scrum startedto arise:

• How do I fit my programme team, project managers anddevelopment manager into this?

• How do I get my products delivered if they’re really big andI have lots of teams?

• I guess I can follow the Scrum of Scrums for communicationbut is that all I need to scale this new thing?

Companies found themselves struggling with Scrum at scale andimplementing its simple structure directly into a world of com-mand and control project and programme managers. What usuallyhappened was that a few developers and testers were allowed toplay Scrum within their existing organisational structure. Outsideof it were our programme and project teams who built the basisof a project and sent it through the Scrum “sausage machine”, tothen be picked up by the service side of the organisation . This isusually known as Water-Scrum-Fall. Project managers now startedmeasuring story points and explaining when things would be done,whilst keeping a RAID log and reporting to a programme board.Whilst a little more uncertain than the beloved Gantt chart it gavesome degree of control.

Companies tried to get more Agile by bringing in experiencedcoaches who despaired at the existing set up, fixed as much as theycould and then departed to “rescue” the next place.

All the while the purists were defeated by the issue that differentcompanies, project sizes (AKA systems) needed different solutionsand took a long time to adapt to change. If I run into a restaurantand shout, “Everyone get out!”, the response may be completelydifferent depending who is there. I can try and predict what willhappen but I don’t truly know. Changing something complex isdifficult and unpredictable.

Chapter One - Describing the Problem 6

In response to this we have seen a huge growth in competingframeworks (sometimes methodologies) to help Scrum along.

Summary

So where does this leave us?

In this book I’m going to focus on underlying principles and waysof thinking in order to help you understand what the frameworksand methodologies really mean to your organisation. I’m also goingto use examples to help you understand how to improve. Let’sconsider (i) a simple defect that needs to be delivered and (ii) amulti-million pound financial system. We wouldn’t put the samedelivery structures around these two changes.