Sheila's Blog

Scrum is an iterative and incremental software development framework.  It’s better described as a set of best practices or guidelines, rather than a detailed step-by-step software development process.  The main focus is to increase communication and help teams to empower themselves, so that they can resolve any issues that are preventing them from working to the best of their ability.  Engineering practices like XP work well within Scrum.  Scrum manages the product development side of things and XP can be used to help improve quality and productivity.

There are two types of roles defined in Scrum.  Pigs are committed to the project – they are members of the Scrum Team.  Within a Scrum Team you have the Scrum Master who ensures that the process is being followed and performs administrative functions.  The Product Owner represents the project stakeholders.  And the remainder of the team is a cross-functional group of people that are needed to work on the project.  Any other roles are chicken roles.  These people are not part of the process and are not committed to delivering the product, but they provide input.  Chicken roles include stakeholders (customers and vendors), end users, and managers.

Each time-boxed iteration is known as a Sprint.  This is usually 1-4 weeks long.  The less confident a team is, the shorter the iterations should be.  At the end of each sprint the team is expected to deliver a potentially shippable piece of software.  The team takes sets of requirements for each sprint from the top of a prioritised list of requirements called the Product Backlog that is maintained by the Product Owner.

To start using the scrum process you first need to define a Product Vision describing the goal of the project.  You then need to generate a Product Backlog to start working from and assign complexity estimates for each item (this may require a Team Estimation Meeting).  There are a number of meetings that are held during each sprint.  In the Sprint Planning Meeting the team discusses requirements in the product backlog, getting as much information as they need from the Product Owner.  The team then selects the requirements (called stories) they think they can commit to delivering at the end of the iteration.  The team breaks down each story into tasks and begins to assign them.  The stories and tasks for the Sprint are put into a Sprint Backlog.

Every day of the Sprint the team has a Daily Scrum Meeting to synch up, update the Sprint Backlog and make sure everyone knows how the work is progressing.  On the last day of the sprint a Sprint Review Meeting is held to demonstrate only completed stories to the Product Owner who will give feedback.  Directly after the Review meeting the team holds a Sprint Retrospective to discuss how the process can be improved.  The Sprint has now ended.  The Product Owner should make sure that the Product Backlog has been updated and reprioritised before a new sprint begins.  A Team Estimation Meeting may be required to do this.

Scrum builds cross-functional, self-organised teams that communicate as much as possible.  Teams are small with 4-9 members.  It allows for clients to make changes to the requirements and reprioritise them – but only between sprints.  The work selected for each sprint is frozen and can only be changed by the team in consultation with the Product Owner.  Visibility is high throughout the process and there are no penalties for identifying a problem. To successfully implement Scrum within an organisation, both management and team members need to buy into the idea.  It’s also vitally important to find a Scrum Master that will do a good job in coaching the team to reach their full potential.  This is a difficult job to do, as often the person who enforces change is not popular.  Someone who is a poor team lead, is not going to be a good Scrum Master.

When working well, the Scrum process is a nice one to use.  It keeps all the team members heavily involved in the project’s success and engaged in constantly making improvements.  However it can also be a difficult process to bring into a company as it doesn’t solve problems that already exist in a company – it only helps identify the issues.  Ultimately it’s up to the team to find a way to resolve any issues rather than changing the process to accommodate them.  So if input into the scrum is poor (bad requirements, individuals unwilling to work as a team), then the output will also be poor.

“I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.”  Ken Schwaber

That’s the theory behind scrum. In practise, it’s not quite as easy as it may sound. Over the next few months I’ll be trying out some more practical approaches to bringing scrum into an organisation.  It seems that every organisation has its own unique approach to using scrum – what works well for one team doesn’t necessarily translate to another.  It’s interesting to see how other teams tackle particular problems and evaluate whether some of those tactics can be employed or altered to work well within your own team.

Tags:   scrumNo Comments