A Practical Example of Agility
Wherever I look these days, so much agile commentary seems to be overly academic and abstract, or focuses far too heavily on dogma and process. I can’t help feeling that rather than helping, we are alienating.
Coaches blog about systems and queuing theory; Consultants are selling their own branded ‘flavour’ of agile with diagrams and flow charts. Promising successful shifts and digital transformations, they’re all very convincing but this is a level above what most are trying to achieve. So many organisations recognise their waterfall-like processes aren’t right, but this conversation makes the transition seem way too hard. No wonder people are saying scrum should die in a fire and agile is dead.
Elsewhere, agencies are rebranding to offer product services, reinforcing their “Agile” ways of working. But when you look closely there are still up-front strategies and deliverables and you realise it’s simply another buzzword to them.
I’m concerned we’re at risk of losing what it means to be agile, and making it too complicated.
Operating with agility means to go about what we do on a daily basis acknowledging that we’re most likely wrong. Encouraging changing details, delaying decision making and collaborating with our team and our customers.
Dave Thomas puts it best:
- Find out where you are
- Take a small step towards your goal
- Adjust your understanding based on what you learned
I want to try to show why we believe in agility with an example that will hopefully be striking by its simplicity.
Before I do, a couple of things to note:
I acknowledge this is a relatively small project — this is deliberate, so that I can go into the full lifecycle in a single post. Yes, on a bigger scale there is a little extra complexity, but broadly speaking, the techniques we use are the same.
That this project was completed by the team here at Parachute makes it an even stronger example. We build our own products, but acted as an agency in this case. There’s a lot of resistance when we talk about agencies working in an agile way — the client won’t go for it, we need signed off scope etc — but this example shows it not only works, but delivers a lot of value.
Introduction: A familiar scenario
The phone rang. It was one of our clients describing a bit of a last minute panic. They had a problem that needed solving, with a tight turnaround time. “I’ve just sent you the brief, hopefully you can help!”
Ah, the brief.
Cue the nightmare of hours extracting tenuous details about a product to draw up a scope of work, write a contract including fixed deliverables and timescales.
As I read the pages of text describing a piece of software I wouldn’t inflict on my worst enemy, my initial reaction was that there was no way I’d be able to make enough sense of this to put a proposal together in the time limits. Further, Parachute have never really taken on work like this. We tend to focus on solving problems, not pitching and certainly not building to spec.
The brief was full of holes and contradictions. Clearly rushed. Uninspired, but resisting the urge to no bid, I suggested we instead meet for coffee the next day.
I explained that I couldn’t help in the traditional way they were used to. But, if they wanted to try something new, I was confident we could solve their problem.
So, armed with a pad of paper and a sharpie, we spent an hour together sketching out the problem. How it was being solved now? Why is that way broken? Who are the users? The stakeholders? An hour is all it took to get a pretty good shared understanding of what needed to be done. I honestly believe more time was put in to writing the brief than it took to sketch out the whole thing end to end.
As expected, the next question came. How much will this cost?
Use your experience
Now, this is an agile post, so you’re expecting me to describe an elaborate game of planning poker where we triangulate estimates and forecast velocity to produce a best and worst case scenario and then multiply by day rates, right? Well, sorry to disappoint. I sat in the car and spoke to my colleague for about 90 secs about what we’d learned that morning. And then we compared it to things we’d done in the past. The conversation went something like this:
“I’m still not sure of everything that needs to go into this, but I feel we know enough.”
“Remember project X we did last year? This is similar to that…”
“You’re right, simpler if anything. Also, Project Y.”
“Well, those were both done within £X, I’m confident we can do this within the same.”
And with that, we had our estimate. It wasn’t perfect, but it was good enough and produced a number that allowed us to feel comfortable, and that ensured value for the client.
Fill in the gaps
We obviously hadn’t covered every edge case and idea in that one hour. We knew there would be holes still. What we needed was a way to find those holes — to shine a light on the project and see what got through.
Our torch was a prototype. We scaffolded the user journey end to end and delivered it back to our client. It was ugly and clunky, and not something many would feel comfortable presenting. We’d been here before and knew it would be ok, but the reaction surprised even us;
“WOW! You’ve basically done it!” (we really hadn’t)
“Yes! this is exactly it” (it wasn’t, we knew it wasn’t)
“Oh, actually, this field should include tax. And that means the result is wrong.” (that’s more like it…)
“And…actually this calculation is a bit off. I forgot that sometimes A happens, so you don’t do B in that case” (great, we’d never have spotted that)
“I think this part would work better this way around. The users don’t think that way. Sorry, is this scope creep?” (no. It’s learning!)
We had made assumptions and been able to test them very, very quickly. We could have spent days writing specifications and contracts but they would never have achieved what we did with that prototype. We now had a significantly improved idea of what the product needed to do and how it should work. We’d learned things that would never have been extrapolated from a spec or scope document.
This is my favourite part of any project, the moment all the pieces start falling in to place and we know we’re headed in the right direction. Everyone gets excited, because the fear of the wrong thing being built is visibly fading.
We went back to work. Incorporated the learning, tightened up the architecture, brushed up the interface a bit. Then, we put it into the hands of the people who would ultimately be using it. The app was already ‘potentially shippable’.
We asked the users to replicate their workflow through this new app — try to do what you usually do, but using this. We instantly saw some interface improvements we could make. So, we made them. Right there and then, relaunched the app and tried again.
We also noticed that things we thought obvious weren’t. For reasons we’d never have known, their workflow was different — “Ah, but if the customer sees that part I have an awkward question to answer, so can it be hidden?”
This is where many agencies start to worry. The app doesn’t work perfectly, they see dwindling profits so they panic and fill in hideous instruction text or try to educate the users against using it wrong. But, we expected and embraced this and built the app in a way that kept cost of change low. So, we changed. And it got better and better each time.
By the end of that day, new users were picking up the (still ugly and clunky) app and instantly getting to grips with it. They were excited — it made their lives easier, they wanted the app right now! No training needed, no instruction manual. Just an intuitive app that did what they needed, in the way they know how to do it.
And that was it. No sprint planning. No Jira. No formal retrospectives. No velocity or burndown. Just building with agility.
In the end, we went from brief to prototype in two days. And from handover to ‘launch’ in another two. There was no training, no bugs stopping the rollout of the product, or amends to cycle through. This collaborative way of working with our customer meant when we delivered the final app, they already knew it worked.
The final app wasn’t what was in the brief. It was entirely different in a lot of ways but it ticked all the boxes in terms of outcomes. It did the job it was designed to do, in a better and more efficient way than the customer could have possibly expected.
“I presented this yesterday and they loved it!! So big thanks for making me look good ;) and producing such an awesome product!” — [The Client]
And for those wondering, yes, the project came in on time and on budget.
Label this approach what you like — agile, lean, shiny new buzzword — it doesn’t really matter. All we really did was throw our ego out the window, assumed we were wrong, led with an open mind and collaborated with the people who would ultimately be affected by our decisions. We followed agile principles. Because they work.