Agility Software

Often, when working with a team new to Scrum and agile software development, I’m asked “How will we know when we’re agile?” At other times, managers will contact me, saying “We’re doing Scrum but we we’re not getting the benefits we expected.” By using the key principles of Scrum, I can quickly determine how “agile” a team is and more importantly, what areas could be improved to achieve more benefit of agile practices.

The Scrum.Org Scrum Guide (written by Ken Schwaber and Jeff Sutherland) identifies three key principles of Scrum:

1.       Transparency: Significant aspects of the process must be visible to those responsible for the outcome.

Are team members able to give honest assessment of the effort remaining? Are Sprint Reviews focusing on the real state of Product Backlog items? Basically, is the team seeking the reality of what’s happening or are cultural issues causing the team to “fudge” information to keep management (or others) at bay?

Team members consistently reported progress at the Daily Scrum meeting: “I started the 12-hour coding task yesterday and worked on that for 8 hours so there’s 4 hours left.” Discrete inquiry after the Daily Scrum revealed that management told the team, “the Sprint Burndown must look good, or else.” Apparently management wasn’t interested in reality, only in looking good to their superiors in the near-term.

2.       Inspection: Scrum users must frequently inspect Scrum artifacts and progress toward a goal to detect undesirable variances.

Is the team meeting every day for the Daily Scrum? Is the team holding a review at the end of every Sprint where completed work is presented to key stakeholders? In other words, is the team talking with each other and key stakeholders about progress?

The team couldn’t seem to complete many (if any) Product Backlog items by the end of the Sprint. Although the team was meeting every day, they talked about technical problems and potential solutions. They never understood where they were in their plan until the end of the Sprint when they were consistently surprised that very little was deliverable.

3.       Adaptation: If an inspector determines that one or more aspects of a process deviates outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted.

Are team members updating their plan in the Daily Scrum meeting to maximize the value they can deliver? Do they meet after every Sprint to review their process in a Sprint Retrospective to adjust the way they’re working together? In a nutshell, is the team adjusting to known issues they are discovering through transparency and inspection?

A manager told me the team had given up on retrospectives; “They were just gripe sessions. Nothing ever changed.” To get different results, you have to change the system and that requires action. Sometimes the hardest part of change is committing to make it happen!

To these three, I add a fourth key principle:

4.       Incremental Delivery: A Scrum team must develop potentially shippable software by the end of every iteration.

When team members complete an iteration, is there real, working software to show for it? Are all the steps required by their company and their customer completed so that there is no more work to do? In summary, are they delivering value with every iteration?

The team was bogged down with bugs. The customer continued to find serious problems with every delivery. When asked to describe their definition of “done,” individual team members had different concepts of what was required. Worse, it was clear that “shortcuts” were rampant. Just saying a feature is done isn’t enough; it must meet agreed upon expectations, too.

I teach the same approach to new Scrum Masters. When team members or management comes to me (as the Scrum Master) wanting to change an event, artifact, or role, I go back to these four principles. If the change doesn’t violate the principles, take it to the team! If the change fails the principles test, I try to turn it into a “Yes, and…” moment, suggesting how the change could be beneficial if we made some adjustments in alignment with Scrum principles.

To be sure, Agile is much more than Scrum. While continuous integration, test-driven development, incremental testing, etc. are important practices in the agile world, a team can be “agile” without these. If they’re truly agile, they will be in the process of adopting many of the common agile practices. If they’re hiding information or not measuring their progress or not changing plans and approaches to address known problems or not completing working software every 2 to 4 weeks, then they have work to do to be called agile.