Capturing the Spirit of Agile: Your Process Should Be Simple, Continuous and Entirely Your Own

“Will we be using Scrum or Kanban? What about Scrumban?”.

One of the first things I get asked in a client engagement, often on day one, is: What kind of agile process are we going to use?

This question is always asked with a degree of anxiety. The client wants this answered urgently, I think, so that they can put it in a box and not worry about it again.

The problem with this approach is that it follows unthinking, prescribed and static “Agile” which, when you write it down as a description, is a contradiction in terms.

If you can name your process, you’re not doing Agile right!

I always encourage these teams to get back to the spirit of agile. My advice? Your agile process needs to be simple, agile and yours.

But how can teams achieve this?

Get back to the Principles

The agile movement was launched in 2001 with nothing more than the Agile Manifesto and the Twelve Principles behind the Agile Manifesto. These are the root documents that have informed almost two decades of agile thinking in software development.

When it comes to growing a process with a new team, the Twelve Principles are a good place to start. This does require a spirit of adventure!

Agile The Movie: Attack of the Waterfall

Allow me to demonstrate some typical challenges in growing an Agile process, with the help of some Agile heros: Ward Beck, Kent Cunningham and their Agile coach, Martina Fowler.

They just started a new Agile project and are deciding how they are going to approach it...

OPENING SCENE: Scrum or Kanban?

The team tries to determine what kind of Agile they will be using going forward.

Beck: “Will we be using Scrum or Kanban?”

Fowler: “I don’t know”

Beck: “Scrumban?”

Fowler: “I don’t know”

Beck: <faints>

Cunningham: “We have to know! How else can we start?”

Fowler: “We’ll figure it out as we go along”

Cunningham: <faints>

SCENE TWO: Know your customer

The team regroups by turning to the Agile Manifesto.

Fowler: “Here, take these documents. These are the principles behind the Agile Manifesto. Have a read and let me know if anything stands out to you.”

Cunningham: “I like the first principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Beck: <nods enthusiastically>

Fowler: “Ok, that’s a good place to start. Do we know who the customer is?”

Beck and Cunningham: <silence>

Fowler: “Why are we here doing this project? Who commissioned it?”

Beck: “Roberta commissioned it. Roberta C Martin, the CEO. Been around a long time, very solid.”

Fowler: “Shall we get Roberta in here, then, and ask what she needs?”

SCENE THREE: Know what you are building

They talk to the CEO to get a steer on the direction of their project.

Cunningham: “Roberta, what kind of software system are you looking for us to produce?”

C. Martin: “We need a new way to sell insurance to our customers….”

Beck and Cunningham: <sprint to their keyboards>

Fowler: “Fellas, come back, we’re not finished….”

Beck: “It’s ok, we have some ideas as to how we could do that better. We’ve been saying it for months!”.

Cunningham: <furiously typing>

Fowler to C. Martin: <sighs> Ok, give them space…

C.Martin: <sighs and leaves>

SCENE FOUR (six weeks later): If only we’d listened…

The team receive some difficult feedback.

Cunningham and Beck to Fowler: Get Roberta in here, we have something to show her….

C. Martin: <arrives, eyebrows raised>

Beck: <demos the insurance sales website> Pretty awesome, eh? Especially the spinners, took us ages to get those right.

C. Martin: Fellas, yes, the spinners are lovely, great job, but we need a mobile app, not a website. In our first meeting, you left before I had a chance to explain! Also, we’re spinning out a new brand, so the colours are all wrong. And we want to be able to sell multiple products at a single visit, not just one….”

Beck: So something like a shopping basket of our insurance products?

C. Martin: Yeah, that might work.

Cunningham: <scribbling> Got it.

C. Martin: We also want much better visibility on how our customers are engaging with the app so we can be evidence based in our UX decisions.

Cunningham and Beck: <both scribbling now>

C. Martin: And we want to introduce a strong social element, so people can get rewarded for promoting our products…..

SCENE FIVE (60 minutes later): Back to the principles

Fowler: So fellas, both of you now have pages of notes on what Roberta needs. It took us six weeks and a lot of wasted coding to get here. Can we continue reading the Principles and see what else we can learn?

Beck: Look at this one: “Business people and developers must work together daily throughout the project”. We spent six weeks without talking to Roberta….

Cunningham: Yeah, and that’s especially bad when you look at the one above it: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”. That’s pretty smart! If we had come back quicker to Roberta we would have only wasted a couple of weeks work.

Fowler: But look at what Beck called out: daily meetings with the customer…

Cunningham: True, if we had been doing that, we could not have gone down the rabbit hole at all! It would have been impossible to get so off track due to the customer feedback.

Fowler: Right, lets ask Roberta and see if that’s possible. What else?

Beck: You and I, Cunningham, we need to compare our notes and make sure we have a shared understanding of what needs to be built...

Cunningham: ...and Roberta needs to agree too. All three of us need a shared understanding.

Beck: Good point. Maybe we can write it up as a todo list on the whiteboard there. Then get Roberta to review it.

Fowler: Great idea, sounds good. Any other good bits in the Principles?

Cunningham: Hah! Look at the last one: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”. We’re doing that right now! It’s too funny. These ideas are wise.

Fowler: They are indeed, great ideas to lean on. Have you anything more to say on this one? Like how regular should the intervals be?”

Beck: We’re doing it right now. Naturally it seems. In response to something going badly wrong. I guess we could do it each time something goes wrong?

Fowler: Ok, but that might not be regular. The principle says regular….are you ok with that?

Cunningham: It’s a start. We could agree as a team that we will reflect as soon and as often as we realise something bad has happened. Bit vague I know, but to get the ball rolling….”

Beck: Let’s do it, we can adjust if we need to.

“Let’s do it, we can adjust if we need to”

When you hear one of your team saying that, you know the spirit of agile has taken hold.

Your team is now thinking for themselves instead of adopting a prescribed technique. No longer is Agile in a box as a defined thing but rather, it’s a living, morphing way of working.

Our little scenario is obviously an exaggeration, especially the idea that Fowler and C.Martin would allow Beck and Cunningham to go off on their coding binge for six weeks. But it highlights some common challenges and how these are overcome.

After a very costly mistake, our team is now:

• Sitting with the business and working with them daily
• Using face-to-face communication
• Using a visible feature list
• Reflecting as often as they feel the need
• Building in small batches
• Getting more excited and involved
• Attentive to the Principles of Agile
• Thinking for themselves

I’m confident that if we followed this team on their journey, they’d find their way to a full continuous delivery and DevOps way of working.

It’s a pity they are fictional because I’d like to high-five them.

The Problem with a Prescribed Agile Environment

Imagine being air-dropped onto the top of Everest and expected to know all about mountaineering. In my experience, that’s a bit like taking on agile after training as a Scrum Master. The danger in learning this way is believing that all there is to agile is Scrum. There are exceptions of course, but in general, your understanding of why the constituent practices in Scrum have been chosen will be limited and not experientially informed.

Why this particular set of practices with these particular frequencies? What forces are being balanced and why? And do those forces apply to my organisation or team?

In prescribed agile environments, people don’t understand agility in terms of its principles. Agile is done by rote with teams relying on “agile tools” like Jira, with epics and stories and burndown charts. This is difficult to square with the Manifesto statement: Individuals and interactions over processes and tools.

Your Agile Process Should Be Simple, Agile and Yours

One of the fun things about working with an agile process is that agile thinking must be applied to the process itself.

You don’t just get something out-of-the-box that remains a static way of working over months and years.

Start with nothing other than the agile manifesto, throw in continuous reflection on what you're doing, a bit of continuous improvement from the principles, and trust your nose to steer you to the smallest process necessary for you to work well in the context of your particular environment.

It’s unlikely you will end up with Scrum. But even if by some chance you did, you will have an experientially informed understanding as to why you are doing Scrum. And because Scrum is not a destination, you will be positioned to move beyond it, due to the fact that you are experienced in evolving your process.

How to Make Your Agile Process Yours

Once you have a stable process in place that fits your team, the temptation is to replicate this process in other teams across your organisation. Don’t make this mistake!

Making your agile process yours refers to your team, not your organisation.

Other teams will have different forces exerted on them; they will be made up of different people, doing different kinds of work. Every team will therefore need to grow their own, unique agile process. That’s not to say that teams in your organisation shouldn’t communicate and share ideas, but never view the company’s agile method as something static.

Your people will need to be coached on the principles, and supported as they grow and evolve as a team. The Agile Manifesto and the Twelve Principles behind the Agile Manifesto can be their guiding lights on this journey.

Good luck!