A crash course on Scrum part 1 - an agile project management methodology

Companies and organizations have never felt the need to innovate and adapt quickly to changes in market conditions like they face today. This requirement boils down to each individual team in your organization. Thankfully methodologies like agile help us with a framework to accomplish that. Scrum is one such methodology that has gained traction in the last few years. Scrum is simple and sticks with you once you start following it for a few cycles. However there are a lot of terms involved which might feel foreign, especially if you are only familiar with the water flow model of project management. Hence, in this brief two part article series, I aim to get you up to speed with the tools, terms and metrics involved in scrum. In a follow up article, I plan to blog about some of my experiences and software tools that I use.

Misconceptions

What scrum is not? - not just a software development process. It is independent of industry, in fact it can be applied even in your household.

Scrum is not all about the stand-up meetings - although that is sometimes trademark of teams that follow scrum. The stand up meetings is a means to improve communication and camaraderie through regular in-person or video conference meetings.

What is scrum?

It's a framework for teams that want to be self-organizing, agile and adapt quickly to changing requirements and deliver in short manageable time line. It is surprising to observe even how considerably large projects can be broken down into smaller pieces and delivered in half or quarter of the projected time and expense by adopting scrum methodology.

History of scrum

Founded on empirical process control theory or empiricism, scrum believes knowledge comes from experience and emphasizes on making decisions based on what is known. Scrum employs iterative, incremental approach to improve predictability and control risk. There are 3 important principles of empirical process control theory:

•  Transparency - a common metric to measure progress and a shared definition of done
• Inspection - regular and frequent inspection of progress is required. But inspection should never get in the way of work or stop or modify the project.
• Adaptation - if inspection leads to a discovery of something in deviation then an adjustment should be made at the earliest.

Core tenets of scrum

Let us look at a few process management techniques that take a systems approach to understand where scrum fits in:

•  Lean - The goal of lean is simple: minimize the time between customer request and fulfillment by continually improving and reducing non-value adding work.
•  Agile - Uses business value as primary measure of progress. Reduces risk through continuous delivery
•  Scrum - a wrapper around agile and is a process to practice agile delivery / development. Scrum is industry and technology agnostic.

In this light, it is relevant to discuss about the key points of the Agile manifesto: An agile process values:

•  Individual and interactions over processes and tools. Teams are self-organizing and self-solving all the way. Teams are self-contained as they figure out what to do and also how to do.
•  Working product over detailed documentation explaining the eccentricities and caveats while using the product. Customers pay for value, which should be provided by the main product and not by a bunch of explanations about the product. Scrum lays emphasis on developing a 'definition of done' and arriving at a consensus with the customer / stakeholder.
•  Customer collaboration over contract negotiation. Most successful businesses attribute their success to one thing - listening and providing what the customer wants. This can be achieved only involving the customer / stakeholder not only in the beginning but also at regular intervals during the development life cycle.
•  Responding to change (agile) over following a process. In today's world with increased access to real-time information in all fronts, companies can continue to remain on top only by embracing change and adapting to it. This means, as your customers constantly adapt to change, so do you. By delivering working product in increments and but periodically collaborating with the customer, scrum helps you to be agile to these changes. As needs change, your development team can change trajectory without much losses or overheads. 

The scrum framework

Now, we are getting into the details of scrum. Let us visit some concepts about scrum that will help us better understand how to adopt it:

4 formal scrum events

Although scrum encourages daily stand-up meetings, it discourages longer more formal events. It recommends each team to organically figure out at what frequency they meet and for how long they discuss. Having said, below are four formal events that scrum teams practice:

•  sprint planning - a meeting where the entire team plans the work to be done during that sprint / iteration
•  daily scrum - a short daily meeting where the team members takes stock of work done the previous day
•  sprint review - a meeting toward the end of the sprint where the product delivered incrementally is visited and reviewed.
•  sprint retrospective - another meeting toward the end of the sprint with emphasis on interpersonal relationships and productivity where the team discusses their development methodology, impedances and figure what can be improved.

Roles in a scrum

Scrum believes in teams composed of multi-disciplinary and cross-functional team members such that all the talent and skills required to finish the product are self-contained within the team. As product complexities grow, inevitably each of your team members start becoming subject matter experts specializing in a narrow functional area. This introduces a unique risk in the form of single point failure. Thus scrum encourages developing a healthy mix of multi-disciplinary team members who are sufficiently acquainted in areas other than their own. Some managers call these as T members (since they gain skill sets both horizontally and also vertically). Thus whenever a shortage of resource or skill set arises, the existing team can expand and fulfill the gap without immediately becoming brittle. In this light, each of the team member fit into one of the following roles:

A team consists of 

• product owner
• development team
• scrum master

Scrum teams are self organizing - they decide how to work on things without external direction, cross functional - have all competencies to finish the project without relying on other teams.

Product Owner (PO) manages product backlog (more on this later) - furnishing with details, prioritizing it, exposing it to all team members. Only the PO has the right to change the backlog and the entire organization must respect this decision. The development team works from this backlog and no one can inject a different set of requirements bypassing the PO. Below are some of the responsibilities that come with this role:

• Manage profitability and ROI (return on investment). A PO does this by prioritizing the backlog to maximize the business value delivered. To start with, the PO must arrive at a way to determine the value delivered, a metric of sorts
• Call for releases. PO decides what constitutes a minimum shippable product. PO also has liberty to move the release time line forward or backward to maximize the ROI.
• Guides product development. PO would establish, nurture and communicate the vision. Knows what to build and in what sequence (note, how to build is not a requirement for a PO. The development team figures this out).

Development team: This amazing team is self organizing, not even the scrum master tells how to turn the backlog into products. Scrum calls everyone a developer no matter the work performed by the person as each of the team member works toward developing the product. No sub teams can exist within a scrum team. 3-9 is a valid team size not including PO and SM unless they also act as development team.

Scrum Master (SM) ensures scrum is understood and practiced. SM plays a servant-leader role in helping teams be self organizing and helping PO with backlog grooming, arrangement, interfacing with external influencers etc. The scrum master usually drives the team meetings.

Conclusion of part 1

This, in this article we observed what scrum is, its core tenets and why would a team follow scrum. We also learnt about the different roles members of a scrum team perform. Get the second part of this article here which talks about the tools and metrics involved in scrum which let you calculate pace and track progress of your team.