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

In our last post 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  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. 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 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 It 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 and notes on the Wiki?
• I need to know, did you meet our done-ness criteria before I sign off on this story? Anything you wish you might have done, but didn’t?
• Were there any refactoring opportunities as part of this story? What would that have 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 and Engage Your Testers!

There’s a partner on our teams that we often forget.. 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 we’re 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 they 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 maybe we can get Good and 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. 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) have towards good to offset our historical bias towards fast. It’s the recognition of our DNA and the power of asking the right questions of key stakeholders that can lead us towards effectively balancing across four dimensions.

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