A lot of people have asked me why I left a good job in Police ICT to sign up for R9 Accelerator. To be honest, I’ve asked myself that a few times over the past 14 weeks too. The short (and trite) answer, is to make a difference. The long answer is, well, longer.
I suppose I got to a point in my career where I had seen enough clever people and good intentions flounder (or get severely hampered) because of big project processes. Huge business cases, ripe with assumptions and their associated risks, trying to steamroll reality into submission. Project staff knowing something was amiss, but simply unable to alter anything. Even running projects with Agile didn’t help much – by then the general course was set, expectations laid out, business owners to satisfy. Big Business Cases. Big Plans. Big Assumptions. Big Pain!
I knew there must be another way – a better way. Something other than taking an untested (or at best marginally tested) idea, and building the unyielding machinery of a big project around it. After all, even reasonable ideas must be allowed to crash on the rocks of the reality they are at odds with.
As luck would have it, there was another way. Enter stage left – Lean Start Up. R9 announced the Accelerator 2.0, which would use Lean Start Up methods to try and solve the previously intractable problems government has delivering services to NZ’s business community. It sounded too good an opportunity to miss. A 12 week programme putting the customer first, learning to iterate around real problems and co-designing relevant solutions. To identify the assumptions, and test them as early as possible, remove the risks that would otherwise hurt you down the track. I was hooked – I signed up. It was a good decision.
Ten teams emerged for the accelerator, some with narrow focus, some broad. Our brief fell into the latter category – tailor government interactions to suit business, while testing a new service delivery model for Government. Say it quickly with a smile and it won’t terrify you so much.
In the face of something so daunting (to us, at least) we had a couple of options. One was project paralysis – we were worried that the size of this could turn us into a mob of deer in the headlights. (And it’s worth remembering that, in this case, the headlight was the oncoming train of Demo Day at the Embassy. Our team’s first success criterion was to get through Demo Day without looking like chumps – or the other word we actually used.
The second option – the option we took – was to start taking really small steps. The accelerator had primed us with the Lean theory, and we took the leap of faith into fast-iteration Lean practice. We went fully customer-centric. We asked businesses about issues they had. We developed a hypothesis about their pain points, and called them back to test our ideas. Then we learned some more, built a new theory, and tested that. There are lots of names for this loop of validated learning. I like build–test–learn. For each cycle we’d reorient a bit, forever changing course, homing in. Although there are lots more subtle influences involved, it’s fair to say we were always customer-led, keeping in mind government’s desired outcomes.
It was great. It was better than great. It was liberating. To feel the weight of sentiment (most businesses didn’t hold back!) out there, to understand someone’s situation, and to want to make it better. And above all else, we know that we are trying to solve something that really matters to people. Much better than a good-sounding idea we’d come up with interviewing ourselves! Talking to customers is powerful stuff, all right.
We started with farming. We had a huge pivot around week three, when our excitement about a new way to help environmental compliance in dairy farms met the rocks of reality that was Dairy NZ’s farm WoF scheme. It was a tough time – ideas are a bit like children, and when one isn’t going to make it there is a kind of grieving process. No, it’s not like the real thing, but it hurts.
But that’s where Lean wins out over traditional project initiation. Assumption tested – risk was real: Don’t proceed. People talk about ‘Failing Fast’ – we found out what that really feels like.
We pivoted to creating authority to act for bookkeepers and other professionals, something that causes much angst among businesses. Through the same fast iterations, we added the client sign-up process, and started co-designing a solution that we and our early adopters think will do that thing we’re in this for – make a difference.
Lean is really working for us in Team 2Shakes. We are supported by R9 and Creative HQ in the funding process to build our solution for bookkeepers. We’ll keep iterating, and integrate Lean with Agile as we develop (not all Agile is Lean!).
The funny thing for me is how familiar Lean feels. Maybe that’s not a huge surprise. I studied manufacturing sciences many years ago, and Lean developed in Japanese factories as a way of minimising waste (effort and resource). I think my brain has been dusting down some 30-year-old engineering concepts, and giving them a fresh new set of software development clothes.
What about the new service delivery model for government? Well, for the 2Shakes solution we feel we’ve managed to get a tick in that box. Maybe even extending the box a bit by working across private and public sector organisations.
But wouldn’t it be great if we weren’t just improving the delivery of government services? Wouldn’t it be awesome if Lean was used further and further upstream in government projects, so all those risks and assumptions could be tested early by talking to real people living real stories? Bit by bit, we could start improving the initiation, the design, and the delivery of services…wait a minute. Maybe that’s why I went on the Accelerator after all.
