SCRUM Theory

Scrum Theory

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.
Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.

Transparency Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.
For example:

• A common language referring to the process must be shared by all participants; and,
• A common definition of "Done"

1 must be shared by those performing the work and those accepting the work product. Inspection
Scrum users must frequently inspect Scrum artifacts and progress toward a goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.
Adaptation
If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.

Scrum prescribes four formal opportunities for inspection and adaptation, as described in the Scrum Events section of this document.

• Sprint Planning Meeting
• Daily Scrum
• Sprint Review
• Sprint Retrospective

(Courtsey - 1991-2013 Ken Schwaber and Jeff Sutherland - Scrum.org)

Handling Projects with SCRUM-BAN

SCRUM-BAN

Scrum-ban is a software production model based on Scrum and Kanban. Scrum-ban is especially suited for maintenance projects or (system) projects with frequent and unexpected user stories or programming errors. In such cases the time-limited sprints of the Scrum model are of no appreciable use, but Scrum’s daily meetings and other practices can be applied, depending on the team and the situation at hand. Visualization of the work stages and limitations for simultaneous unfinished user stories and defects are familiar from the Kanban model. Using these methods, the team’s workflow is directed in a way that allows for minimum completion time for each user story or programming error, and on the other hand ensures each team member is constantly employed.

To illustrate each stage of work, teams working in the same space often use post-it notes or a large whiteboard. In the case of decentralized teams, stage-illustration such as Assembla, ScrumWorks, Rational Team Concert or JIRA in combination with GreenHopper can be used to visualize each team’s user stories, defects and tasks divided into separate phases.
In their simplest, the tasks or usage stories are categorized into the work stages

• Unstarted
• Ongoing
• Completed

If desired, though, the teams can add more stages of work (such as “defined”, “designed”, “tested” or “delivered”). These additional phases can be of assistance if a certain part of the work becomes a bottleneck and the limiting values of the unfinished work cannot be raised. A more specific task division also makes it possible for employees to specialize in a certain phase of work.

There are no set limiting values for unfinished work. Instead, each team has to define them individually by trial and error; a value too small results in workers standing idle for lack of work, whereas values too high tend to accumulate large amounts of unfinished work, which in turn hinders completion times.A rule of thumb worth bearing in mind is that no team member should have more than two simultaneous selected tasks, and that on the other hand not all team members should have two tasks simultaneously.

The major differences between Scrum and Kanban are derived from the fact that, in Scrum, work is divided into sprints that last a certain amount of time, whereas in Kanban the workflow is continuous. This is visible in work stage tables, which in Scrum are emptied after each sprint. In Kanban all tasks are marked on the same table. Scrum focuses on teams with multifaceted know-how, whereas Kanban makes specialized, functional teams possible.

Since Scrum-ban is such a new development model, there is not much reference material. Kanban, on the other hand, has been applied by Microsoft and Corbis.

^{(Courtsey Wikipedia)}

The Pig & Chicken Roles

"Pig" roles

The Pigs are the ones committed to the project in the Scrum process - they are the ones with "their bacon on the line."

§  Product Owner - Represents the voice of the customer. He/she ensures that the Scrum Team works with the "right things" from a business perspective. The Product Owner writes user stories, prioritizes them and then places them in the product backlog.

§  ScrumMaster - Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster's role is to protect the team and keep them focused on the tasks in hand.

§  Team - Have the responsibility to deliver the product. A team is typically made up of 5–9 people with cross-functional skills who do the actual work (designer, developer, tester, technical communicator, etc.).

"Chicken" roles

Chicken roles are not part of the actual Scrum process, but must be taken into account. An important aspect of an Agile approach is the practice of involving users, internal business groups and stakeholders into portions of the process. It is important for these people to be engaged in the outcome of the project by providing feedback into the development, its review and planning for each sprint.

§  Users - The software is being built for the someone. "If software is not used"—much like "the tree falling in a forest" riddle—"was it ever written?"

§  Stakeholders - (customers, vendors) - These are the people who enable the project and for whom the project will produce the agreed-upon benefit[s], which justify its production. They are only directly involved in the process during the sprint reviews.

§  Managers - People who will set up the environment for the product development organizations.

{From Wikipedia, the free encyclopedia}

The Chicken and Pig Story

SCRUM Roles

The Scrum Team consists of the ScrumMaster, the Product Owner, and the Team. Scrum Team members are called “pigs”. The Product Owner is the “pig” of the Product Backlog. The Team is the “pig” of the Sprint work. The ScrumMaster is the “pig” of the Scrum process. Everyone else is a “chicken.” Chickens cannot tell “pigs” how to do their work.

A chicken and a pig are together when the chicken says, "Let's start a Project!"

The pig thinks it over and says, "What would we call this Project?"

The chicken says, “Agent Efficacy!"

The pig says, "No thanks, I'd be committed, but you'd only be involved!"

SCRUM " The Framework"

SCRUM Framework

SCRUM Framework Rules

SCRUM " The Process"

SCRUM "The Process"

"Out of the box". Most projects have a list of requirements, Scrum records requirements in a Product Backlog. Requirements need not be detailed nor do they need to be described fully. As with most projects, the requirements are sourced from the expected users or "the business". The Product Owner prioritizes the Product Backlog: items of importance to the project/business, i.e. those items that add immediate and significant business value, are bubbled up to the top.

The Project Team responsible for doing the actual work then creates a Sprint Backlog: this comprises of Product Backlog items that they believe can be completed within a 15 day period. The Project Team may liaise with the Product Owner and others in order to expand item(s) on the Sprint Backlog. After 15 days have elapsed, the team should have a "potentially shippable product increment". I will discuss the make-up of the Project Team later in this article, under the topic: Scrum Roles.

The Product Owner, the ScrumMaster and the Project Team will make an initial pass over the Product Backlog items where they work out roughly how long each item will take. Initially, these are estimates, best guesses. As time progresses, well within 15 days, we’ll know if the estimate was even close.

Scrum lets us refine our estimates on-the-fly: if we believe that a task will take longer than imagined, we have the ability to say so before the tasks starts. By only ever working with small work packages (time-boxed to 15 days), any schedule/requirement issues are dealt with as soon as they are identified, not much further downstream where the cost of recovery is considerably higher.

What does this "potentially shippable product increment" actually mean? Put simply, every 15 days, the team should provide something of value to the business, something they can use or something that provides considerable direction.

Scrum Basics

Scrum Basics

Scrum revolves around the philosophy of simplicity, resulting in delivery of something that moves the project frontward. It achieves this by offering the following questions (referred to as Scrum’s three questions).

Scrum asks…	Main Project Management issue
What have you done during the last 24 hours?	This is progress, it’s work completed to date
What do you plan to do in the next 24 hours?	This is forward planning, it is work you are about to do
What’s stopping you getting on with the work of the next 24 hours? (Impediments)	These are your impediments or obstructions, it might be things you need in order to work… more forward planning. It’s also identification of immediate risks.

Scrum Roles

• Scrum uses three "roles": Product Owner, ScrumMaster and Project Team.
• The Product Owner is possibly a Product Manager or Project Sponsor
• The ScrumMaster is key, he or she "represents management to the project
• The Project Team should consist of Team members (3-10). The team itself should be self-organizing, cross-functional, involving individuals from a multitude of disciplines: SMEs, Data Analysts etc.

Adaptive Agile in Action – A Case Study

 

Adaptive Agile in Action – A Case Study

Expectations from Team:

• Very basic of Agile is to have development at fast pace
• Handle the 6 months Project road-map in smaller 14 days sprints
• Adapt to frequently changing client requirements
• Client and Project Teams work closer than in any other Project Management Model

Challenges we had in project:

• Requirements were changing on daily basis and this could have affected the whole product so we decided to go for adaptive agile method
• End date to deliver the project was fixed
• Customer wanted to be a part of the Project closely
• Delivering lots of content with in fixed deadline was a challenge

How we handled those challenges:

• Daily SCRUM meetings, Project Road map broken down into Mini Projects or Sprints
• Framework per Sprint ensuring each Sprint should have appropriate “User Stories”
• Client, Product Owner and BA worked closely through meetings, walkthroughs, midpoints and progress reports

Everyone to follow the Daily Stand-up rule of answering three questions:

• What I accomplished yesterday?
• What I will be accomplishing today?
• Any Impediments

(Ground Rule: Daily SCRUM to be wrapped up within 15 minutes)

Key Learning

• Agile gives you the ready work product at the end of every sprint…Client can share the findings and recommendations at any time once a sprint is over and move towards the “BIG PICTURE” of completing the Project Road-map
• It gets easier to Ready to accommodate changes if the Project Teams follows the “Adaptive Agile Methodology”

Collaboration in Agile

How Collaboration is placed with in Agile Manifesto?

One of the methodologies in Agile Manifesto is very effective and famous for promoting “collaboration” and is better known as Daily Scrums AKA Daily Standups.

These meeting are very simple but very effective ensuring teams to communicate effectively. This methodology ensures that the team is committed to deliver short term goals to realize the Business Objective or the “Big Picture”.

There is a proposed format of the Scrum or daily standups where the team discusses 3 vital questions:

• What did you do yesterday?
• What will you do today?
• Are there any impediments in your way?

In a way if we look at the format it covers the Past/Present & Future of the Project ensuring that the team should have a 360 degree view of where they are heading towards

Who all should be involved in the daily Scrums:

• Project Team
• Scrum Master
• Product Owner
• Client

(I will touch upon Scrum Master/Product Owner in my future blogs)

How Daily SCRUM is placed with in the Agile Manifesto (SCRUM)?

Let’s understand what is SCRUM?

Scrum is an iterative process that demands a complete fully functional work product towards the end of the 3 or 4 week long Sprint (Mini Projects usually). Sprints will occur whenever there is still work defined in the Product Backlog (Project Roadmap).

Agile Benefits

Have we ever thought of why most of the projects lose their direction before their completion?

There could be several factors which can hamper the pace and the direction of projects to name a few:

• Indistinct Project Vision
• No framework around requirements gathering
• Inadequate Project Planning
• No or low client collaboration

So, the next logical question which comes to mind is how an ideal Project Plan and Execution should look like?

The best way to answer this question is “Go for Adaptive Agile Methodology”

Now let’s understand how each element with in the Adaptive Agile Model works?

Project Vision – Talks about the road-map and the goals of the project which provides a direction for the project.

Framework – A framework will act a one stop shop where the Project Team and the client can view the Business Objective and the Approach to realize the project vision with the help of well-defined and focused User Stories. (In my next blog I will touch upon user stories and its benefits)

The Plan – It is an integral part of the Framework ensuring that each Mini Project or Sprint (It is usually a part of a release plan, I will touch upon Sprints in my upcoming blogs) is well placed within the Framework to realize the Project Vision.

Let’s Collaborate – This is one of the most important pieces of this Model. So, let’s understand what do we mean by word Scrum?

SCRUM is a movable set of guidelines that oversee the progress of a project, from its plan stages to its completion. It is one of the sought after methodology of Agile manifesto which aims to overcome some common failure points with in a project by promoting:

• Communication in between the Project Teams and the end customer
• Effective Customer Problem solving techniques
• Structured approach to complete a particular task
• What the team learned from their previous sprints in a form of Retrospective Meetings

(Note: This is an Adaptive Agile Methodology and not a pure Agile Method of executing a project)