Scrum is considered by many to be the dominant Agile methodology today. All Agile methods got their name from the Agile Manifesto in early 2000’s. The inventors of Scrum, along with other Agile innovators, got together and wrote the agile manifesto. The Agile Manifesto has four principles that encompass methodologies considered Agile. Agile methods 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
Keep in mind Agile methods do advocate getting rid of the items listed on the right. It is just that Agile methods focus on the items on the left first.
[login]Of all current methodologies, the most recognizable in mainstream IT circles is Scrum. There are many reasons for this, which we will not delve into here. For those anxious about using Scrum, this is a guide to help your organization get started with Scrum. Below are methods that need to be implemented, and instructions on how to do that within an organization. Besides this guide, it is highly recommended that you obtain some or all of the recommended books in the Resources section.
Upper Management Buy-In
Methodologies like Scrum can be implemented in a Skunk Works way. Start with one small group and then hope that this successful implementation spurs other groups to mimic their success. Unfortunately this method can lead to a slow death, if for some reason there is no upper management buy-in later on. When it is politically expedient to not use Scrum, because of management hostility to the method, you have a problem.
To avoid this, prepare a presentation for your upper management to convince them you need their support to make this change. In this presentation, make the case for why your organization needs to change. Below are some points to include in such a presentation:
- Current methods have our team delivering software with features that are not necessary. We have wasted money to create features our customers do not use.
Our business owners expected to have certain features available when projects are delivered. Scrum methods help eliminate confusion about what is delivered, between the business owner and IT.
Changing features in the middle of the project is difficult. Scrum allows business owners to change features quickly from one “sprint” to the next, allowing business to quickly adapt to changing customer requirements.
Currently, business owners do not see how much work goes into our projects. Scrum provides a framework to give visibility into what the costs are (resource and money) for the project.
Determining Product Owner and Scrum Master
Now that you have upper management buy-in, you need to decide who your Product Owner and Scrum Master are. Project Managers who are the current PM’s for your projects make the most obvious resources for Scrum Masters. A key quality for the Scrum Master is the ability to serve the team!
Instead of usual Project Manager Duties, the Scrum Master needs to do what he can to make sure the Team (including the Product Owner) succeeds. The Scrum Master’s role does not include a lot of Gantt Chart project plans, months out into the future. There are metrics to use, and a lot is displayed to team members and management. But these are metrics that can tell management early how the project is progressing. This kind of quick feedback is how Scrum teams can make adjustments early before a deadline when their project runs into problems.
The Product Owner should be someone from business who can put time into the project, directing the team to business value. The Product Owner will discuss what is needed with different business area stakeholders, and pass those findings on to the team.
Product Backlog Grooming
Scrum practices recommend that there is regular and consistent backlog. This also assumes that this backlog is regularly groomed to prioritize, add and get rid of stories or tasks. Scrum assumes that the product backlog is prioritized by someone in a Product Owner role. This can be done along with a Scrum Product Owner, who is the voice of the product owner in the scrum team.
The Product Owner should be someone from the business side, willing to invest time in the project. They will direct the project’s features, and answer questions about features for the team. The Product Owner is responsible for making sure the team is working on items that are valuable for business.
Create The Backlog
To create your backlog, work with the Product Owner. Working with some members of the team, take your list of items to be worked on and begin prioritizing them. This article assumes the list items are in a story format. Stories are a recommended method for breaking down a project into manageable parts.
To prioritize, it is recommended that the Product Owner assign some type of business value to each story. A simple way to start would be by assigning a 1, 2 or 3 to the story. 1 being a have to have, 2 being a nice to have if there is time and 3 being a we will look at this for our next release.
Also, some Product Owners may want to know what the “cost” of feature will be during development. So that you can let that Product Owner know the cost, the entire team should try to perform some kind of estimation. Planning Poker is one of the most effective ways to estimate. Using Wisdom of the Crowds, and looking at levels of effort, the team can give the Product Owner an idea of what one story costs in terms of time and effort.
Groom The Backlog
Once the backlog is prioritized, begin the grooming process. Grooming means that the Product Owner, Scrum Master, and perhaps with a Business Analyst or a team lead, determines the fate of stories. Stories that are in a low or unnecessary priority should be tossed.
New stories need to be taken to the team for more estimation. The team can give a quick level of effort estimation for these stories. Also, during these grooming sessions, the Product Owner can select a small subset of stories that could be in the next sprint. The other way to do this is to wait until the planning meeting and let the Product Owner select stories then. This is tough when the Product Owner and team are not collocated.
Plan Your Sprint
Rich communication among team members is a cornerstone of all agile practices, and Scrum is no exception. The planning meeting is an event with rich communication that starts each Sprint off. The frequency of this depends on the team. Select 1-4 week sprints. To have your sprint over the 2 week threshold may indicate that there is an issue. Most software projects can handle 2 week or less sprints. The exceptions to this may include coordination with another team, not using sprints, or support from another group only allows longer sprints.
During this planning meeting the Product Owner works with the team to select the stories to complete in the next sprint. As mentioned earlier, the Product Owner could come to the meeting with a preselected sub set of stories to select. The team communicates the level of effort they can commit to for that sprint. The Product Owner then selects the stories to be worked on for that sprint that total the level of effort indicated.
Here is a simple example. The Product Owner comes to planning meeting having a selection of stories that total 10 points. The Product Owner knows that last sprint the team completed 8 points of work. She is hopeful that the team may commit to more points, since they are bringing on a new team member.
In the planning meeting, the team is asked to commit to a number of points to complete for the sprint. The team states that they have discussed this, and can complete 7 points for the sprint. The Product Owner asks why the low commitment when they just completed a sprint with 8 points and are adding more resources? The team explains that the new resources will take some education time this sprint, learning how the team is implementing a new technology. Also, they explain, 2 members of the team have 2 days off this sprint. When they look at the actual amount of time to work this sprint it turns out to be less than last sprint, hence the 7 points.
The above example shows the type of negotiation and explanations that should take place when your team is planning. There is a lot of communication that goes on in Scrums, and the planning meeting starts this off.Daily Scrum (Daily Standup)
The next rich communication experience is the daily standup. This meeting involves all team members. Stakeholders are welcome to attend, but the meeting is for sharing of information among team members.
The Scrum Master should set up the daily standup with all team members, and invite any other stakeholder to listen in. The daily standup lasts no longer than 15 minutes. In the daily standup, each team member reports on the following:
- * What I worked on yesterday
* What I will work on today
* Any issues that are blocking me
Any other discussion can take place after the daily standup. But during the daily standup discussions of technical issues, clarifications of stories should not be allowed. This is to keep the meeting short. If those clarifications are needed, the participants will ask the involved parties to hang around after the standup to discuss these issues.
Retrospectives
The retrospective allows all team members to discuss the process. These meetings occur when the sprint is over, usually the day before the planning meeting. The retrospective allows the team to look at their sprint from a distance. The team explores what went well, and what did not go well.
It may make sense to demo the completed software before the retrospective. This allows the team to show to business owners what they could currently release if they wanted. It also reminds the members what they worked on earlier in the sprint.
The Scrum Master needs to set up a demo meeting where all are invited. It is highly recommended that invitations are sent to all affected business areas, as well as the Product Owner and the Team members, who will present. Make the demo a good time, with the team showing off what they have accomplished this sprint.
After the demo, send out an invitation to all team members, including the Product Owner, for the Retrospective. Now the team can adjust for the next sprint, keeping what worked, and what did not work. To conduct the Retrospective, the Scrum Master should ask each team member, what worked and what did not work.
An effective way of doing this can be to ask for 3 things that worked and 3 things that did not work in the current sprint. Write those down on a white board. At the end of the Retrospective, assign action items to help improve what did not work. The team is ready for the next Sprint!
Resources
You can use the above steps to start using Scrum. The best way to start Scrum would be to get a good Agile Coach in to help start your new process. Below are some recommended readings. Using the people from these resources would be a good place to start looking for an Agile Coach if you are so inclined.
Whether you do or do not get a coach, get some of all of the recommended books shown below.
Succeeding with Agile: Software Development Using Scrum By Mike Cohn
