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 & 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 is 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 5 years, what’s another 3 months?

Unbeknownst to Max, he was influencing the behavior of his team in a very negative way. Instead of them 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.

Next we’ll explore some ideas on how Product Owners can improve their balance in this messaging dance towards...

Good or Fast?

Earlier we explored an example of how subtle messaging around fast over good, can back-fire within teams in the long run. Now let’s look at alternative messaging with a focus on quality.

Be Careful In Your Messaging!

And you need to be real in your messaging. Teams’ can smell it if you’re not being truthful or don’t believe in what you are saying.

In this trade-off you also need to be patient and consistent. Conventional software teams have been trading off quality for so long that they don’t necessarily see that they’re doing it. Or if they are just beginning to tenuously focus on quality, one pressured comment in the wrong direction can quickly derail any gains they have made.

In my team example above, in order to turn-around our focus, I interrupted the Scrum Planning session and reminded the team that their prime directive was to deliver as much, high quality software, as they could within each sprint—working as a tightly coupled, creative, and self-directed team. That quality was the paramount factor in every user story. That we wanted, no demanded, that they finish each story to the point of no remaining rework. To use a common agile expression, so that it was done-done-done!

This coaching reminder changed everything and they adjusted their sprint contents and goal accordingly—pushing off nearly 30% of the stories that they’d previously ‘committed’ to.

I found myself, from that point forward, consistently reminding my teams of this commitment to quality as inherent to agile project success. I would also take time to explain that quality doesn’t necessarily result in work taking longer. Since their DNA was so wrapped in making the wrong trade-offs, after years of the wrong pressure, I found that for every ten conversations I had on our Scrum delivery focus—nine focused on quality and one focused on content delivery timing or speed. When consistently taking this approach, I found that teams would begin to internalize the messaging and start behaving in a more balanced fashion.

Asking the “Right” Questions

To this day, I think this 9:1 ratio is right for most teams transitioning from traditional to agile methods. Instead of Product Owners or Project Managers or Leadership focusing so strenuously on Schedule or Cost or Scope, they should be focusing on Quality. Questions about quality should be asked daily.

Instead of these questions:

Are we on schedule? Are you done yet, are we done yet, are they done yet?
What’s your velocity? Can we increase it by 50% this sprint? Why can’t you deliver twice as many templates as estimated?
We’re behind schedule, what is everyone doing to make it up? Working this weekend I hope!
Are we working overtime to recover the schedule? Why can’t we make the time up in testing?
What, you want to do some cleanup of hacked code—what will that do to the schedule? Can’t we just wait?
Is that work on the Product Backlog? If not, we can’t do it. Or another variation…Is that on the Roadmap…etc.
We are committed to this date and delivering specific content…period! Aren’t you?
We don’t have time for architecture or backlog grooming in this sprint…we need to simply Get R Done!

Ask these questions:

Have we reserved time to plan for testing? We’re going to vet that plan across the team…right?
Did you vet that feature with the customer? Is it what they were looking for? Oh, they want changes, more than we planned for. Well don’t let that influence our doing it ‘right’!
Did you deliver complete unit tests with the solution? Did they all pass? I’m glad. Now we just need to maintain them in future sprints so we have an effective “safety net”.
Did the team sit down during the design of the component and review / collaborate on it? Did we post those design decisions & notes on the wiki?
Did you meet our done-ness criteria…before I sign off on this story? Anything you wish you would have done, but didn’t?
Were there any refactoring opportunities as part of this story? What would that cost us in time?
Did you test it thoroughly? Did you document your tests in some fashion – acceptance tests, test cases, etc.?
Did we do a code review? Did we make all of the noted adjustments? Did we re-review the code if appropriate?
Are we moving too quickly or chaotically? Do we need to slow down a bit and re-focus on our quality and craftsmanship?

Do you see the difference? How hard would it be for you to reframe your typical project or team inquiries in this fashion? What impact would it have on your teams?

Remember—Trust & Engage Your Testers!

There’s a partner that we often forget in our teams. It’s the testers! Why do we traditionally discount them so quickly? I think a part of it has to do with the balance we’re discussing here. When were balancing towards speed, we don’t want to hear anything that might potentially slow us down. And testers, whether you know it or not, are all about slowing the train!

They find bugs. They constantly talk about up-front quality and baking it into the project rather than testing it in. They want to test thoroughly and document the results. They, gulp, want to get things right the first time.

So, if you are emphasizing quality within your teams, guess who becomes a wonderful partner in your efforts? Gulp again, your testers!

Instead of trying to marginalize or ignore their feedback, which I see far too often, encourage and demand their feedback. Realize that they want to get the project done as quickly as you do. They just want it to be done well. Ask them for strategies to holistically deliver a solid product. Speak to them about historical trends and what risks they perceive will uncover in your current project.

Above all, don’t short-shrift their time needs. Give them the time to do a solid job and setup your project culture so that their feedback is listened to and applied.

We Can’t Have It All…

But Perhaps We Can Get—Good & Fast Enough!

I’m of the mind today in my agile teams that I can get good software and I can get it sufficiently fast or fast enough. Teams certainly ‘get’ the fast part of that equation—especially since our traditional approaches to software have beaten it into their conscious and subconscious so well over time.

The point is—I think we need to by default slow things down a bit. Yes, I just said that. But slowing down doesn’t necessarily imply non-competitiveness or becoming truly slow. It simply means that we’re balancing across good and fast and delivering things that are Good and Fast Enough. And fast enough implies a thoughtful balance between Cost, Time/Schedule and most importantly, Scope. One that accepts ongoing adjustments based on incremental progress towards a clear goal.

We also need to emphasize the commitment we (the business) has towards good to offset our historical bias towards fast. It’s the recognition of our DNA and the power of asking the right questions from key stakeholders that can lead to us towards effectively balancing across four dimensions. Is that too much to ask?

Having a nice meal and getting it quickly enough? Patty my waitress doesn’t think so any longer and perhaps neither should you…

Thanks for listening,

Bob.

The Agile Project Manager--How do you want your Software, Good or Fast?