Scrum is the fastest growing Agile framework. Yet, incredibly difficult to implement.
Previously, we discussed a brief overview of Agile. As mentioned before, Agile is a set of principles that encompasses many frameworks such as Extreme Programming, Lean, and the most popular framework, “Scrum”.
Like traditional project management, there exist processes. Each process will have an input, enablers/ controls (called tools and techniques in Waterfall), and outputs. However, processes in the form of Agile develops “working software” or a working deliverable via one or more processes.
Unlike traditional project management, Agile- and by extension Scrum- does not necessarily define the total scope nor plan everything up front. Instead, scope and planning are done iteratively or adaptively as unknowns become known. This is especially true where a new and novel product is being created (or invented) such as in the software or pharmaceutical industry.
Scrum Background and Start
Scrum originated in theory back in 1986 by two competing theorist from Japan. Hirotaka Takeuchi (now a professor at Harvard Business School) and Ikujiro Nonaka published a white paper titled “The New Product Development Game” in the Harvard Business Review describing a methodology that resembled Rugby. Thus the name Scrum later came to be.
In 1993, three westerners fined-tuned “Scrum”. They were Jeff Sutherland, John Scumniotales, and Jeff McKenna. However, Scrum did not gain real popularity until Ken Schwaber and Mike Beedle wrote and published the book titled “Agile Software Development with Scrum” in 2001.
Scrum, like most other frameworks built off the Agile principles, is meant to be lightweight and simple to understand, yet proves to be difficult to master when adopted in an organization.
Scrum Theory
Scrum was founded on “empiricism”, meaning knowledge is learned through our senses. It is not merely inherited. In other words, knowledge comes from experience ocmbined with what is already known.
There are three pillars that uphold every implementation of empirical process control:
- Transparency – every aspect of a process must be visible to the person or persons responsible for the outcome. Note- In Agile, the team is always responsible, not an individual.
- Inspection– Use frequent inspections of deliverables (or artifacts discussed later). However, inspection should not be so frequent that is gets in the way of work.
- Adaptation– If during inspection, the development team sees uncontrolled deviations or that the deliverable will not work, changes are made quickly to minimize further deviation. Combined with inspection, it creates an environment of continuous improvement through Scrum.
Inspection-and-adaptation is seen and practiced through four formal Scrum events (each discussed in more detail later).
- Sprint Planning
- Daily Scrum
- sprint Review
- Sprint Retrospective
There are three main components of Scrum that we will discuss in order. They are the Scrum team, artifacts, and events.
Key members of a Scrum Team
In Scrum, it is vital to know the key members of the project team.
Product Owner
In Waterfall Project Management, this would likely be the sponsor of a project. In Scrum, the sponsor is know as the product owner. The product owner ensures that the project is profitable and has a positive return on investment.
As such, the product owner prioritizes the features of a product and/or outcomes of a “sprint” (discussed later). The product owner is allowed to adjust these features or outcomes as well as their priority when needed in order to adjust rapidly to market conditions etc. This dynamic allows the product owner to focus on the “what” of the project, not the “how” or method it will be completed.
This list of “whats” is called a “product backlog” which will be discussed further later. The product owner helps create and manage this list by:
- Clearly, without ambiguity, defining the items on the product backlog
- Prioritizing features or outcomes
- Adjusting their priority (order of completion) as needed and when needed
- Optimizing the product value of work being performed by the team
- Making sure the product backlog is visible, transparent, and clear to the team through showing what the team will work on next
When a deliverable is completed in a certain sprint, the product owner is the one who will accept or reject the deliverable. (Similar to “Validate Scope” process in Waterfall.) Unlike waterfall, a product owner is one person- it cannot be a group. This person has complete authority over the product.
Scrum Team
Similar to all other types of project management, Scrum has a team. There are some similarities, but many differences as well. This team is the group that will execute the work in time-boxed “sprints” that will be discussed later.
In Scrum, team members are all called “developers”. This arises out of the fact that Scrum was originally built for the software industry.
In Scrum, teams are self-organizing. This means that your team will naturally bond into a group and should remain on the same team regardless of project. The team will develop their own set of operating guidelines under the leadership of a Scrum Master.
Development teams are cross-functional. In other words, each team member can do every task in a backlog. There are no sub-teams as all members are cross-functional.
As mentioned earlier, not one individual is accountable for an action or result. Rather in Scrum, the entire team is held accountable as whole. The teams responsibilities are the following:
- Delivery of a product increment
- Quality of a product increment
- Self-managing their own work
- Estimating the product backlog items by estimating the effort for each item
Attaining the right sized team for optimization is key. The team must be small enough for agility but large enough to complete significant work within each sprint. The amount of work in a sprint is called “velocity”.
The team should be between three to nine developers. This team size is in addition to (does not count) the Scrum Master and the Product Owner. The thinking is that any development team less than three decreases interaction and results in smaller productivity. In contrast, teams greater than nine requires too much coordination to be self-led, and generates avoidable complexity.
Scrum Master
The Scrum Master is the project manager per se. But because there is technically no hierarchy in a Scrum team, he or she is not a manager. More like a captain of a sports team.
This expert is a servant-leader that is primarily responsible for ensuring Scrum practices are being followed and is charged with removing impediments so the team can focus on the work at hand. The Scrum Master facilitates and leads events of Scrum and ensures consensus. The Scrum Master is also responsible for the following:
- Ensures engineering practices are being followed
- Removes impediments (conflicts or roadblocks to success) are addressed and removed
- Coaches the development team in self-organization and cross-functionality
- Advises the Product Owner on how to arrange the product backlog to maximize value. Provides counsel and advice so the client sees deliverables continuously in a logical flow for the overall product.
Scrum Artifacts
So far, we have discussed the scrum team. Now we will discuss scrum artifacts. These are a set of documents or charts that will facilitate organization of the overall product and what has to be completed. These artifacts encourage transparency of the product. every member should know every aspect regardless of role.
Product Backlog (PBL)
The product backlog is an ordered list of everything that might be needed in the product. This list is the responsibility of the product owner to include its content, availability, and order of the list. The product backlog specifies the “what” and “how” of a feature from a customer-centric perspective. These items are written in a “story” form in a format similar to “As a (type of user), I want (goal of deliverable) so that (reason or why).” For example, “As an account manager, I want to search the database of existing leads, so that I can close deals“.
The product backlog should have a product wide “definition-of-done” (discussed later) to prevent technical deficit. The PBL may also contain acceptance criteria needed.
Effort to complete the work is estimated by the development team with input from the product owner. The list of all the items on the PBL should include the features, requirements, enhancements, and fixes that constitute changes to be made to the overall product in future releases (scope in Waterfall). Effort may be expressed in man hours or similar. Story points, this is a more qualitative measure of effort. Yes- it can be confusing. For more information, click here!
Items at the top of the PBL are more detailed than the ones of lower priority at the bottom of the PBL. This is an example of rolling wave planning taught in the PMBOK 6th ed. Keep in mind that the PBL is a constantly evolving artifact of Scrum.
The PBL is visible to all stakeholders on the project. As it evolves, it can change in priority or needs depending on changing market conditions, budget etc. Similar to a Work Breakdown Structure in Waterfall, estimates can be achieved to forecast time of remaining work and possibly budget.
PBL refinement (aka “grooming”) is the activity of creating and refining the PBL, estimating activities, and prioritizing them at any given point.
No Comments