Quick and Quality

“If you need it bad, that’s how you’re gonna get it.”

In our microwave world, we want (or need) things done quickly.  If you rush a job, quality suffers.  How do we resolve this paradox?

Many businesses are doing something right.  Our furnace recently died in the cold of winter; the two companies with the fastest response also have top reviews for quality.  Perhaps that can be explained away with repetitive processes.  But what about quality plus innovation?  Complicated, unpredictable processes? New product development?  Complex systems architectures and design?

Submit to the Triple Constraint…?

In the world of complex systems, professional project managers for years controlled conflicting priorities with a tradeoff model.  If your project got off track (schedule, cost, or expectations), you could optimize the plan.  The project manager drew a triangle and labeled each point:

  • Time
  • Scope
  • Cost

“Pick two.”

It’s a triple constraint.

Of course, someone realized, you could Quickly deliver Big, Cheap Junk, so they taught their protégés to write in the middle of the triangle:

  • Quality

“Pick three.”

They still call it a triple constraint.

“Good enough” is better than perfect.

One day researchers and savvy marketers discovered that people don’t really know what they want until they see it, and people typically use only about 20% of new innovation anyway.

So why waste time building big, perfect things?  In fact, delivering a little bit that is “just right” might be appreciated even more by our customers.

After delivering a little bit, we have some budget left over to deliver the next little bit.  If we get it wrong, toss it.  We’ve got room to build the next thing with the money saved in this new approach.  Companies like Apple — that learned to deliver less than their competition, but deliver it extremely well — started to thrive, and then they picked up the pace.

Bonus:  Customers get their hands on our product or try out our service sooner.  We had a decent idea of what was most important, and delivered just that little bit, and quickly.  Now we’re making friends and influencing people, and getting good feedback on what’s next on the priority list.

Double Bonus:  We may be only a quarter through our roadmap and already getting 80% or 90% of the benefit.  Now we have 75% of our budget or timeline left.  We can proceed like we thought we would, or we can shift all that budget and people to focus on the Next Big Thing, that other big deal that wasn’t getting anything done yet.  Were we ready for that pleasant surprise?  Can our team turn on a dime?  Is anyone paying enough attention to recognize the opportunity?  Do our change management processes understand?

Double Bummer:  We’re not the only ones doing this.  Other teams and our competitors also embrace this new approach of delivering a little bit at a time, with quality embedded as we go.  So the problem doesn’t go away, it gets more sophisticated and susceptible to the process of how we and our teams do our work.

Getting things done right and getting the right things done.

In order to get the “right things done” quickly, agile frameworks use the iterative and incremental approach described in my prior Focus & Flexibility post.

If the first half of quality is based on understanding fitness for purpose — getting clarity from external feedback — the second half of quality is based on disciplines to heighten internal feedback .

In order to get “things done right”, many agile and DevOps practitioners add technical disciplines to the iterative process.  These disciplines provide feedback as quickly as possible, even before getting to done.

Immediate feedback in software development

In the software industry, several agile disciplines can be used for designed for quality and quick feedback:

Pair programming

The practice of Extreme Programming (XP) takes the feedback loop of code review to the extreme:  continuous review, in the form of pair programming.  Two software developers sit together, often sharing a single keyboard.  While immediate productivity takes a hit, the “two heads are better than one” principle leads to fewer bugs and better design.  Better quality code is easier to maintain.

Like a driver and navigator working together to make their way through an unfamiliar city, pair programming can get the solution to its destination more reliably.

Mob programming

The overgrown cousin of pair programming, mob programming gets the whole cubicle involved.  They may share a single computer with a big screen, or have multiple screens on a wall together.  The group can simultaneously work on programming, testing, and refining user stories.

Automated testing,  test driven development (TDD) and test-first

In order to validate the code, tests are created to run automatically each time the code is changed, to help make sure nothing breaks.  Test-driven development take it a step further by creating the automated tests before writing the code (or at a minimum, at the same time).  A test-first model codifies this process:

  1. Write the test.
  2. Run the test and watch it fail.
  3. Write the code.
  4. Run the test and watch it pass.

Continuous integration, continuous deployment and DevOps

When the feedback loop is truly continuous, especially when writing software that runs in cloud services, the line between developing a solution and operating a solution starts to blur.  The intentional blurring of that line creates a DevOps team.

To illustrate:  Amazon deploys new software to production every 11.6 seconds.

The result is transformational:  releasing software used to be (and many places still is) a big, scary operation.  Automating those testing and deployment processes transforms the traumatic into the trivial.

Skateboarding on the freeway

The triple constraint of old-school project management misses a major principle.

Trust = Speed

Would you ride a skateboard at 60 miles per hour on the freeway in rush hour?  Even with a helmet?  (I wouldn’t!)

How about last year’s model sedan with seat belts and airbags?  Even without a helmet?  (You’d probably speed up, because the speed limit is 65!)

What’s the difference?  Safety.  Confidence.

Seat belts and air bags

When it comes to delivering innovation:

Quality = Safety = Trust = Speed

Developers will deploy faster, businesses will upgrade more often, and customers will adopt more quickly when they trust the solution will work after each update.  The disciplines of agility (especially continuous feedback cycles) increase the confidence and speed of the entire team.  Upgrades can become non-events (except for “what new thing do we get now?”).

Together with interpersonal dimensions of teamwork and respect, agile disciplines are the seat belts and air bags that enable us to move quickly and confidently.

Quality and speed are not incompatible adversaries, they are necessary companions.

Leave a Reply

Your email address will not be published. Required fields are marked *