--------------------------DE-TOUR--------------------------
In this chapter, the following are included for clarity and context. They are not part of The Scrum Guide:
Standards, Definition of “Done” for new teams, Agile versus Scrum, Scrum-Waterfall Hybrid model, ScrumButs
--------------------------DE-TOUR--------------------------
Scrum is not a methodology, process, or technique for building products. It is a framework within which one can employ various product building processes and techniques.
Scrum is a collaboration framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
As a framework, Scrum provides a broad structure consisting of a Scrum Team and associated roles, events, artifacts, and rules.
Scrum is lightweight with only three roles, five events, and three artifacts. It is simple to understand.
This structure enables a simple but effective way of working together as a team towards a focused goal.
Scrum is NOT a process but a framework – What does this mean?
Scrum is not a process or methodology for building products. Unlike a process or method, it does not prescribe a detailed development blueprint specific to an industry sector or domain.
It is a container framework wrapping around any appropriate process or technique. A team within an industry sector can choose to employ industry specific processes and techniques within Scrum. For example, the software building Scrum Team can employ software engineering techniques such as continuous integration, Test Driven Development, etc. as part of their development work.
Fig. 9- Scrum- Container of other Processes and Techniques
-------------------Question- 18--------------------------
Scrum is best described as a
a) Software methodology.
b) Framework for developing and sustaining complex products.
c) Product development process.
d) Collection of best practices.
-------Answer-------
Scrum is a framework within which appropriate processes and techniques can be employed to develop complex products. Correct answer is 'b.'
-------------------Question- 18--------------------------
How does this framework work? - Heartbeat of Scrum
Irrespective of the domain-specific product building techniques applied by different Scrum Teams, all teams follow the same Scrum framework. Scrum is founded on empiricism, and three pillars uphold every implementation of empiricism. Scrum events are built around these three pillars. If these pillars are properly followed, Scrum will be healthy.
The three pillars of empiricism are
1. Transparency: Transparency means
• Providing visibility of information about the work and the outcome.
• Using common standards for information so that observers will share the common interpretation and understanding.
By transparency, the significant aspects of the work must be visible to those responsible for the outcome.
2. Inspection: performing frequent reviews of the Scrum artifacts and progress towards the Sprint Goal to get early feedback on undesirable variances.
3. Adaptation: performing adjustments if the inspection finds variance beyond acceptable limits, and hence the resulting product will be unacceptable. The Scrum Team has collective responsibility to make the adjustments as soon as possible to minimize further deviation.
-------------------Question- 19--------------------------
Transparency, Inspection, and Adaptation are the three pillars of
a) Empirical Process Control Theory.
b) Lean.
c) PDCA.
d) Six Sigma.
-------Answer-------
Correct answer is ‘a.’
-------------------Question- 19--------------------------
Other than the Sprint itself, which is a container for all other events, each of the other four events in Scrum is a formal opportunity to inspect and adapt. These four events are predefined points of inspection to understand what has happened. In every Scrum event where inspection is performed, there can be an opportunity to adapt and respond. Fig. 10 shows the events of Transparency, Inspection, and Adaptation.
Fig. 10- Pillars of Empiricism
What is an example of the team applying a transparency principle?
The empirical approach requires the team to increase the transparency of the information as much as possible. One can increase the transparency by keeping the information factual, making it visible to those responsible for the outcome, and establishing common standards. An example of a common standard is the definition of "Done." Those performing the work and those accepting the work product must share a common definition of “Done.”
-------------------Question- 20--------------------------
Transparency in empiricism refers to
a) Clear thinking and planning by each team member.
b) The significant aspects of the product development process are defined by common standards and made visible so the observers will share the same understanding.
c) The highest levels of morality.
-------Answer-------
Transparency requires that significant aspects of the process must be defined by common standards, and they must be visible to those responsible for the outcome. Correct answer is ‘b.’
-------------------Question- 20--------------------------
--------------------------DE-TOUR--------------------------
'Standard' is not a formal element of the Scrum framework. To add clarity, this book uses the term ‘Standard’ to denote things like definition of “Done,” “Definition of Ready,” etc.
--------------------------DE-TOUR--------------------------
The definition of “Done” defines set of conditions that must be met in order to accept the team’s Sprint outcome as a product Increment. In other words, a product Increment is a body of inspectable, "Done" work.
As an example, the following can be some possible conditions of a definition of “Done”:
• The Completed Product Backlog Item must pass all automated integration tests.
• The Completed Product Backlog Item must have an associated technical document listing impacted technical components.
• The Completed Product Backlog Item must meet the technical performance requirements defined in the organization’s performance objectives.
By using the definition of “Done” everyone transparently understands what a “Done” Product Backlog Item or a "Done” Increment means. In the Sprint Review, a Product Owner will accept a Product Backlog Item as complete if and only if it meets the conditions set forth in the definition of “Done.” The definition of “Done” mostly contains technical conditions such as quality, performance, etc.
-------------------Question- 21--------------------------
What is used by the Scrum Team to identify unfinished work in a Sprint?
a) Coding Standard
b) Definition of Ready
c) Testing Standard
d) Definition of “Done”
-------Answer-------
The definition of “Done” provides the same shared understanding of what it means for the work to be complete. It spells out all that is required to get the work ‘done.’ So, it is used by the team to assess what is yet to be done to complete the product Increment. Everybody developing the same shared understanding is the key to transparency. Correct answer is ‘d.’
-------------------Question- 21--------------------------
The definition of "Done" need not be the same between different Scrum Teams of an organization. However, any one product or system should have one definition of “Done” which will be a standard for any work done on it. This will be discussed further in Part 2.
The Scrum Team lives by Scrum Values so that the Scrum Pillars come to life
Scrum values are a set of fundamental qualities underpinning the Scrum framework. The older versions of The Scrum Guide did not contain these values. Later the authors regarded these values as an important common denominator to develop better software and hence added them to The Scrum Guide. Scrum Teams live by five values: commitment, courage, focus, openness, and respect. Being proficient in living these values brings the Scrum pillars of Transparency, Inspection, and Adaptation to life and builds trust for everyone. The Scrum Team members learn and explore these values as they work with the Scrum events, roles, and artifacts. These values are seen as another checkpoint to compare the behavior within the Scrum Team to see if the behavior reflects the understanding or just the mechanics.
The five values of Scrum are:
1. Commitment
Commitment of every team member to achieve the goals of the Scrum Team. Commitment in following the pillars of empiricism and self-organization and using them to achieve the goals.
2. Courage
Courage to work on tough problems. Courage to do the right thing by accepting that the future cannot be predicted and responding to emerging change. Courage helps everyone to be grounded in reality not giving into personal pride.
3. Focus
Focus of the team on prioritizing and completing the Sprint work to achieve the goals of the Scrum Team. Focus helps to avoid doing other things not related to the Sprint Goal.
4. Openness
Openness of the Scrum Team and its stakeholders in expressing and facing the facts and truths about all the work and challenges with performing the work, thereby increasing transparency. Openness to collaborate with others with the highest amount of transparency.
5. Respect
Respect each other as capable and independent people so that it can provide a trustworthy environment to learn and share.
-------------------Question- 22--------------------------
A Development Team member is requested by an important stakeholder to help them with an urgent and important task outside the Sprint Goal. The Team member set aside the Sprint work for the day and instead helped with this request. Which statement best describes the Team member’s action?
a) The Team member has gone the extra mile and must be rewarded.
b) The Team member has violated Scrum rules by not consulting with his manager.
c) The Team member did not live by the Scrum value of focus.
-------Answer-------
The Scrum value of focus helps to avoid doing other things not related to the Sprint Goal. The Team member is expected to live the Scrum value of focus by prioritizing and completing the Sprint work to achieve the goals of the Scrum Team. Correct answer is ‘c.’
-------------------Question- 22--------------------------
What if our team is not mature enough to create a useable Product Increment every Sprint?
The objective of every Sprint is to produce at least one potentially releasable and useable Product Increment. The definition of ‘Done’ should have conditions that the Product Increment must meet to be released to production. For newer teams this is often a big challenge.
Yet the definition of “Done” should not be set with the objective of making it easy to meet although it will fail to qualify for production. Unless the Increment is potentially releasable, the Scrum Team cannot get feedback from actual usage. Diluting the definition of “Done” will hide the current weaknesses in Product Development.
Given this, even a new team should define “Done” with conditions such that the Increment will be Production ready. At the same time, the conditions need to be realistic to motivate the team. Over the iterations, as the team’s ability matures, more stringent conditions can be gradually added. Having a realistic definition of “Done” for a new team means that the working Increment may have known bugs, but they are transparent between the Development Team and Product Owner.
--------------------------DE-TOUR--------------------------
Since Scrum was in existence before the Agile movement, Agile is not referred to within Scrum. Today Scrum is widely seen as one of the “methods” under the broader umbrella of “Agile.” Many regard Scrum and Agile as being the same. We need to put these things into perspective before moving on.
--------------------------DE-TOUR--------------------------
How does Scrum relate to Agile?
Agile within software development is associated with “The Agile Manifesto.” The Agile Manifesto is a proclamation of a better way of working to create software. The Agile Manifesto is a set of values and principles for a new way of software development. Scrum has contributed a lot to the development of Agile. See agilemanifesto.org for more information.
Though the Agile Manifesto is widely seen as the mother of all Agile-based frameworks, Scrum, which is an alternative software development model, existed before the Agile Manifesto was written.
Scrum started as an alternative approach to complex product development several decades back. The rough idea of Scrum in product development was introduced by Hirotaka Takeuchi and Ikujiro Nonaka in their white paper titled “The New New Product Development Game,” which was published in the Harvard Business Review in 1986.
Ken Schwaber and Jeff Sutherland introduced Scrum as an alternative to traditional development models to systems and the software development world. They presented a process framework called Scrum at the 1995 OOPSLA Conference. They presented Scrum as an enhancement to traditional models of systems development.
Later they defined the Scrum framework that employs Scrum Teams and the associated roles, events, artifacts, and rules to produce frequent working Product Increments.
Scrum is a standalone framework, but it respects the Agile Manifesto
The Agile Manifesto was written by group of representatives of “alternative implementations of software delivery models” in February 2001. The authors of The Scrum Guide (Ken Schwaber and Jeff Sutherland) were among these representatives.
In principle, the Agile Manifesto’s ideas have a lot in common with the Scrum framework elements. Scrum mutually respects the Agile Manifesto values and principles. Scrum explicitly lists “Understanding and practicing agility” as one of the services that the Scrum Master provides to a team.
Agile is a philosophy about a “Newer way of developing software.” It is a philosophy because it is not prescriptive on an exact implementation. Scrum is one of those concrete implementation frameworks to help people develop any complex product not just software. The Scrum framework definition is concrete with Scrum Teams and the associated roles, events, artifacts, and rules.
We want to become Agile. Where do we start?
Anyone wanting to transition to Agile should understand the Agile Manifesto, and its values and principles. Many organizations embrace the Agile values and principles at the conceptual level. Then they decide on a concrete implementation framework such as Scrum that gives a structure to the Agile way of working. After that, the Scrum Team employs additional techniques that add value specifically to them within the Scrum framework. For example, many Scrum Teams in the software domain employ Extreme Programming (XP) practices within the Scrum framework to add agility to their development work.
Original Scrum is defined in The Scrum Guide - Immutable
For organizations with historical development practices and infrastructure, the most common scenario after applying Scrum is that the Scrum Teams may encounter issues that will impede their effort to create potentially shippable Increments within short Sprints. Scrum will expose such dysfunctions in the current organizational ecosystem. It is normal and expected.
The organizations should try to correct these dysfunctions. Sometimes organizations take the route of ScrumButs to handle these dysfunctions.
ScrumBut refers to an adjustment or modification made to Scrum so that the organization can hide the problem instead of addressing it.
Scrum.org defines ScrumButs as having a particular syntax:
(ScrumBut)(Reason)(Workaround)
Scrum.org provides some examples of ScrumButs:
"(We use Scrum, but) (we cannot build a piece of functionality in a month,) (so our Sprints are 6 weeks long.)"
"(We use Scrum, but) (sometimes our managers give us special tasks,) (so we do not always have time to meet our definition of “Done.”)"
Hiding the weaknesses using ScrumBut will take away the opportunity for organizations to address them and become agile.
-------------------Question- 23--------------------------
Shortly into using Scrum for the first time in an organization, the Scrum Team runs into several issues against following Scrum. The most common inference is
a) Scrum should have been applied for Product Development instead of Software Development.
b) The team should have followed only the Scrum’s guidance about how to perform software engineering practices like design, coding, testing, etc.
c) The Scrum Team didn’t plan the product development project completely in advance.
d) It is normal for first timers. Scrum will expose all weakness in the current organizational ecosystem. They should be seen as the opportunities for improvement and need to be resolved.
-------Answer-------
For organizations with historical development practices and infrastructure, the most common scenario after applying Scrum is that it will expose the weaknesses in the current organizational ecosystem. It is normal and expected. The organizations should strive to address these weaknesses while maturing their team’s ability to produce useable software within the Sprints. Correct answer is ‘d.’
-------------------Question- 23--------------------------
Can we follow a hybrid approach of combining Scrum and Waterfall?
Some organizations learn about the dramatic changes that Scrum brings and want to implement Scrum. At the same time, they want to implement Scrum “smoothly.” A common approach is to follow a hybrid model where they retain the existing methods and selectively apply partial Scrum. An example is the planning of Sprints into a Design Sprint, Development Sprint, Testing Sprint, etc. This is nothing but Waterfall in a Scrum disguise.
The Scrum authors are particular about providing a version of Scrum that will maximize the benefits intended. The approved body of knowledge on Scrum is "The Scrum Guide.” The authors position this version of Scrum in The Scrum Guide as immutable, i.e. it cannot be adulterated with customized practices or hybrid terminology.
Any such act will dilute the identity and distinguishing character of Scrum. The adulterated Scrum without its original identity may not be seen as a “change for the better” by the people in the organization.
If someone claims that a hybrid model is working fine, they need to investigate if they are able to witness the transformational changes that Scrum brings:
• Has the risk of creating waste gone down by early and frequent delivery of production-quality Increments?
• How many investments were identified as “waste or questionable” and severely modified or terminated early?
• Are the Scrum Teams producing more valuable and successful products?
• Has the engagement with business partners and customers increased significantly?
-------------------Question- 24--------------------------
Is Scrum immutable?
a) Yes
b) No
-------Answer-------
Changing Scrum or customizing it for the convenience of an existing culture may dilute its distinguishing identity as a “change agent.” Also it may be perceived as just another additional practice which fails to motivate those who anticipate change. Correct answer is ‘a.’
-------------------Question- 24--------------------------
We already have multiple releases. Why should we consider Scrum?
Some organizations may already have multiple releases of their product instead of batching. However, they may not have a disciplined product development approach to contain the risks and increase the value.
• Scrum enforces the discipline of timeboxing: A Scrum Team produces a potentially releasable and useable Increment every few weeks. Timeboxing into a few weeks leads to frequent, highly relevant feedback that enables the teams to replan and mitigate risks. At the end of a few weeks, if the review reveals that the Increment is a waste, the direction for the next Sprint can be adjusted. The risk of pursuing a wrong direction is limited to the cost of one Sprint.
• Scrum nurtures the owner’s mindset at the team level: Scrum offers several opportunities to course correct and make the right decisions. To make appropriate decisions, the team must have an owner’s mindset. In Scrum the Product Owner is given empowerment on product decisions, and the team is given empowerment on their work decisions.
Some organizations have occasions where such self-organized teams release the initial Increments to actual use (without waiting for the full product suite) and realize business benefits early. Since the product is still being built, these early benefits then can be used to fund the subsequent work.
In some other instances, by completing the high-value items in the Product Backlog, the team may have realized most of the intended business value already. In such cases, the product building effort can be closed early, thus saving cost.
This disciplined ecosystem of risk mitigation through empiricism, bottom-up intelligence, and the owner’s mindset of value maximization is possible only with the application of Scrum in its entirety.
Summary
• Scrum is NOT a process for building products.
• It is a container framework within which one can employ various processes and techniques.
• It is a collaboration framework within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value.
• It focuses on value delivery and may not reflect a traditional project approach.
• It has only three roles – Product Owner, Scrum Master, Development Team.
• It has only three artifacts – Product Backlog, Sprint Backlog, Increment.
• It has only five events – Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
• The three pillars of empiricism are the heartbeat that upholds every implementation of the empirical process control.
• The pillars are Transparency, Inspection, and Adaptation.
• Transparency requires that significant aspects of the process be visible and defined by a common standard.
• The definition of “Done” is a standard for ensuring Transparency. Its definition must enable the team members to have a shared understanding of what it means for the work to be complete.
• Inspection requires that Scrum users frequently inspect the Scrum artifacts and progress towards a Sprint Goal to detect undesirable variances.
• Adaptation requires that, in the event of unacceptable variances, the Scrum Team must make adjustments as soon as possible.
• The Scrum Team members learn and explore five values of Scrum as they work with the Scrum events, roles and artifacts. When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of Transparency, Inspection, and Adaptation come to life and build trust for everyone.
• Scrum existed before Agile. Scrum respects the Agile Manifesto.
• Implementing only parts of Scrum is not Scrum. Scrum is immutable.