Implementing SCRUM – Workshop

Implementing SCRUM – Workshop  

About SCRUM

SCRUM appears simple, yet has practices that deeply influence the work experience and that capture key adaptive and agile qualities. Scrum’s distinctive emphasis among the methods is it’s strong promotion of self directed teams, daily team measurement and avoidance of prescriptive processes. SCRUM practices are founded on the Agile principles (see annexure). Some of the key agile practices include;

·         Self directed and self organizing teams

·         No external addition of work to an iteration, once chosen

·         Daily stand up meetings, with special questions

·         30 calendar day iterations

·         Demo to external stakeholders at the end of each iteration

·         For each iteration, client-driven, adaptive planning

The SCRUM process overview

Scrum hangs all of it's practices on an iterative, incremental process skeleton. Scrum's skeleton is shown in the diagram above. The lower circle represents an iteration of development activities that occur, one after another. The output of each iteration is an increment of the product. The upper circle represents the daily inspection that occurs during the iteration, in which the individual team members meet to inspect each other's activities and make appropriate adaptations. Driving the iteration is a list of requirements. This cycle repeats until the project is no longer funded.

The skeleton operates this way: At the start of an iteration, the team reviews what it must do. It then selects what it believes it can turn into an increment of potentially shippable functionality by the end of the iteration. The team is then left alone to make it's best effort for the rest of the iteration. At the end of the iteration, the team presents the increment of functionality it built so that the stakeholders can inspect the functionality and timely adaptations to the project can be made.

Some Organizations using SCRUM

Microsoft, Sun, Sammy Studios, Siemens, Philips, BBC, IBM, SAIC, Ariba, Federal Reserve Bank, HP, Medtronics, Motorola, Valtech, IDX, Primavera, Yahoo, Conchango, Bentley systems, CapitalOne, Federal reserve bank, Clear channel, Xerox, Nokia, Novell

The business case

Organizations using SCRUM methodology have reported productivity gains to the tune of 50% to 100% (on the very conservative side)

The key SCRUM glossary 

Product backlog	All features of the product
Release backlog	A subset of the product backlog, targeted at the next production quality release
Sprint backlog	Tasks for the iteration. Granularity 4-16 hours
Sprint	Iteration of 30 days duration
Daily scrum meeting	Daily stand up meetings
Team introspections	Reflect and improve upon the learnings
The product owner	The product owner is responsible for representing the interests of every one with a stake in the project and it's resulting system.
Teams	The team is responsible for developing functionality
Scrum Master	The Scrum Master is responsible for the scrum process, for teaching scrm to everyone involved in the project, for implementing scrum so that it fits within an organization's culture and still deliver the expected benefits, and for ensuring that every one follows scrum rules and practices

Scrum has defining moments when the concept of a self-organizing team becomes clear.
Scrum and other agile processes have several defining moments when a key participant really "gets it." When these occur, I know that everything is going well and that the expected benefits will result. These flashes of insight include:

1. The customer realizes that it's OK to proceed without all of the requirements being defined.

1. The customer sees a product increment demonstrated at the end of each of the several sprints. He realizes that his involvement was important and had an immediate, tangible result. He also realizes that the project will be successful and deliver something he wants and needs.

1. A team member trusts that someone will help when problems occur. After identifying an impediment or problem during a daily Scrum, either the Scrum Master or a fellow team member provides immediate help.

1. The IT manager senses teamwork in progress after walking through an open area where scrumming is taking place. The buzz, energy and focus are palpable.

1. The project manager realizes that she doesn't have to police the staff.

1. The team realizes that no one is going to tell them what to do.

1. We presented agile concepts and overviewed Scrum and XP.

1. The customer described the business domain.

1. We explained the product backlog, sprint planning and sprints concepts.

1. The team members introduced themselves.

1. The customer and team defined a product backlog (a prioritized requirements list) with enough work to drive the team for several months of sprints.

1. The customer and team brainstormed about how much functionality the team could build in the next sprint.

1. The team defined the sprint backlog (their collective tasks) for the next sprint to turn the selected product backlog into working functionality.

1. We presented daily Scrum, end of sprint, sprint signature and management topics.

1. We explained XP practices and described how they work with Scrum.

1. The project team began the first sprint.

Experiencing Agile  -  Please Read annexure A and B

Our Methodology of implementing SCRUM

The main goal of this program is to ensure effective implementation of the SCRUM methodology, resulting in business advantages.

Since SCRUM is not highly prescriptive, reading and class room training alone will not help for it's effective implementation.  The model we propose, include a two day workshop and 10 days on site support of a Certifed Scrum Master, who will work along with the teams, in implementing SCRUM.

Phase – 1  - Duration 1 day

Session -1 Understanding the SCRUM framework

1.     Adaptive Vs Predictive

2.     When to go agile

3.     Agile manifesto

4.     Key Agile principles

5.     Key agile methodologies overview

6.     Key  SCRUM practices awareness

a)     Product backlog

b)    Release backlog

c)     Wide band Delphi – estimation

d)    Sprint planning & sprint backlogs

e)     Backlog graph

f)     Roles and responsibilities

g)    Daily stand up meetings

h)      Team introspection

     Session -2  - Experiencing SCRUM   - Case study based exercises

1.     Sprint planning meeting  

2.     User stories and story points

3.     Estimate using wide band Delphi

4.     Triangulation

5.     Requirements prioritization

6.     Release planning

7.     Sprint planning

8.     Burn down chart

9.     Stand up meetings

10.  Team self organization based on imposed constraints

Phase – 2

Session-3 – Follow up program (duration 1 day, 30 days after session 2)

The focus of this session is to facilitate right implementation of scrum. This is optional and at the same time, highly recommended if the organization is implementing scrum. All the participants should have attended sessions 1 and 2, and should have at least one SPRINT experience. 

1)      Scrum implementation assessment

2)      Retrospective meeting for the real life scrum implementation done by the participants

3)      Action planning

Professional service charges

For phase 1                               -   Rs. -

For phase 2                               -   Rs. - 

This proposal is valid for a period of one month, from the date of submission

All taxes will be extra

50% of the professional service charges to be given on day one of the assignment

Return flight ticket from Cochin / Bangalore to the location, stay in a decent hotel and Local conveyance extra, for each trip made. Two trips are required if the customer is going for Phase1 and Phase 2.

The program will be delivered at the customer’s place

The participants will be provided with reference material a copy of the slides used during the workshop

All the participants should have at least one project lifecycle experience

We recommend a minimum of 8 participants and a maximum of 20 participants / batch.

Annexure – A

The Agile Principles

1.     Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2.     Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage.

3.     Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.

4.     Business people and developers must work together daily throughout the project.

5.     Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6.     The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7.     Working software is the primary measure of progress.

8.     Agile processes promote sustainable development.

9.     The sponsors, developers and users should be able to maintain a constant pace indefinitely.

10.  Continuous attention to technical excellence and good design enhances agility.

11.  Simplicity – the art of maximizing the amount of work not done- is essential

12.  The best architectures, requirements and designs emerge from self organizing teams.

13.  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts it’s behavior accordingly.

Annexure – B  

Agile Epiphanies

In my experience with agile methods, I've found that hands-on practice quickly leads to cries of "Eureka!"

Some quick definitions are in order:

·         The Scrum Master is a coach who ensures that agile practices are used correctly.

·         The Build Master is a senior engineer who watches for good engineering practices and successful, continuous builds.

·         The Sprint is a 30-day work period that produces an increment of product functionality.

·         The Daily Scrum is a stand-up meeting in which status reports are exchanged, progress is observed, and impediments noted and removed.

·         The Customer is the person paying the bills.

·         The Product Backlog is an emerging, prioritized list of customer requirements.

·         The Sprint Backlog is a list of tasks that the team completes to turn a requirement on the product backlog into a product increment during a sprint.

Getting It

These moments are mini-epiphanies, that flash that occurs when people suddenly understand their roles and how they relate to those of their colleagues. 

I was particularly interested in the fifth epiphany (the project manager understanding his or her new role) and how this realization depends on the sixth epiphany (the team self-organizing and figuring out its work). No matter how many books you read or presentations you attend, these personal insights can arise only from real-life experience.

Finding the Agile "Feel"  - Experience sharing

You can describe how to ride a bike to someone, but he won't really "get it" until he experiences firsthand how to balance while pedaling in motion. Agile processes feel different, and teams need to get that feel—close-up and personal.

The project managers were reluctant to get started, preferring to prolong the discussion. Although they were interested in agile processes, their real-world projects were important and ongoing.

Entering the workshops I used to initiate the projects, these managers were skeptical. They were used to starting projects by doing more, and were now feeling adrift without the detail work they expected to precede the development of a plan. To make matters worse, the project teams were new to the project managers on the XYZ projects—the teams largely consisted of outside contractors.

The workshop flow was:

The project managers for the last two projects turned around at step 6, when the team defines the work for the next sprint. At that moment, they felt as though a burden had been lifted from their shoulders. We started step 6 by reviewing the selected backlog—what the team is thinking about turning into coded, working functionality by the end of the next sprint. We then asked the team to spend the next four hours figuring out how they were going to create this working functionality, including a rough design and the work tasks. Then, we yielded the floor—no one could talk except the team members.

At first there was an uncomfortable silence. The team members were thinking, "We're in a training session—they'll tell us what to do next!" But we didn't. Soon, the pressure of the silence spurred members to offer some initial observations and questions. This quickly escalated, because software developers are usually very opinionated and have lots of ideas. In the normal, top-down project management process, however, they aren't usually asked; they're told! Here, the responsibility of filling the silence served to nudge team members into independent thinking.

The team brainstormed, plotted, schemed and even planned how it would build the code during the sprint. The conversations started slowly, but soon people were working on whiteboards, drawing designs and noodling out the functionality. As the team dialogue progressed, the ScrumMaster wrote down the tasks under discussion. At critical points, the customer or project manager offered observations, made decisions and helped the team focus on the work. We began to recognize the familiar agile "buzz" that indicates that the participants "get it."

After four hours, we called a time-out. The teams had defined their work for the next sprint as well as possible. Some unknowns would have to be worked out, some of the estimates were vague and new work would appear, but the team had gotten a feel for what it would do in the next 30 days.

As the team planned and brainstormed, a light bulb switched on over the project manager's head. Eureka! Suddenly, the project manager experienced agile self-organization! The team would figure out what to do on its own. The manager's traditional role—defining all the work and ensuring its completion—shifted to facilitating, coaching and mentoring, guiding the team to do its best. In this agile task transition, the team takes on a great deal of managerial responsibility—to the project's benefit.

This Is Not a Test

Even if you've read about agile processes, heard about agile processes, and can talk about agile processes, you won't truly understand them until you've experienced agility in progress, close-up and personal; otherwise, it's all academic. When introducing agility into new projects, I try to expedite firsthand experience to engender the agile epiphany: that moment when it all comes together and the process seems self-evident.