Hans Samios' Personal Lean-Agile Knowledge Base

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== How Can We Introduce Scrum to Our (Customer or Field) Stakeholders? ======

> "Some people are not only are they interested in the sausage, but also the sausage making process."

While most people are not interested in the process we use to create value for them, some people are. For example, when you first have external stakeholders, whether someone external to your shop, or outside the company, you may need to explain the process we are using to them so they can be more engaged. 

Sometimes we need to tell our customers or field stakeholders (hence generic term "customer") about our development process. People have heard about Scrum. Here is some text that has been used to introduce customers to key concepts.

No matter how you present this information to the customer, it is recommended that you have a meeting with the customer to discuss the process and their understanding of it, and what our expectations are. While it is important we get the feedback from the customer, it also helps if the customer presents the feedback in a way which helps our Scrum Teams understand it and in such a way that it energizes the Scrum Team.

====== Scrum Methodology Overview ======

Scrum is a project management method for agile software development. The definitive book on the Scrum process is “Agile Software Development with Scrum” by Ken Schwaber. 

The main roles in Scrum are the Scrum Master who coaches the team through the processes and vigorously removes obstacles in the path of the team, the Product Owner who represents the stakeholders and the Development Team which includes the people with all of the skills necessary to produce potentially shippable software (including subject matter experts {SME’s}, development, certification and documentation). The Product Owner is the customer advocate and the owner of the prioritized set of high level requirements called the Product Backlog. The backlog is prioritized based on customer and business value. Each item in the backlog receives a cost factor relative to other items.

A key principle of Scrum is the recognition that during a project the customers can change their minds about what they want and need based on what they see (traditionally called "requirements churn" but in reality this represents learning we should take advantage of), that cannot be addressed successfully 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. The Scrum Team is self managing and once it has agreed the quantity of work with the Product Owner, it commits to delivering it. Progress toward the goal is tracked daily and the Product Owner is consulted if the Scrum Team feels it cannot achieve the goal based on the new information it has.

The Scrum process recommends approximately 30 day (or less, typically 14 days) software development iterations called Sprints. During each Sprint the Scrum Team creates an increment of potentially shippable software. The set of features that go into each Sprint come from the Product Backlog. The Scrum Team determines how much they can commit to complete during the next Sprint based on their prior Sprint velocity (how many points they have delivered per Sprint). The Scrum Team is usually co-located in a scrum room where they can easily work together and have the Daily Scrum meeting. Face-to-face communication and iteration are encouraged over formal requirement and design documentation and approval. During the Sprint no one is allowed to change the backlog, which means that the requirements are frozen for Sprint. The Scrum Team is isolated from changes to their scope during the Sprint, so changes are handled and even encouraged as part of the planning for the next Sprint.

At the end of each Sprint there is a Sprint Review where the team demonstrates what they have produced to the customer. The customer is often invited to participate in these demonstrations. The purpose of the Sprint Reiview is to gather up feedback on what was developed in the sprint. This feedback is incorporated into the Product Backlog by the Product Owner. After the Sprint Review, there is a Sprint Retrospective meeting where the Scrum Team reflects on ways they could improve the process and specifically what they will do differently during the next Sprint. The next Sprint then starts, and the cycle repeats.

A key principle of Scrum is that each iteration produces tested and potentially shippable product increments. Each Scrum Team has a “definition of done” that includes testing and verification for the functionality they produce. In addition, all new functionality should have an automated test procedure (ATP) created that tests the component each time the software is built. After each Sprint, the software is demonstrated to the stakeholders (customers, management, etc) where they can provide feedback on what was produced.

For large projects, some Release Sprints will be required to test the integrated software prior to final commercial release. Customers may also institute their own acceptance tests of the commercial software they receive using their specific configuration.

====== Want to Know More? ======

As said, before a stakeholder engages in a Sprint Review, you should spend some time working with to introduce the basic concepts of Scrum and agile to them. See {{:introduction_to_scrum_for_stakeholders.pptx|"Introduction to Scrum for Stakeholders"}} for ideas on what to talk about. Note that in most cases this is as short as a 10-15 minute conversation and often does not require a formal presentation.

And if you want to send the people are more dynamic presentation of the basics of Scrum, you could do worse than to send the link to [[https://www.youtube.com/watch?v=9TycLR0TqFA|Scrum in 7 minutes]]. 

{{tag>Consultant Tools Team Stakeholder Roles SprintReview Review FAQ PresentationIdea}}