RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Getting Started With Scrum Development

Of all current software development methodologies, the most recognizable in mainstream IT circles is Scrum.

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.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date