Scrum is an iterative incremental process of software development commonly used with agile software development. The name comes from a rugby term, which is short for scrummage (like American Football’s scrimmage), and is a way of restarting the game after the ball stops.
This concept transfers well to the scrum attitude, which, as Carl Youngblood once said, one could basically sum up as an acknowledgement that human beings can only focus on their goals in small steps and for short periods of time and need help from one another, ways of visualizing their progress, and constant reassessment to be successful.
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.
Following are some general practices of Scrum:
- Customers become a part of the development team. (i.e. the customer must be genuinely interested in the output.)
- Like all other forms of agile software processes, Scrum has frequent intermediate deliveries with working functionality. This enables the customer to get working software earlier and enables the project to change its requirements according to changing needs.
- Frequent risk and mitigation plans developed by the development team itself. – Risk Mitigation, Monitoring and Management (risk analysis) at every stage and with commitment.
- Transparency in planning and module development – Let everyone know who is accountable for what and by when.
- Frequent stakeholder meetings to monitor progress – Balanced (Delivery, Customer, Employee, Process) Dashboard updates – Stakeholders’ update – You have to have Advance Warning Mechanism, i.e. visibility to potential slippage / deviation ahead of time.
- No problems are swept under the carpet. No one is penalized for recognizing or describing any unforeseen problem.
- Workplaces and working hours must be energized. – “Working more hours” does not necessarily mean “producing more output.”
Several roles are defined in Scrum; these are divided into two groups; pigs and chickens, based on a joke about a pig and a chicken.
A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed but you’d only be involved.”
So the pigs are committed to building software regularly and frequently, while everyone else is a chicken: interested in the project but really irrelevant because if it fails they’re not a pig, that is they weren’t the ones that committed to doing it. The needs, desires, ideas and influences of the chicken roles are taken into account, but not in any way letting it affect or distort or get in the way of the actual Scrum project.
In scrum, a project begins by conducting a meeting in which the features of the application to be developed are determined. The resulting document is called product backlog which is a high-level document for the entire project. It contains broad descriptions of all required features, wish-list items, etc. It is the “What” that will be built. It is open and editable by anyone. It contains rough estimates, usually in days. This estimate helps the Product Owner to gauge the timeline and, to a limited extent, priority (e.g. if “add spellcheck” feature is estimated at 3 days vs 3 months, that may affect the Product Owner’s desire).
The sprint backlog is a greatly detailed document containing information about how the team is going to implement the requirements for the upcoming sprint. Tasks are broken down into hours with no task being more than 16 hours. If a task is greater than 16 hours, it should be broken down further. Tasks on the sprint backlog are never assigned, rather tasks are signed-up for by the team members as they like.
Each day during the sprint, a project status meeting occurs. This is called “the standup meeting”. The scrum has specific guidelines:
- The meeting starts precisely on time. Often there are team-decided punishments for tardiness (e.g. money, push-ups, hanging a rubber chicken around your neck)
- All are welcome, but only “pigs” may speak
- The meeting is timeboxed at 15 minutes regardless of the team’s size.
- All attendees should stand (it helps to keep meeting short)
- The meeting should happen at the same location and same time every day
During the meeting, each team member answers three questions:
- What have you done since yesterday?
- What are you planning to do by today?
- Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to remember these impediments.)
At the end of a sprint cycle (every 15-30 days) a sprint retrospective is held, at which all team members reflect about the past sprint. The purpose of the retrospective is to make continuous process improvement. This meeting is timeboxed at four hours. Two main questions are asked in the sprint retrospective:[1]
- What went well during the sprint?
- What could be improved in the next sprint?
Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project.