Loading...
Menu

A Lightning Introduction to Scrum

h1={color:#000;}.

Also by Mohammed Musthafa Soukath Ali, available at leading online retailers:

1. Scrum Narrative and PSM Exam Guide

2. The Professional Scrum Product Owner: Guide to Pass PSPO 1 Certification

3. A Pocket Guide to Passing Professional Scrum Master (PSM 1)

##

A Lightning Introduction to Scrum

Copyright 2016 Mohammed Musthafa Soukath Ali

All rights reserved

The Scrum Guide ©2016 Scrum.Org and ScrumInc is offered for license under the Attribution Share-Alike license of Creative Commons, accessible at ‘http://creativecommons.org/licenses/by-sa/4.0/legalcode’ and also described in summary form at ‘http://creativecommons.org/licenses/by-sa/4.0/’. While this book reproduces the content from The Scrum Guide, it does not adapt the original content.

The information contained in this book is provided without any express, statutory, or implied warranties.

Rev. 1.0

2016 Edition

Editor

Samantha Mason

##

[]Table of Contents

1. Chapter 1 – A new approach for complex problems

2. Chapter 2 – Vehicle of Scrum – An Absolute and less complex team

3. Chapter 3 – Scrum – A container and collaboration framework

4. Summary

##

[]Chapter 1 – A new approach for complex problems

How a Product is built using the traditional way – Waterfall

Organizations create strategies for business purposes. Some of these strategies aim at building product capabilities. For example, a software product building strategy may include a Customer Relationship Management System, Billing and Payments, Mobile Channel, New Product Introduction, etc.

Many organizations use a process methodology called waterfall in their projects to build products. Two types of people are needed to define the business and development aspects of project plans.

The business people: They define what the product should do. To define the product needs, they make long-term predictions about the future. Some examples of predictions include what the value of the product will be, how it will be received in the market, and more importantly what that market will be when the product is actually released. Predictions are based on many assumptions and projections built on what is known today, which may be years before the product is actually released.

The project managers or planners: They plan how to build the product. Based on the product needs deduced from the business predictions, they come up with a sequence of activities like Analyzing, Designing, and so on. They also predict (estimate) the future cost and time of these activities to find the total project cost and time. Such estimations are based on many assumptions and future projections of the product needs, people competency and behavior, project technology, etc.

Why the name waterfall?

The outcome from the waterfall-based project planning is a detailed plan.

Later, during the execution of this plan, future changes may invalidate the current plan. Such changes may require re-planning project activities, sometimes again from product definition, and re-doing all the activities. Such revisiting, re-planning, re-doing, is called as Iterating. In waterfall, iteration is seen as the result of bad planning. So, when people in waterfall encounter a change, they reactively go through an elaborate change control process to resist the change, to keep the original plan intact.

A waterfall-based project plan expects that the sequence of steps in the plan will go forward without requiring changes. They resist changes when they do occur. So, the plan is designed such that the activities only go forward without iterating back again, and hence the name waterfall. It is just a waterfall, the water falls only forward, not backward.

Fig. 1- Waterfall way of building products

Waterfall – The tale of late feedback

After executing the complete plan, usually after a long period of time, the product is delivered to Business / users in a big one-time release. These people see the outcome and provide feedback about the product. The business may choose to test the market and release the product. So, the market also may provide feedback.

If the feedback is positive and indicates the larger acceptance of the product, everyone is happy.

However, this is not always the case. The assumptions made by the business about user behavior may be invalid. The interpretation of the Project Managers / Planners about what the business people wanted may be incorrect. Also, the external factors, market receptiveness, and assumptions might have changed.

Sometimes, the feedback may be about a new insight that requires major modification to the product, or the product itself is identified as obsolete.

Such feedback is called Late Feedback since the waterfall project may already be closed, or it may involve too large an effort to incorporate the feedback so late.

Fig. 2- Late Feedback in Waterfall

Complex problems

Product building is a complex problem. Most often, it is not just an isolated product development, but may involve integration of the product into the larger organizational system.

For example, in software development, as technology evolves and markets change, organizations need to continuously adopt the newer software developments and enhancements into their existing complex web of technology infrastructure.

This complexity is further multiplied by the presence of many other factors such as different people, processes, technology components, and so on.

Complexity becomes more dynamic – Complex Adaptive Problems

Product building is not only complex. Multiple factors involved in building complex products also vary over time. For example, in a software project, a software component that worked in a small-scale system, which has limited users today, may not work when the system becomes larger with multiple users tomorrow. Similarly, some of the developers that worked today may not be available for the project tomorrow, and the productivity may vary.

Such time-dependent complex problems are also called complex adaptive problems.

In these problems, the amount of unknown is really huge in the initial stages and will likely trend down over the course of product development. This trend is called the cone of uncertainty. Therefore, future change is certain in complex adaptive problems.

Is waterfall-based Project Planning a scientific approach?

At the initial stage of a project, planners use techniques such as Critical Path Method (CPM) to scientifically calculate the duration of the project. These calculations need some inputs such as product definition, people productivity, etc. The planners make assumptions to arrive at these inputs.

Since the project is at the initial stage, the cone of uncertainty is high and hence the assumptions have high probability of becoming incorrect.

So, if these assumptions are incorrect, output from the scientific calculation will also be incorrect. Therefore, project planning in the waterfall method is based on scientific calculation, but it does not mean that this planning is foolproof and risk-proof.

Are scientific approaches good for complex adaptive problems?

Scientific calculations and predictions are helpful when the problems are deterministic, stochastic, etc. In these types of problems, the future behavior or result can be modelled or predicted.

Complex adaptive problems are not deterministic. Deterministic requires the elements of the problem to be either constant or follow a definite mathematical model. The elements of complex adaptive problems are not predictable and do not follow a definite mathematical model.

Complex adaptive problems are also more complicated than being stochastic. While the elements of stochastic problems are random, the range or the boundaries of variation can be predicted. This boundary can be derived from data of the past. An example is the toss of a coin. Though the result of the coin toss is random, it is always within the boundary of either head or tail. The elements of complex adaptive problems are not only random, but their random behavior cannot be modeled based on the past.

In complex adaptive environments, what will happen is unknown and hard to predict. Predictions based on scientific approach may need extensive resources and recursive fine-tuning to arrive at an optimal plan. For planning one project, such a huge investment in scientific modeling is usually not justified.

The New Way – Empiricism – Observation rather than prediction

Empiricism theory is based on the concept that complex problems are hard to predict.

Empiricism helps people to navigate uncertain complex problems. It requires them to take one step at a time, such as performing a small amount of work to gather experience.

1. It divides complex problems into a small scope of short-term iterations. For each iteration, just enough work is planned that can be completed within that short iteration of few weeks. There is no big scope of work spanning a long duration.

2. It uses a small team to perform these few weeks of work. It requires them to increase the visibility of work or product information as they travel this iteration.

3. The small team creates a product increment at the end of these few weeks. The Increment is shared with stakeholders for inspection and feedback is solicited. The team gathers experience from this work.

4. From this feedback and experience, new clarity emerges and knowledge is obtained. The scope and plan for the next iteration is adjusted based on this new knowledge.

You can equate the traditional “trial and error” model to empiricism. Each iteration is a trial to solve a problem and gain more clarity. Based on the trial outcome and the newly found clarity, the next iteration is planned. Since each iteration is planned based on the new found clarity from the previous iteration, the risk of unknowns is gradually reduced over the iterations.

Reducing risk increases the probability of meeting the goal.

So, empiricism applies an iterative, incremental approach to optimize predictability and control risk.

Fig. 3- Empiricism through iterative incremental approach

Scrum – A new way to address complex problems

Scrum is a newer way or framework within which people can address complex adaptive problems. Scrum is founded on empiricism control theory. Scrum provides new set of terminology to define the framework.

Is Scrum a proven approach?

Ken and Jeff authored Scrum two decades ago. Several organizations and practitioners have applied it with profound results. Many case studies are documented. Today, Scrum is the most widely adopted framework among all the frameworks intended to bring agility into producing software.

Scrum events that offer opportunity for early feedback

There are total of five events within the Scrum framework. Other than the container event Sprint, each event implements the theory of empiricism by offering an opportunity to get early feedback and the opportunity to best utilize that feedback.

Five events of Scrum

1. Sprint: Sprint is the heart of Scrum. It is like a mini-project that contains the other four events.

2. Sprint Planning: This is the first event of the Sprint. A small amount of work is chosen and a plan of how to deliver that work is put together.

3. Daily Scrum: The short and quick daily recurring event within the Sprint in which the team members synchronize their progress with each other and confirm the next 24-hour plan.

4. Sprint Review: The one-time event within Sprint in which the team makes the progress visible to the stakeholders. Both the team and stakeholders collaborate to adjust their next steps.

5. Sprint Retrospective: This is the final event of the Sprint. This is an inspection and adaptation opportunity for the Scrum Team to inspect their way of working and identify potential improvements.

Fig. 4- Scrum events

##

[]Chapter 2 – Vehicle of Scrum – An absolute and less complex team

Along with empiricism, Scrum aims to maximize the value of people working together. The vehicle of Scrum is the Scrum Team. It is a small team that has a very clear focus on product ownership and has less complexity in the way it works.

To enable this ownership and reduced complexity, Scrum lays down two strict rules:

1. Reduce management-communication and role overhead by being self-organized: A Scrum Team plans, executes, and controls its own work without any one individual managing their work. The team contains only three roles, Product Owner, Scrum Master, and Developer. A team that manages its own work is called self-organizing.

2. Take full ownership by being cross-functional: A Scrum Team must have a minimum of three and maximum of nine Developers so that the team can have all skills necessary to create the product. A team that has all the required skills to build the product is called cross-functional.

Figure 5 shows the Development Team that is part of a Scrum Team. Just like the Scrum Team, the Development Team within the Scrum Team is also cross-functional and self-organized.

Fig. 5- Scrum- Development Team

Where is the manager for the project?

In a Scrum Team, there is no role other than the three previously mentioned roles. This means there is no Project Manager.

Building complex products is a knowledge game. The team involved in this game contains a knowledge-based workforce. If they face challenges in their work, they are knowledgeable enough to collaborate in innovative ways to address them.

However, this ground-level team needs to be structured and empowered to become self-organized and cross-functional.

One hindrance to self-organization is how project teams are traditionally managed. Usually, a team is assembled with individuals having some unique skill needed for the product development. These individuals are expected to wait for tasks to be assigned to them by a manager. Managers command these individuals with direction and control. Such leadership is known as command and control leadership.

Once their task is completed, the individuals wait for the next task to be assigned. Instead of self-organizing as a team to solve the challenges, they usually just limit their contribution at individual level and execute what is asked.

Another pitfall with command and control leadership is that more often the project decision and directions will reflect the subjectivity of one commanding individual. But, in complex adaptive problems the changes and challenges are generally multi-dimensional. They require multi-dimensional analysis to comprehend and respond. For such multi-dimensional thinking and action, it is desirable to leverage the collective wisdom of all members of the team, rather than just one commanding individual.

Therefore, there is no commanding and controlling manager within Scrum. The Development Team, which is the team on the ground that knows the reality, takes full ownership and self-organizes their work.

If there is no Project Manager, how do we engage existing Project Managers?

In a traditional model, the Project Manager controls the project budget, the project team members, and the project tasks. In Scrum, these activities are distributed between the three Scrum roles.

Though the Project Manager role is eliminated, there are still management positions within Scrum. The Development Team collectively manages the project tasks and their own work. The Product Owner manages the business investment. The Scrum Master manages how Scrum is implemented.

As for the existing Project Manager, they can choose one of these management positions. However, they need to consciously choose the position with the understanding of the responsibilities involved. None of these management positions, such as Product Owner, Scrum Master, etc., involve managing people or unilaterally controlling the project plan or tasks. This will be further explained in the rest of the book.

Self-Organized Teams balance their self-empowerment to create value

In a self-organized team, all the team members plan their work together and track its progress against a common goal. They also identify and resolve challenges together. Without any management or direction from outside, they strive to balance flexibility, creativity, and productivity, so they can maximize the collective value of their work.

Who manages the people aspects of the Scrum Team?

Every Scrum Team usually works within a larger organizational ecosystem. Though Scrum does not have management roles like Project Managers, there is a shared understanding among Scrum Practitioners about the important role “Managers of Organization” play. These managers set and manage larger strategies, define operational units, structure self-organized teams, and help to resolve organization impediments to Agility.

For any personnel issues within the team’s influence, such as personality conflicts, the self-organized team itself will resolve them.

If the issue is outside their influence, such as human resource management functions of hiring, firing, compensation, and other legal aspects, they are handled by the appropriate human resource authority defined by the organization’s management.

Since everyone is a Developer without specialization, can the team members pursue specializations anymore?

The members of the Development Team are called Developers irrespective of their primary skill set. They perform all the development work required to convert the business needs into a useable product feature.

For example, in a Development Team that builds software, each of the Developers could be a specialist in an individual area. But there is no special role assigned to them. As needed, the Developers can take up any activities such as user interface design, design, coding, testing, integrating, user manual creation, etc. to reach the goal. This arrangement is to reduce the role overhead and people working alone in silos.

However, while the specialists should identify themselves as part of the team and learn additional skills to collectively deliver the work, there is no barrier to personally enhancing their special competencies and continuing to specialize.

Scrum – A new way of optimizing work and maximizing value

In waterfall, batching and big bang releases are common.

Accumulating developed product features over a long time period without releasing them for use is called batching. Usually they are released together as a batch in a big-sized release (big bang fashion) in one or two limited production releases.

By batching the features for a combined release, the waterfall plan treats all of these features as having the same value with no sensitivity to time.

The truth may be that different features within a batch may have different business values. So, it will make significant business sense to rank (order) the features by their business values and start delivering those more valuable features earlier.

By having the team work on features with the highest business value first, we earn more return on the team’s work. Early developed features can be released to production if it makes business sense.

There is an exclusive business role in the Scrum Team that is responsible for keeping the product features ordered. This role is the Product Owner.

The Product Owner feeds the list of ordered product features to the team. By ensuring that the team works on higher value features first, and constantly working with them to clarify the business questions, they can optimize the team’s work against value.

The Product Owner can choose to deliver the completed features to production often instead of batching them. By using the feedback obtained from the production usage and any market changes, the Product Owner can adjust the product features and their order to maximize the business value and control risk.

Fig. 6- Product Owner

We do have business managers even today. What is so different with the Product Owner?

The Product Owner does not resort to a traditional working style where they define all the product needs at one go based on today’s knowledge, and then toss a big requirements document over the “fence” to another team for development.

The Product Owner is much more than a traditional business manager in two aspects:

1. Continuous engagement with the team: The Product Owner respects the fact that the future cannot be predicted. They adopt empiricism to continually get clarity and refine the product. They are on the constant look out for every opportunity to maximize the value of the product. They continually work with the team to help them understand the product needs and get the best value out of their work.

2. Ultimate authority of the team’s scope of work: The Product Owner leverages the dedicated Development Team to continually shape the product and uncover new knowledge. So, it is essential that the team should only be working on their product needs. The team should not be “switching the context” of their work due to any external authorities directing them to do “some other” work. So, the Product Owner is the ultimate authority on what the team should work on next. Even the CEO of the organization cannot request the team to work on something else. Anyone wanting to add something to the product, must go through the Product Owner.

How is progress measured in Scrum? What are the key performance indicators (KPI)?

Scrum is founded on empiricism, where the decisions about the next Sprint are taken based on the insight obtained from the previous Sprint.

Every Sprint must create at least one piece of functionality that is useable by the intended users. Only then can it lead to inspection, usage, and useful feedback. So, the Increment is the only measure of progress in Scrum. There is no other metric of progress such as creation of any interim documents/artifacts, completion of phases, etc.

In addition a Scrum Team may internally use some measures such as Sprint Work Planned Vs Completed (Burn-down), Rate of Completion (Velocity), etc. However, these are only internal metrics used by the team to manage their work. They are not indicators of progress for stakeholders.

Scrum – A new way of leading by coaching

In Scrum, empiricism and self-organization drive the product development approach. A leadership role is introduced to teach and coach people about these concepts and other elements of Scrum.

This leadership model is called servant leadership. The servant-leader does not take the lead in planning or controlling the development work. Instead, the servant-leader mentors the team to manage their work themselves within the Scrum framework.

In Scrum, the person playing the servant-leader role is called the Scrum Master. The Scrum Master serves the team by coaching them to work together for a common goal irrespective of their individual skills. The Scrum Master mentors the team so that it becomes self-sufficient in their product development ownership. Such a self-sufficient team will frequently create working product increment, get early feedback in order to re-plan based on emerging insights, and solve the problems by their collective wisdom and collaboration.

Fig. 7- Scrum Team

Is the Scrum Master only a teaching role?

Scrum Master is a management position in Scrum. Scrum Master manages the Scrum Implementation. The Scrum Master coaches the Scrum Team to realize their potential. They are not just teachers or coaches. They are responsible for many other activities that are instrumental in transforming teams into value creators.

An example of a critical activity they play is- when the Scrum Team runs into issues that prevent it from achieving their goal and if these issues are outside the team’s influence, the Scrum Master owns these impediments and resolves them. The Scrum Master also helps the organization to adopt Scrum, set the goals to improve the way of working in Scrum, etc.

If there is no detailed project plan, how will we know the details of the project and work execution?

Scrum uses three artifacts to track the information about the Product and the work. We have already discussed two of the artifacts, the Increment and the Product Backlog.

1. The Increment is the mark of the real progress, and it provides information for required stakeholders about the progress so far.

2. The Product Backlog is the product definition in terms of ordered product features. It is never frozen (closed for changes) and is a continuously evolving artifact because the Scrum Team and Product Owner in particular are always looking for changes and opportunities to maximize the value of the product. Using the ordered features, one can understand what the team will work on in the future.

3. The Sprint Backlog is a temporary artifact created for each Sprint. It contains both the subset of the Product Backlog items chosen to be delivered in a Sprint and also the plan of how to deliver them. It is the plan maintained by the team about what tasks should be performed within the current Sprint.

Fig. 8- Scrum artifacts

##

[]Chapter 3 – Scrum – A container and collaboration framework

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

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.

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. The following picture shows the events of transparency, inspection, and adaptation.

Fig. 10- Pillars of Empiricism

What is an example of the team applying a transparency principle?

So, 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”.

The definition of “Done” defines what is meant by the completion of a Product Backlog item or a product Increment. The definition of “Done” contains conditions that must be met in order to deem a team’s deliverable as a Potentially Shippable Item. 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 only if it meets the conditions set forth in the definition of “Done”. The definition of “Done” can also contain non-functional requirements like performance.

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

The definition of “Done” need not be the same between different Scrum Teams of an organization. However, any one product or system should have a definition of “Done” which will be a standard for any work done on it. This will be discussed further in Part 2.

What if we are 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 very big challenge.

Yet, the definition of “Done” should not be set with the objective of making it easy to meet though 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 gets more mature, 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.

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 very descriptive 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 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.

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?

We already go for multiple releases. Why should we consider Scrum?

Some organizations may already go for 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 produce business benefits with initial increments, which could fund the follow-on work. In some other instances, the follow-on low-value work is cut down after enough value is delivered, 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

• The waterfall way of product building leads to a plan that tries to predict future.

• The waterfall plan does not proactively look for early feedback. Feedback happens late.

• In complex adaptive problems, future is uncertain and hard to predict. Waterfall way of predicting the future is risky.

• Empiricism advocates observation rather than waterfall way of prediction to navigate complex adaptive problems.

• Empiricism asserts that knowledge comes from experience and making decisions based on what is known.

• Scrum is founded on empiricism that facilitates early feedback.

• Scrum has been used to manage complex product development since the early 1990s.

• Scrum employs an iterative, incremental approach to optimize predictability and control risk.

• The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules.

• Scrum is NOT a detailed process for building products, but a high level 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.

• Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt.

• Traditional command and control leadership blocks the team’s bottom-up intelligence.

• Scrum facilitates team intelligence by building a small cross-functional team that self-organizes its work.

• Cross-functional means having all competencies needed to accomplish the work without depending on others not on the team.

• Self-organizing means empowerment to choose how best to accomplish their work rather than being directed by others outside the team.

• The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.

• The Development Team builds the Product.

• Individual Development Team members may have specialized skills, but everyone’s title is Developer.

• Individual Development Team members may have areas of focus, but accountability for the development ownership belongs to the entire Development Team.

• The Product Owner is responsible for maximizing the value of the product and the work of the Development Team.

• The Scrum Master is responsible for ensuring Scrum is understood and enacted.

• The Scrum Master is a servant-leader for the Scrum Team.

• The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

• Scrum existed before Agile. Scrum respects the Agile Manifesto.

• Implementing only parts of Scrum is not Scrum. Scrum is immutable.

##END##

Thank you for reading this book. Your one minute feedback means mountain of motivation to me. If you find it meeting your needs, and hopefully you have a minute to express that, could you leave a review at your favorite retailer?

Thanks!

Mohammed Musthafa Soukath Ali

About the Author

Mohammed Musthafa Soukath Ali

SCJP, LOMA 286, PMP, PSM, PSPO, SA, SPC

Musthafa is the author of the #1 Best Seller book “Scrum Narrative and PSM Exam Guide” in Shakespir.com He is also the author of the latest book “The Professional Scrum Product Owner”

He is ranked as one of the Tata Consultancy Services (TCS) Global Top Project Planners, acting as specialist coach for complex IT Application Development projects. He is also external Management Capability Adviser for some of the Tata Group Companies.

He is a designated Agile Software Delivery Expert, having consulted 10+ global customers. He published 9 papers in conferences with two international speaker invitations at Berlin/Spain. He is one of the Subject Matter Experts in TCS Corporate Agile Think-tank.

His specific expertise include Coaching/Consulting for building up Agile Culture at Organizations, Delivery Coach for J2EE based enterprise application development, Consulting/Audit on global software delivery capabilities, Domain Analysis in Retail Banking/Personal Finance, and Coaching on Expedited Competency Development Practices.

You can connect with the author through his linkedin network: https://in.linkedin.com/in/mohammed-musthafa-soukath-ali-9a857762

##


A Lightning Introduction to Scrum

  • Author: Mohammed Musthafa Soukath Ali
  • Published: 2016-06-19 16:35:09
  • Words: 6850
A Lightning Introduction to Scrum A Lightning Introduction to Scrum