How to release more often, have great customer focus, and great quality

Posted on March 20, 2014 by kristianjaeger

Introduction

Something that I hear in software development circles is that folks want more frequent releases, they want more customer focus, more opportunities for innovation, and excellent quality. However, sometimes they do not know where to start to achieve what may at first seem like daunting goals.

Long software release cycles, feature sets that match a specification but might not match customer expectations, and lack of perceived innovation can be significant problems in software development.

—————————————————————————————————

The Methodology

Some software methodologies have certain preconceptions associated with them and can sometimes be discounted immediately without really taking a hard look at the details of what they are.

I have had the pleasure of working on a few teams here at Microsoft that use this sometimes misunderstood methodology.  I have both been a leader and participant in the process.

This methodology is called Scrum and is valuable for those in several different engineering disciplines and to their leadership as well.

—————————————————————————————————

How does it work at a high level?

Outline of process:

  • Create a backlog of scenarios and associated features for the product.  This backlog can be updated, or added to, at any time and can be reviewed periodically.  There are various tools such as Team Foundation Server (TFS) that can be used for this purpose.
  • Assemble a backlog of scenarios and features to be completed in a relatively short milestone (two to four weeks). Design, coding, testing, and bug fixing all occur during the milestone.
    • A planning meeting prior to the start of the milestone can be used to discuss this and give relative costing to the work items.
    • Each workday have a short meeting, fifteen minutes at maximum, to discuss progress from the previous day, what will be worked on, and any blocking issues.  If the meeting is reserved for these topics only it will stay on point and short.
      • There can also be similar meetings to coordinate larger cross-team projects.
      • At the end of the milestone there should be potentially shippable results, or one should be able to demo the progress.
        • Additionally, there can be opportunities to do an early release to a limited group of customers via alphas or betas.

—————————————————————————————————

Science behind Scrum

Scientific studies have confirmed several benefits of this approach.  You might be surprised to find that one of the studies was regarding three different teams at Microsoft!

These teams used various practices along with Scrum to achieve their goals: regular short meetings, planning poker, continuous integrations, test-driven development (unit tests), done criteria, source control, code coverage, peer review, static analysis, and XML documentation.

What did these teams learn from transitioning to this methodology?  They found that initially their productivity decreased slightly while they were learning the process.  However, by their fourth short milestone they observed a significant increase in productivity without an increase in defects!  They also had better quality with regard to defect density compared other teams not using the methodology,  including data benchmarked across forty projects from nine companies!  “These results indicate that [the methodology] combined with sound engineering practices have the potential to yield a higher quality product.” (Scrum and Engineering Practices:  Experiences of Three Microsoft Teams)

—————————————————————————————————

Key Concepts

“Scrum is an iterative and incremental Agile software development framework for managing software projects and product or application development. Its focus is on ‘a flexible, holistic product development strategy where a development team works as a unit to reach a common goal’ as opposed to a ‘traditional, sequential approach’. Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication among all team members and disciplines in the project.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.” (http://en.wikipedia.org/wiki/Scrum_(software_development))

The statement below is a high level glance at the philosophy behind the methodology.  It is the agile manifesto.

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.” (http://agilemanifesto.org/)

So, in other words, the objective is to use the Scrum methodology to achieve an organization’s goals, not to follow a process for its own sake.

—————————————————————————————————

Other Helpful Items

Scrum can be even more effective when used in tandem with other helpful tools and methods.  Some of these are: user research, A/B testing, testing in production, telemetry, business intelligence data, etc…  For example, on my Xbox SmartGlass client platform team the development and test teams work very closely together.  We leverage unit tests, continuous integration, and a focus on the end-to-end experience, amongst other items during development to keep quality high.  Using these tools we can quickly catch regressions and other issues.  In our case, we work in an open workspace that easily facilitates communication between developers and testers.  However, there are other teams that still successfully use Scrum without this workspace layout.

—————————————————————————————————

Training and Implementation

To be successful using Scrum it is very important to get good quality training.  There are many resources available and even certifications, as well.

Teams should give the new process time.  It is common for teams to question or have doubts for the first few milestones or sprints.  For some big teams or organizations it may take longer, as much as twelve to eighteen months in some cases, for them to get into a good rhythm with the new methodology.

By tracking the relative costing of work items and how much work is completed per milestone it leads to a predictability of what could potentially be accomplished in the future.

Another key factor to consider is to get approval and agreement from the entire team, including upper management.  This is so each person not only agrees with the approach but also has a sense of ownership too.

—————————————————————————————————

Tailoring the Process to Fit Your Team

Teams can tailor Scrum to fit the way that works best for them.  After having the context and knowledge from training and experience it can be easily changed to meet the team’s needs and desires.  For example, if a team prefers a detailed process with several reports (burn-down graphs, etc…) then they can do that.  However, if they prefer a very lean process with more focus on team members talking in person to resolve priorities and issues (this can work well for small teams) then they can implement that.

—————————————————————————————————

Improving Customer Focus

Improving customer focus is a key benefit of using Scrum.  Demonstrations at the end of a milestone is a good way to show progress and gather feedback.  For example, during Xbox One development my Xbox SmartGlass team would do demos to show progress and gather feedback from others in the larger Xbox organization.

For features that are ready to ship or to be adopted early there are other options for gathering feedback.  Pre-releases such as Alphas and Betas can be used to get feedback.  Also, regular releases to customers can be useful.  One example was for the Xbox One release. We leveraged Beta feedback to address issues and improve Xbox SmartGlass prior to the holiday release.  Also, for the third party developers that we work with we did regular monthly releases to meet their needs and gather feedback.

In addition, Scrum provides the flexibility to add work items, or stories, that were not planned and prioritize them before other work items.  An example of this was that we quickly developed and tested features and a demo for the E3 conference in 2012 related to work on the Xbox 360.  We had already planned other work for the milestones in question but were able to be flexible and re-prioritize.

Another advantage of this approach is that teams do not have to follow a predefined schedule for releases.  Products can ship when they are ready and not at a prearranged date, if so desired.  After seeing the results of the team’s labor they come to know how much work can be completed each milestone, and can predict better when releases can occur.  So, essentially a team could ship anytime that they and the customer deem is appropriate.

I have worked on a few teams that have used Scrum, and a few that have claimed to use it.

I would like to emphasize the importance of training for Scrum.  The teams who have had the most success with it were the ones that had training and had ownership in the process.

Examples of teams where Scrum worked well were: Microsoft SharedView, Xbox.com, and currently Xbox SmartGlass.  Sometimes it takes time for members of the team to adjust to the new process and that is okay, and likely should be expected.  However, the process leads to better productivity, more predictability, better quality in terms of the customer-facing results, and better transparency of what is happening on the team through planning and daily standup meetings.  It also lends to a better sense of identity for the team as well.

Conversely, the teams that had mixed results were teams that claimed to use it but did not really follow the process.  In other words, they would say that they were using Scrum but still clung to some old ways of planning, developing, testing, releasing, etc…

—————————————————————————————————

Conclusion

In summary, Scrum is an effective methodology that enables shorter software release cycles, more opportunities for gathering and responding to customer feedback, more avenues for innovation, and meanwhile keeping excellent quality.  It is even better when used with additional tools and processes, like those mentioned above.

—————————————————————————————————

Additional Resources

More case studies:

Scrum books

Filed under: Agile | Tagged: , , , |

« »

One Response

Leave a comment