SCRUM

Scrum is another “light weight” methodology that falls under the agile framework.  It’s foundation is based more on past experience rather than theory.  Scrum is a planning focused agile methodology with some unique characteristics and guidelines.[i]  One unique aspect are the three pillars of transparency, inspection and adaption.  These pillars are implemented in every project.  Another unique aspect to Scrum is the makeup of the team.  There are three major roles / parts which is the Product Owner, Development Team and Scrum Master.  With those team roles, Scrum also has processes that occur during each iteration.   The major parts are the product backlog, sprint backlog, sprint planning meetings, sprint, sprint review meeting and sprint retrospective.  All of these piece makeup the Scrum methodology.[ii]

                The implementation of Scrum’s three pillars, which are transparency, inspection and adaption, are key ingredients to a successful Scrum project.  Transparency ties Scrum closely with the agile requirement of close continuous communications with the customer.  Transparency requires that the development team and customer define the language that will be used throughout the project. [iii]   An example given in the Scrum Guide is that the customer and development team should have a mutual understanding of what “done” means.[iv]  With regards to inspection, it is important to continually review the deliverables called “Scrum artifacts” to ensure that there are no variances that are undesirable.[v]  This fits the agile requirement of “continuous excellence.”  The third pillar in Scrum is adaptation.  When a project becomes unacceptable because certain variances detected are outside the desirable limits, the development team must be able to adjust the process or the code that is being worked on.  This fits the overall purpose of agile which is to be able to quickly adapt to changing environment and changing circumstances.  In addition to the three pillars, Scrum also has a unique team structure.

                The Scrum team structure has three major parts, which are product owner, development team and Scrum Master.  One role that is important in Scrum is the product owner, who is characterized as the “voice of the business.”[vi]  The product owner is the firewall between the business and the development.   The development team should only be working on requirements set by the product owner.  No one else in the organization should be allowed to order anything from the development team.[vii]  This keeps the development team focused, and keeps them from being pulled into multiple directions.  This also keeps the requirements more manageable. 

Another crucial part of a Scrum team is the development team.   The development team is responsible for transforming the assigned business requirements into a functioning product.    They follow the agile framework that encourages “self-organizing teams” and the empowered individuals to make important decisions on their own.[viii] [ix]  Like other agile methodology they have shared ownership of their product.  They are also said to be “cross-functional,” and are not given individual titles within the development team. [x]

 The third piece of the Scrum team is the Scrum Master.  The Scrum Master is characterized as a “Servant-Leader,” by the Scrum Guide.[xi]  The Scrum Master ensures that the Scrum guidelines are being properly implemented by the team.  The Scrum Master helps people outside of the Scrum team understand the Scrum methodology and improves how the rest of the organization interacts with the Scrum team.  Furthermore, the Scrum Master helps the development team and product owner efficiently handle the management and implementation of the business requirements.  Another key responsibility that the Scrum Master must accomplish is they must “remove impediments to the team’s progress.”  Examples of this could be getting a critical purchase order approved to replace a dead laptop.[xii]  Furthermore, Scrum Masters facilitate all of the sprint meetings.

Image retrieved from the Sterling, C. (2009) Retrieved from http://www.gettingagile.com/2009/05/01/scrum-is-the-vehicle-not-the-destination/

Scrum methodology has several important activities that are conducted through the Scrum development cycle.  One of the beginning steps of Scrum, is the product backlog planning.  Product backlog is basically a list of prioritized features and business requirements determined by the customer and gathered and managed by the product owner. [xiii] Once a product backlog has been established, each item on the product backlog is gradually assigned to an iteration called a sprint.  They then create a separate list called a Sprint backlog, which consists of items from the product backlog selected to be included in the upcoming Sprint.   During a Sprint planning meeting, time estimations are made on each Sprint item.  Furthermore, a goal or goals are established during the sprint planning meeting.  Goals help teams focus, especially during the half way point when teams “start to get confused.” [xiv]  To have continuous monitoring of the status of the sprint, daily scrum meetings are held. Scrum meetings allow the development team to report their status and confirm the likely hood of reaching the Sprint’s goals.  Prior to closing out a sprint, it is recommended to conduct a demo of the features completed during the sprint.  Author of the book, Scrum and XP from the Trenches: How we do Scrum, Henrik Kniberg stated that demos can help development team’s acquire feedback from the customer.  Furthermore, if the demo goes well, it will boost the team’s reputation and increase their confidence, and if it goes bad, it provide them with the incentive of putting more effort in the next sprint to avoid the embarrassment next time.[xv]  After the demo, the sprint is almost ready to be closed.  However, before the sprint is to be closed, a sprint retrospective is recommended.  This activity is an example of how Scrum implements the agile manifesto’s principle of regularly reflecting on work performed and striving for to continually improve.  A sprint retrospective has the entire Scrum team meet, to reflect on the current sprint that is ready to be closed out and list out lessons learned. [xvi] [xvii]  Having explored the parts of Scrum, it also is important to explore how it has been implemented in the real world.

It is important to examine how Scrum has been adopted by the business community and individual development teams.  Mark Paulk provides some insight on how the Scrum methodology has been adopted by development teams and organizations in his paper, “A Scrum Adoption Survey.” Paulk surveyed “software professional” that consisted of members from Scrum Alliance, Project Management Institute and “high maturity organizations.”[xviii]  From the 205 responses, he was able gather data on multiple Scrum related topics.  Team Dynamics and structure is a key component of Scrum.  With regards to team size, Paulk found of those surveyed, that “7-9 members” was the most common size among Scrum teams.  Another result that was found was a majority of professionals that were surveyed said that their development team was co-located and also that they “work at a sustainable pace.”  With regards to roles, among those surveyed, the survey found variation among the specific roles within each professional’s Scrum team.   With regards to the Scrum Master role, most utilized only a Scrum Master and a little less utilize a project manager that act as a Scrum manager, but a much smaller percentage had both a project manager and a scrum master.   As for the product owners, survey respondents mostly said that the product owner had to prioritize based “on the agenda of multiple stakeholders.”  Less followed the Scrum guideline of empowering the product owner with being the “single point of control for prioritizing” the product backlog.  With regards to the sprint lengths, most of the surveyed professionals said they kept most sprint lengths limited to 2 weeks.  Paulk says this could be attributed to the Scrum training recommending to start new Scrum teams with 2 week sprints because two weeks is “short enough to provide rapid feedback, which promotes fast learning, and the length of the sprint can be adjusted as the team learns what works best.”  The survey shows that Scrum guidelines are not always fully followed, but for the most part teams adhere to most of the methodology’s framework.[xix]

With the values, team dynamics and processes of Scrum, it provide development teams a solid foundation on to which teams can implement agile with in there organization.  It is suggested to follow the guidelines closely when first implementing Scrum.  However, as seen by the survey, many companies have chosen to make adjustments and do what works for them.