Delivery Issues

Last year, we had a major delivery issue. We were struggling to deliver bug-free software on time. When we got into quarter one of this year, we realized that we had to put a stop to the madness, here's how...

The first thing we had to figure out is, was this an issue between the keys and the screen. Was the team lacking skills? Were we asking too much of our devs?

I spent a lot of time in my career thinking that to be great dev, you had to be some kind of math genius, or possess some special skills. These were skills that I just didn't have, so greatness was somehow always going to be out of reach.

Then I went to an agile course and they put this quote up on the screen:

“I'm not a great programmer; I'm just a good programmer with great habits.” -- Kent Beck

It forever changed my perspective. I stopped focusing on figuring out if I was a savant and focused on my habits.

At the time we struggled with delivery, I was reading No Rules Rules by Reid Hastings. If you've read the book, my fear was that we were having a talent density problem. The team was perhaps to inexperienced to work at the velocity we were asking them to.

Books have an uncanny way of influencing our thoughts during the time we are reading them. This book had me looking at talent density for problems. But then I remembered that Kent Beck quote.

I realized that greatness is such an amorphous term. What is a great dev? Are all devs great at all the things? As an agency, there's no way we can have exactly the right person for every problem we encounter.

We had to develop great habits, habits that would guide us through any problem, and help us deliver consistently. Perfect programmers and as a result, programs don't exist. We get closer to perfection through iteration, this is at the core of agile.

But we were operating in a waterfall. We followed the process I did at every agency. There's a problem or goal express, the sales team scopes it, then doubles their estimate for safety. The design team designs the whole thing. The client approves. Finally, we develop.

While in development we said we were agile. We had project boards with columns, we had some loosely defined sprints. We did bi-weekly reviews with the client. But the devs built to an immutable blueprint. No matter how many times we said the word agile, this wasn't it.

So what are great habits for all projects? How can we operate in an agile way when we have to scope during a sales process? Do we add all the devs to all the sales and discovery calls?

No, this is simply attempting to fix a waterfall by freezing it.

First, we killed fixed scopes for everything but small projects (4 - 6 weeks). From now on every project is a journey with the client. We either use time and materials as a guide (hourly billing) or we set up a monthly subscription when the engagement is long.

Next we introduced user story mapping as a requirement before any build. During this phase we let the clients go wild. Nothing is too grand or off-limits, let's map the entire problem together.

Then we work to define our MVP. What does a first release look like? What is the minimum viable solution? This is different for every client but this part is critical. I like to say you will get 100% of what you need in this release even if that's only 50% of what you want.

Next we merged design and dev. These were no longer going to be looked at as separate phases. They needed shared understanding and they needed to be viewed as a cohesive unit. Devs need to feel connected to the users and design needed to feel connected to the medium itself.

Finally we introduced true iterations. We run a two week sprint process, but those sprints are not always building. It's ok to spend cycles planning, it's ok to spend cycles improving the code and eliminating tech debt based on new understanding.

We had to behave more like a product org and less like an agency (in the traditional sense). Our sprints turned into group collaborations between clients, designers, developers, and product folks. We don't "shield" parts of the team anymore. We're all here for the same goal.

The result... last week we had a major launch built by a team of junior engineers. They worked with the client, they worked with design, they validated their assumptions, caught issues early, and ultimately launched on time with no bugs. In short, they had great habits.

In tech there is a massive focus so-called A-players, 10x devs, rock stars, etc. But this is a lazy way to build great teams, and often foolish. Create an environment of collaboration, where people can form great habits and you'll ship better software, more often, consistently.