Rediscovering Lean

Introduction

For those who love continuous improvement, software engineering fits. Turn in any direction and you’ll see potential for doing better, going faster and increasing quality. You can adopt new methodologies, master practices and capabilities, read from thousands of books, and sample hundreds of thousands of videos with the promise of better outcomes. 

I myself improved, going from no process to waterfall, SCRUM, and Kanban, adopting TDD, BDD to CI/CD, migrating monoliths to microservices, and graduating from working off requirements documents to running autonomous teams. 

These changes worked. Based on the metrics outlined in the excellent book "Accelerate" (Lead Time, Deployment Frequency, Mean Time to Restore and Change Fail Percentage), I was performing at a high level. Or was I? 

Stress

The trouble is, deep down, I knew I was not! My engineering metrics were great, better than ever. But my Pirate metrics (AAARRR!) sucked. Where was the real user impact I wanted? I grew weary. Each new initiative and with every one of those practices I adopted, I changed how I worked, which required conscious effort to discover, learn, implement and refine. Spending all my mental energy on improving delivery metrics was bad; continuously improving the wrong thing was worse.

In the middle of this crisis of confidence, my head of engineering asked me to lead the development of a new mobile product. This was a big deal based on a real user need we could address. Along with it also came a large chance of failure. A year previously, I would have jumped on it. But with more self-awareness around my limitations delivering on such a large project, I wavered.

The Opportunity

With my approach not working, I needed to change. Was a killer process to solve my problems just around the corner, awaiting discovery? Or should I stick to where I was, and bring more discipline in my application? Luckily, my reading list at the time mirrored my more reflective mood. 

Reading "The Goal" by Eli Goldratt made it clear I was focusing on the wrong things, that these processes and practices were a proxy for real work. Marty Cagan, in "Inspired", reminded me why I got into software: not to be the greatest engineer, but to build products people love. "Coaching for Performance" by John Whitmore gave me confidence that my team and I were best placed to solve our own problems.

I decided to change; to get off the agile capabilities and tactics hamster wheel and put my efforts into this new goal and the customer problems it solved.

The Foundation

The key difference in this project that made it stand out from all of my previous projects was this goal:

Make a sale of this new mobile product within six months.

Most goals in life start out clean. But by the time the people doing the work receive them, they are stretched way out of reality and filled with ambiguity. 

Consider this goal, for example: increase the quality and reliability of the sales dashboard. Seems simple right? These "ilities" are great, but when resources are tight, which one wins? 

Ambiguity leaves an autonomous team scrambling, In this case, they scramble trying to define whose competing definition of quality is the right one, and how much reliability is enough!

Instead, give them clear guidelines within which to be creative. They require a model on which to objectively base their decisions. Our goal gave us a six-month runway, with the customer front and centre. Not solving a real problem for them would mean no sale!

Trust

Explicit customer focus had an immediate impact on team behaviour. We loved debating the pro’s and con’s of technical approaches, architectures and process. But this time we poured over product research, pulled more background from the business, and got deeper into the "why". It was clear that the strategic importance of this project, and the trust the company placed in the team to deliver on it, was huge. 

Ownership and initiative grew with this trust and motivation. One engineer whose default mode was build mode, rather than drive forward, asked what we wanted to learn first. What evidence we could gather to tell if our six-month bet was the right one to take?

The Concept

This was the right question to ask. We didn’t dive headfirst into the build. Instead, we identified an opportunity to learn and measure. There was a customer summit coming up in three weeks, with 300 of our most valued customers scheduled to attend. What were the problems this mobile app would solve for them? How important was it that we solve them? 

If we as a team were committing, then we wanted some commitment in return. Getting five customers to sign up to a pilot program to collaborate with us on building out the product over the following five months was our key measure of that commitment. Not reaching that number meant new information for the business. To run this test, we had to get building, and fast!

It was back to basics: a whiteboard and a marker (stickies always fall off!) to organize our work. With the goal of giving clear guidance and having a motivated team, we needed nothing more. What we achieved in those three weeks was remarkable. We got a functioning M.V.P. app and a mobile backend into users’ hands. We did this not by working faster, but by making difficult choices and cutting out all waste, for example:

• Writing no unit tests. Getting in front of users so we could learn was the number one priority, not writing the cleanest code.
• Having no silos on our cross-functional team. Rather than polish up screen designs, our UX designer learned react-native to help with the app build!
• Leveraging cloud-native services. I’ll never forget the look on our CEO’s face when he passed by two days into the project only for us to give him a demo of the authentication functionality of the app working.

And before you choke at the mention of no unit testing, we built quality in by throwing away ALL this code and starting fresh. I could talk with the team tester about what quality represented to us at that point in the project, and could make unbiased decisions around it. You see, having a specific goal meant waste was easy to define. Shortcuts are everywhere when you know where you are going.

"If we do not know who the customer is, we do not know what quality is." Lean Startup, Eric Ries

The customer summit and feedback we got exceeded our expectations, with eight signing up to our pilot program, keen to give a hand in shaping the app around their needs. But before we moved onto this next phase, I regressed…

Regression

I was keen to get the pilot off to the best possible start. The organic and fluid style we took during the proof of concept would have to change. With customers now involved, we needed more structure. In order to set us on the right path, I felt compelled to hold a more traditional-style weekly planning meeting. This turned out to be a horrible idea. 

An observer in that meeting would have noted one or two people talking, and the rest with their heads down wishing they were somewhere else. This contrasted with the energy and engagement levels of the previous three weeks. I was bringing my solutions to the group’s problem (of how to run the pilot), without involving them; a sure way to lose a good team. The people doing the work, those with the problem, are best positioned to solve it. 

"To get the best out of people, we have to believe the best is in there" Coaching for Performance, John Whitmore

It turns out that they enjoyed the lightweight way we had worked since beginning the project. They felt we could run the pilot the same way. We sat next to each other; we enjoyed open communication. When blockers arose, we worked through them. When multiple options presented themselves, we collaborated on the best way forward. We extended this openness to our customers as well. Our whiteboard was a simple information radiator whose limited space kept our work in progress and simple backlog in check. That was enough. No horrible meetings, no ceremony, just focusing on the work.

Does this approach work for all teams? Probably not. But for this particular team, it suited perfectly! Happy, working as we wanted, the pilot started to gain momentum.

The Pilot

Weekly customer calls where you demo, get feedback, solve problems, and discuss options are the lifeblood of any pilot. In software, that feeling you are behind the curve can become the norm. This customer contact remedies that, creating empathy and driving team performance. For us this resulted in getting ahead. At the start of one particular call, the customer jumped straight into a problem she had. It turns out, we had just released a feature that morning to solve that very use case!

But things were not always so heroic. During a team discussion on our users’ major pain point, we gravitated towards a particular solution. Without stopping to question it, we grabbed markers and proceeded to the whiteboard to map out the design and architecture around it. Good times! A few hours later, and with two months of work mapped out, we were satisfied. We could see the power in our solution.

"Jumping to conclusions is a safer sport in the world of our imagination than it is in reality" Thinking Fast and Slow, Daniel Kahneman

This is an example of doing something very dangerous: jumping to conclusions. After two minutes of getting out of our team bubble and talking to actual users, it became clear we were over-complicating the whole thing. Luckily for us, they steered us in another simpler direction. It took us roughly two days to implement what they were looking for. From tracking the usage metrics and feedback around this, we could see it was what they needed. Two months of work saved from just two minutes conversation!

We were on the road to delivering a great product; the team was happy, the pilot customers happy. But that was not enough.

The Sale

Look back at the goal. Deliver on a sellable product, not just a minimum viable product. My engineering-centric view, optimising the development and delivery of the software, forms only part of that story. 

Creating a strong product was pointless if we were not working in line with other functions in the company- with our sales and marketing departments to generate and develop leads, and with customer services ready if and when a sale happened, to make sure the customer had a great experience. There was more to life than engineering.

Forming a fully cross-functional team early on kept us in sync. This team owned the full value stream map from concept right through the sale to onboarding, with members from most functions around the business. This unit was key in identifying and working through any bottlenecks that arose across the business on any given week. 

This approach was slow at times. At this stage of development, the product was changing rapidly with functionality and design in constant flux. Having to communicate this outside of the development team was an overhead I found easier to ignore. This drift quickly bubbled to the surface.

This wider team meeting weekly meant concerns were raised and tackled, instead of left festering. In this case, product marketing came and sat with the engineering team for two months. They saw firsthand how the product was developing and landing with pilot users. They took this into account in their marketing efforts, and also easily fed back ideas arising from market research and the positioning of the product.

Rather than repeating some of my previous failures where I ended up with a great engineering outcome, but muted results in terms of business value, this cross-functional team created an alignment that resulted in us delivering on a sale together. This deal was closed on the last Friday of our six-month period! 

Success

This first sale and achieving that goal was extremely satisfying for me. Over the coming weeks, a large proportion of our pilot customers converted buyers of the product, which was a tremendous validation of our close collaboration during the early development of the product.

In describing the journey from concept to sale above, I gave many examples of things like waste, learning, trust, speed, and quality guiding our decisions. These are examples of Lean principles in action: 

• Having a specific goal allowed us to "eliminate waste". 
• We "deferred commitment" by deciding to prove the concept, rather than diving in to build it.
• Then we "delivered fast" on that three-week proof of concept. 
• We "built quality in" by throwing away that P.O.C. 
• Working with customers through the pilot "created knowledge".
• Allowing the team doing the work to decide on how best to do it "respected people". 
• Finally, and crucially, aligning across multiple functions in the business "optimised the whole" value stream.

"But wait a minute. I thought you said you didn’t follow any methodologies?" Well, it turns out I did. I was lean! All those years of learning and adopting various practices and techniques had left their mark. I had absorbed the principles behind them without being truly aware of it. Focusing on the goal, our users, and what felt right as a team, allowed them to finally come to the surface in a way that led me to the success I was searching for.

Conclusion

Choosing an approach to product development is hard. Even with a decision made, it takes a real effort to implement, so much so that you lose sight of why you are doing it in the first place.

"For success, like happiness cannot be pursued; it must ensue" Victor E Frankl

My advice is simple. Stop chasing the latest and greatest agile practices. There is a seemingly endless combination of them, and your time and energy are limited. Instead, spend that time working out your unique approach based on the goal you have been given, the people you have, and the underlying principles that you hold, be they lean or otherwise. This foundation will make the practices you do apply all the more meaningful and successful and will lead to better outcomes, happier teams, and maybe even a sale or two.

About the Author 

Kevin Duggan is mobile lead at Poppulo (an internal communications software company), in Cork Ireland. He has spent over fifteen years building products and teams. When Kevin isn’t writing code, he can be found racing mountain bikes, running, and playing guitar. In a former life, he was also a champion Irish dancer who toured worldwide. Here is his website.