How Do You Want Your Software; Good or Fast? Part 1.

Picture this.

You are in a software diner one evening after a long day at work. A tired and disheveled waitress walks up to you to take your order; gum smacking as she goes over the daily specials. Nothing really sounds good to you, but you are extremely hungry and short on time. She summarizes the possibilities for you to help with your decision-making. Honey she says,

You can get mediocre to terrible food fast or slow food that tastes good. But you can’t have both—good and fast food.

It seems as if we’re always given certain choices in our software delivery challenges similar to what our waitress has given us. We have all heard of the “iron triangle” of Project Management—defining Scope, Cost, and Time as the three critical dimensions for a project. Usually Quality is placed within the triangle as a fourth variable, totally at the mercy of the other three.

What’s that old Project Manager joke?

You can hold any two of the dimensions fixed, but not all three of them. But isn’t that exactly what most traditional projects try to do; hold all three constant? What inevitably varies in these is quality, but rarely in a transparent and decisive way. It’s usually compromised slowly and disastrously behind the scenes, one method or component at a time that isn’t thoroughly designed or tested or documented. These trade-offs always, and I mean always, come back to haunt the team, project, and organization with re-work.

Badly Influencing a Scrum Team

I was attending a Sprint Planning session for one of my Scrum teams. I was the director of engineering and agile coach for a small internet eCommerce company at the time and I liked to hang out as a “chicken” in our various teams planning sessions to see how we were doing.

We had relatively mature Scrum teams, so our Sprint Planning sort of went by the book. The product owner would present each user story to the team. The team would ask a final round of questions to familiarize themselves with the story, and they might re-estimate it after additional discussion.

Then they’d plan the tasks for that story and align it into the workflow for the Sprint. Usually individuals would sign-up for those tasks and realign them based on dependencies and any sequencing required. This exercise would be repeated for all stories until the teams’ capacity was full. Then they would commit to the Sprint goal and set of stories as a body of work to be done.

In this session I noticed that the Product Owner was very subtlety influencing the team. Let’s call him Max. Max was well respected by his team and he’d established a natural rapport with them. He was also very personable and well liked. During the session he would talk about the business need for more content in this specific sprint. How desperate the customers were for more-more-more. How important it was to the health of our business. He would always preface team clarifying questions with this level of concern or fear over how much the team might be committing to. What I observed in the team in response to this surprised me!

They bought into it!

Often team members changed their time estimates based on his influence. They would all buy into shortening them. Of course there was always optimistic discussion surrounding the compromise, such as:

• Oh we simply overestimated this story in our grooming session; it appears much easier now…or
• Oh, Sally is a domain expert here, she can get it done in about one third the time and with less documentation…or
• Oh, there isn’t as much testing as you might think. Trust us, we’ll simply test it with unit tests and a little regression…or
• Oh, we don’t need to do any design for it, even though it is the most complex part of the system…or
• Oh, we can refactor the ugly code in that component at a later time. Don’t worry, it’s been there for five years, what’s another three months?

Unbeknownst to Max, he was influencing the behavior of his team in a very negative way. Instead of their being realistic in their estimates and holding to their quality goals, they were subtly succumbing to the perceived needs of the business. Without threats or shouting or coercion, but simply based on his relationship with the team and their desire to ‘succeed’, Max wielded great influence.

I clearly saw how the team was shortening their scope on craftsmanship and quality as part of their assessment and planning for each story. Multiply this by the number of stories that landed in the sprint and the inevitable pressure to deliver, and they created a recipe for low quality, high rework and eventual low customer satisfaction. But nobody realized it. They kept thinking they were doing what was in the best interest of the business and were pleasing Max.

The Quality Focused Product Owner and Project Manager

Now I posit that this sort of influence and behavior is nearly universal in software teams. In traditional teams it’s much more open and direct. Max gave us a good example of how it subtly plays out in agile teams.

Whether you’re in an agile methodology or not, you have the notion of a Product Owner. Call them a business liaison or stakeholder. Call them a Business Analyst. Call them a Project Manager. Whatever you call them, they are the living embodiment of business need facing your teams. They serve as a messenger of need and the teams listen carefully to what they say, both their verbal and non-verbal clues and communications!

I think these liaisons can get too caught up in the pressures of business and project delivery and apply the wrong pressure to their teams. Much as Max did in the above story. They think by equally pressuring on cost, scope, and schedule that they’ll deliver what the business needs. But the quality trade-offs this inevitably creates, undermines the very things they’re hoping to create.

Instead, they should be ranting and raving about holding quality constant, realizing that their teams already understand the need for speed. Constantly emphasizing that scope is the variation target for the effort. That priority of scope, delivering the most valuable components and features first, is what is most important, with each of these receiving the right amount of quality polish that is demanded, no required, by the customer.

In my next post I’ll wrap this up with some ideas on how Product Owners can improve their balance in this messaging dance…

Don’t forget to leave your comments below