Top Ten Organizational Impediments

By Craig Larman and Bas Vodde

When we were writing the "Organization" chapter in Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum we asked a group of agile development experts working in and with large companies about the most challenging impediments their organizations faced. We aggregated their responses into a list of what we call the top ten organizational impediments.

10. Failure to Remove Organizational Impediments

Jeff Sutherland, co-creator of Scrum, considers the failure to remove organizational impediments to be the main obstacle facing large organizations. Common reasons for not removing impediments are "That's the way we've always done business" and "We won't change because we invested so much in this."

9. Misguided Cost Savings and Synergy Efforts

Peter Alfvin, an experienced development manager involved with introducing lean principles at Xerox, and Petri Haapio, head of the agile coaching department at Reaktor Innovations, both mentioned centralized departments looking for cost savings and synergy, leading to local optimization as an impediment. They offered several examples of these misguided efforts. The first was a centralized tool department that required all departments to use the same tool. This well-intentioned savings slowed development efforts for at least one group because the "mandatory tool" didn't fit the job they were doing. Also cited was a time when the so-called furniture police forced all groups to use cubicles in order to standardize and minimize cost. This led to inefficient workplaces for many teams. Another example was the IT department limiting video conferencing to lower network traffic, which hurt teams who depended on that method of communication.

8. Lack of Training

Sami Lilja, global coordinator of agile development activities at Nokia Siemens Networks, noticed that some organizations seem to consider learning a waste of time and money. Those organizations tend to educate and coach people only "when there is time for it." This distorted view results in a vicious fire-fighting cycle—mistakes made because of constricted developer skills, followed by hasty emergency repairs and a management team unwilling to allot time to analyze the causes of the mistakes, then more mistakes made.

7. Single-Function Groups

Larry Cai, a specialist at Ericsson Shanghai, mentions functional organizations (single-function groups) as one of the largest impediments to becoming agile. These single function groups create barriers for communication and abet finger-pointing among units.

6. Local vs Global Optimization

Esther Derby, consultant, coach, expert facilitator, and author of two books related to organizational learning, considers systems that foster local optimization over global optimization a major barrier to success. She gave several examples of these systems, including management by objectives(MBO)and budgeting systems.

5. Assumption that Book Learning is Enough

Mike Bria, a former agile coach at Siemens Medical Systems, mentioned what he called "do-it-yourself home improvement" as an impediment. He said that many people mistakenly believe that they "know how now" after reading one or two books, proving the truism that a little knowledge is a dangerous thing. These organizations usually do not bring in outside expertise, electing instead to do it themselves. Lasse Koskela, the author of Test-Driven, mentions a similar impediment, what he calls an "unwillingness to look outside the organization."

4. Individual Performance Evaluation and Reward

A trainer (name removed on request) at one of the largest e-commerce sites, mentioned individual performance evaluation and reward as a major obstacle he had noticed. These archaic practices frustrate developers and managers on agile teams, hinder team performance, and foster command-and-control management.

3. Unrealistic Promises

Lü Yi, an agile trainer and department manager of a large development group in Nokia Siemens Networks in Hangzhou, considers "commitment games" and unrealistic promises to be a leading organizational obstacle. Unrealistic expectations lead to shortcuts, continuous fire fighting, and legacy code. We cover this topic in more detail in the "Legacy Code" chapter of the companion book, Practices for Scaling Lean & Agile Development.

2. Assuming Agile Is All About Developers

Diana Larsen, expert facilitator and, together with Esther Derby, author of Agile Retrospectives cited this impediment, "Assuming it's all about developers." Too often, organizations mistakenly assume that agile and lean involves only developers. They don't understand that a successful move to agile requires a shift in thinking and behavior at multiple levels of the organization.

1. Silver bullet thinking and superficial adoption

Almost everybody we interviewed cited some version of silver bullet thinking and superficial adoption as an impediment. Dave Thomas, founder of OTI, large-scale lean product development consultant, and managing director of ObjectMentor, spoke eloquently about this problem. He said that many companies make the mistake of equating agility with productivity, rather than with adaptability. This, coupled with a lack of educated executives, leads to the mistaken notion that agility is some kind of silver bullet. This, in turn, fosters the belief that meaningful problems can be solved by saying "we do agile" and going through the motions of doing so, with no deep understanding or change by the leadership team. Ironically, because this behavior leads to no real change and no real result, these same organizations eventually abandon lean/agile principles because they "don't work."

A related impediment is the wishful thinking that significant improvement in large product groups can and will happen fast, within only a few years. In reality, significant improvement in large organizations can take five or ten years—if there is sustained executive support.

Our Two Cents Worth

After publishing this top ten list, we decided to add our own personal favorite organizational impediments to the list. The first impediment we have uncovered is a culture of individual workers rather than real teams and teamwork. Too many groups of individuals disguised as teams are ostensibly adopting Scrum, yet they still have the mindset of "Jill does Jill's tasks, Raj does Raj's tasks and so forth." These organization have yet to move as a whole team together, pairing and multi-learning within the group.

The second impediment we see is the gap between people in management roles and those doing the hands-on work. Frequently, changes made at the management level have no impact (or at least, no positive impact) whatsoever on the actual work. Similarly, decisions by hands-on developers are often not aligned with the direction of the organization. This gap is caused by managers who do not go and see the real place of work—sometimes because they have lost the skill to do so—and by developers who do not think outside their normal job responsibilities—they are "retired on the job." The gap leads to shallow agile and lean adoptions that happen either only on the management level—without any change in technical practices—or only on the development level—without any change in the organization. The lean practices of go and see and managers-as-teachers help to reduce this gap.

The replies from the agile development experts validated our own experience and acknowledged that we were covering the right topics. The remainder of the "Organization" chapter in the book explores these organizational obstacles and what you can do about them.

9 Tips for Creating a Good Sprint Backlog

By Luciano Félix

The sprint backlog is a simple list of the tasks that must executed by the team in order to deliver an increment of functional software at the end of that sprint. Sprint backlog creation happens in the second part of the sprint planning meeting with the participation of every team member. Giving some real attention to this process is fundamental to a better understanding by the team about what should be done and to better planning during the sprint. Despite this, many teams still struggle with this activity. I hope these tips will help.

1. Involve every team member in the process. It can’t be said enough: the involvement of every team member in the process of sprint backlog discovery is essential. On a multi-disciplinary team, everyone can contribute to task creation, enabling the team to draw from several different perspectives about the story. This generates a much richer Sprint Backlog than if only coders or a technical guru were involved.
2. Discuss how every item should be implemented. Before any tasks are written on post-its it's necessary for the team to spend some time discussing every story that will be brought into the sprint. In fact, the majority of the meeting should be dedicated to understanding how the team is going to tackle the stories. This discussion will involve creating basic designs, checking existing code, discussing architectural possibilities, and so on. Having a shared understanding about the story and the possible solutions will enable the team to create a task list that truly expresses the work to be done.
3. Have a definition of done. Having a common definition of done in place, available and visible to everyone is extremely important. This definition will serve as a guide to what should be done and will remind the team what the general acceptance criteria are for every item in the backlog.
4. Identify all kinds of tasks. Too many teams focus on coding tasks. The truth is, though, that coding is not enough to deliver real working software. The sprint backlog should include every kind of task: object modeling, coding, learning a new technology, database activities, tests, and so on. Having a posted definition of done will help to remind teams of the tasks they are forgetting. By listing every aspect of delivering working software and going through those tasks, the team will gain a new understanding of the real effort the next sprint will require.
5. Don't estimate tasks at all. This is a sensitive one. Estimating tasks in hours is popular and may be necessary when a team if first starting out. In the end, though, we can drop this without losing much. (See Alan Atlas’ article about this topic) The team commitment to the sprint should be done with the backlog items in mind, not the tasks. After all, if we estimate that a task will take 4 hours but it actually takes 12 hours, as long as the team achieves the sprint goal, what difference does it make? Identifying as many tasks as possible and creating a sense of constant progress during the sprint should be enough.
6. Don't assign tasks up front. Resist the temptation to direct work; the team should decide who is going to do what according to the circumstances. If you start to assign tasks to the “most suitable” team member, it will prevent the rest of the team from learning new things, block communication, and decrease collaboration. Empower and trust the team to manage themselves.
7. Review the sprint commitment. After task identification, when the team has a much better understanding about the real effort that is needed, the sprint commitment should be reanalyzed. Does the selected sprint backlog really fit in the sprint? If not, there are some alternatives. Drop the item with the lowest priority or split stories into smaller pieces. What matters in the end is that the team can commit to something they have a good understanding about.
8. Don't use too much time. Respect the time box. Define a meeting duration and stick to it. Timeboxing forces the team to concentrate and intensively discuss the items, making it much more likely that the tasks will be uncovered. The team cannot always identify everything that should be done during the sprint, but that's not a problem. It is much more important for them to gain a thorough understanding of the stories they are bringing into the sprint.
9. Evolve the Sprint Backlog during the sprint. The team will understand more about the stories as they work on them. New ideas may arise and old ideas may be dropped. The Sprint Backlog should reflect these changes. The Daily Scrum is an excellent time to create new tasks and lose unnecessary ones.

If the team invests the time and effort to build a good sprint backlog it will be rewarded with a much better overall understanding of the work to be done, a sense of progress on a daily basis, and a clear commitment to what will be delivered. It may not be easy, but it will be worth all the hard work.

Explaining the Sprint Budget Chart

The Sprint Budget Chart maps how a team consumes its budget over the length of the sprint relative to the planned budget consumption calculated by ScrumEdge. This chart is based on three variables, the Planned Budget, Budget Used and Actual Completed.

Planned Budget

Once sprint planning is complete and tasks have been assigned to Team Members, ScrumEdge calculates the Planned Budget by assigning a percentage value to each day of the sprint.

Planned Budget:

Planned Budget = Previous Day’s Planned Budget + (100 / Total Days in Sprint)

Example: If a team is working on a 10 day sprint their Planned Budget value will be calculated as follows:

Day 1: 0% + (100 / 10) = 10%

Day 2: 10% + (100 / 10) = 20%

Day 3: 20% + (100 / 10) = 30%

…

Day 10: 90% + (100 / 10) = 100%

Budget Used

The Budget Used line shows what percentage of the the planned budget a team member has used. It is calculated every day by dividing the total number of hours burnt till that day by the total number of hours estimated in the sprint.

Budget Used (Whole Team):

Budget Used = (Total Team Hours Burnt till this Day/ Total Team Hours Estimated in Sprint) * 100

Budget Used (Team Member):

Budget Used = (Total Member Hours Burnt till this Day / Total Member Hours Estimated in Sprint) * 100

Example: If a 2 team plans a sprint where their total task estimates are 100 and burns a total of 12 hours on the first day, and 15 hours on the second day their Budget Used for the first two days will be as follows:

Day 1: (12 / 100) * 100 = 12%

Day 2: (27 / 100) * 100 = 27%

Actual Completed

The Actual Completed line shows the percentage of actual work that is completed in the sprint and is calculated only when a task is completed. The Actual Completed is calculated by dividing the total estimates for completed tasks by the total number of hours that are estimated in the sprint.

Actual Completed (Whole Team):

Actual Completed = (Total Task Estimates for Completed Tasks/ Total Hours Estimated in Sprint) * 100

Actual Completed (Team Member):

Actual Completed = (Total Task Estimates for Completed Tasks for Member/ Total Member Hours Estimated in Sprint) * 100

Example: A team plans a 100 hour, 10 day sprint. 1 task with estimates equaling 7 hours is completed on Day 2 and another with estimates equaling 3 hours on Day 3. On Day 4 a task with estimates equaling 12 hours is complete. The Actual Burn for this sprint would be calculated as follows:

Day 1: (0 / 100) * 100 = 0%

Day 2: (7 / 100) * 100 = 7%

Day 3: (10 / 100) * 100 = 10%

Day 4: (22 / 100) * 100 = 22%

Analyzing the Budget Chart

If used properly the Budget Chart can be a powerful tool. During the course of a sprint, the ScrumMaster can use the Budget Chart to see how much of the plan budget their team uses every day and how much actual work is completed based against the team’s budget consumption.

If the Budget Used line goes over the Planned Budget line, the ScrumMaster should immediately recognize that the team is taking longer to complete tasks than they had estimated. However, this does not mean that the sprint is headed for disaster. It is normal for team members to go over their estimates from time to time. A good ScrumMaster should investigate further to see if this could actually a problem later on in the sprint.

The Actual Completed line is an important indicator of how much work is actually being completed through the sprint. There may be a case that the Budget Used and Planned Budget lines match up perfectly but the Actual Completed line hovers at 0%. This would indicate that the team is using up the time they had planned to spend on tasks, but not actually completing any tasks. It is normal for the Actual Completed line to hover close 0% at the start of the sprint and pick up as the sprint moves forward and tasks are completed.

It is important for ScrumMasters to understand these trends and facilitate the team members in completing committed tasks.

Explaining Sprint Burn Rate Charts

 
The Sprint Burn Rate chart maps the average number of hours a Scrum team burns over the length of the sprint relative to the required burn rate calculated by ScrumEdge. This chart is based on two variables, The Ideal Burn and the Team’s Burn.

Ideal Burn

Once sprint planning is complete and tasks have been assigned to Team Members, ScrumEdge calculates the Sprint’s Ideal Burn rate by adding up the total number of hours required to complete all tasks in the sprint and dividing these over the length of the sprint to get the average number of hours the team should be burning each day to complete their tasks.

Ideal Burn: (Whole Team)

Ideal Burn Rate = (Total Sprint Hours / Number of Days in Sprint) / Total Team Members

Ideal Burn: (Single Team Member)

Total Sprint Hours Assigned to Team Member / Number of Days in Sprint

Example: If a 2 man team plans a 10 day sprint and their total tasks estimates are 100 hours their Ideal Burn Rate would be as follows:

(100 / 10) / 2 = 5

The ideal burn rate stays constant through the course of the sprint.

Team’s Burn

The Team’s Burn is the average number of hours the team burns every day.

Team’s Burn: (Whole Team)

Team’s Burn = (Total Hours Burnt By Team / Number of Days) / Number of Team Members

Team’s Burn: (Single Team Member)

Team’s Burn = Total Hours Burnt By Team Member / Number of Days

Example: If a 2 member team was to burn 10 hours on Day 1, 15 hours on Day 2 and 20 hours on Day 3, their Burn Rates would be as follows:

Day 1: (10 / 1) / 2 = 5

Day 2: (25 / 2) / 2 = 6.25

Day 3: (45 / 3) / 2 = 7.5

The Team’s Burn Rate changes from day to day.

Ideal Burn vs. Team Burn

The Team’s Burn when mapped against the Ideal Burn should give the ScrumMaster an idea of how many hours their team is burning every day. The Ideal Burn tells the ScrumMaster how many hours the team committed to burn every day through to course of the sprint. On the other hand the Team’s Burn tells the ScrumMaster how many hours their team is burning every day.

It’s important to keep in mind that the Sprint Burn Rate Chart does not help predict the success of a sprint. A Scrum team may be working at ideal burn levels and still not complete tasks because of incorrect estimation. However, this chart does give the ScrumMaster an idea of  how much time each team member is spending working on a sprint everyday. If a member’s burn rate is well below the Ideal Burn this chart should help the ScrumMaster raise a red flag and investigate the matter.

Similarly if the Ideal Burn at the start of the sprint is higher than the team’s overall velocity, the ScrumMaster should note that the team may have overcommitted. At this point it would be a good idea to regroup with the team and if need be, revise their sprint plan.

Strategist: A New Role for Scrum Organizations?

By Srinivas Suravarapu

One vague area in Scrum is vision and strategy. Most discussions about Scrum fall within the boundaries of daily scrums and release plans. What is needed is more understanding of how Scrum and a company’s vision work together. To help senior management comprehend the limitations of Scrum and to help Scrum teams visualize the big picture, each organization that wants to implement Scrum needs a strategist –someone responsible for creating a level playing field where all stakeholders and participating parties in business can contribute and add more value. The strategist’s role should be to evaluate ever-changing market trends, sales, and the organization as a whole to make sure that what engineering builds is not just feasible but valuable.

Value, in this case, is not about metrics. Value is the perceived financial gain or goodwill that a product or innovation will create. Potential sales or new business are often used as measures of this value. It is important that a strategist be able to research this kind of data and have it available before taking up a project for implementation. Feasibility is equally important in determining value. Market opportunities must be balanced against organizational capabilities. Too often companies enter markets where they do not have sufficient capabilities to compete effectively. The strategist’s job is to act as ScrumMaster of the organization, recognizing the market opportunity but evaluating it against existing capabilities, not just of the engineering team but of the entire organization.

Scrum will help a team deliver a quality product but a Scrum team, in the end, can only deliver what it was asked to create. If what was asked for is too expensive given the current capabilities or not appropriate for the existing market, the company ultimately won’t receive the value for its investment. This isn’t the fault of the Scrum framework. It’s a function of garbage in, garbage out. A strategist is essential in a Scrum organization to ensure that the needs of the market are balanced against the capabilities of the organization.

You may wonder, isn’t this the product owner’s job? I don’t think so. Not only does the product owner have enough on his plate already, he is usually not in a high-enough position to be able to see the whole picture. The strategist must be someone in the organization who has a global view and a data analysis background: a traditional strategist or senior management executive. Below are several reasons why I recommend a strategist in addition to a product owner.

• The product owner is more intrinsically oriented to the development of the product. The product owner usually comes from a business analyst or project manager background. Taking on the strategist role would require that the product owner spend too much time away from the team.
• A traditional strategist operates agnostic to the technicalities of a product and bases her job around market trends. A strategist’s strengths are non-project-management areas such as market research and trend analysis.
• A strategist has the unique ability to translate market needs into terms of financial gain for the senior management team and into terms of engineering work for development. These two components create a road map for organizational prosperity.
• A strategist acts as a liaison between senior management and the product owner to streamline communication and help both parties make well-informed decisions.

Overall the strategist should enhance the value added by Scrum. Having a strategist ensures that what senior management envisions and what the engineering team paints are in harmony not only with each other but with the market as a whole.

Unlearn What You Have Learned: Ten Habits You Must Break To Be Successful with Scrum

By Nimesh Soni

In the Star Wars movie The Empire Strikes Back, Luke tries unsuccessfully to rescue his X-wing fighter from the swamp. After some time, he gives up. He tells Jedi Master Yoda that lifting the fighter is impossible with the force, the new approach Yoda is trying to teach him. Yoda has these words of wisdom for him:
“You must unlearn what you have learned.”
Scrum is no different! Like the Jedi force, the Scrum framework is conceptually easy; it’s putting Scrum into practice that is difficult. In order for a team to be successful, the team members must unlearn what they have learned so far in their careers.
Here are nine habits you must break in order to be truly successful with Scrum.

Habit One: Create email trails

Often, on traditional projects (i.e., waterfall), team members create trails—written proof to cover themselves. Scrum, like all agile methodologies, values communication and collaboration among team members. Individuals are encouraged to pair with other team members, discuss the story or task at hand, and drive it to completion (and not worry about getting it in writing). Team members must unlearn the mentality of creating a trail and learn to trust and depend on their teammates.

Habit Two: Use command and control

In traditional project management, the project manager uses a command and control approach to steer her project in a certain direction. She generally is responsible for the success or failure of the project. On Scrum projects, team members must learn to take collective ownership of the project. In turn, the project manager has to learn to facilitate and empower rather than dictate and drive.

Habit Three: Create disciplines and silos

On traditional projects, each team member is assigned certain tasks and is responsible for completing theses tasks. Generally, the tasks assigned are discipline-specific, focused on the primary skills of each team member. A systems analyst, for example, will be assigned only the tasks that relate to requirements gathering. This creates silos and requires hand-offs.

On a Scrum team, each member has to unlearn the tendency to specialize and instead should use pair programming and role sharing to expand his or her understanding. No more staying in your own lane. Scrum team members are encouraged to venture into others' lanes.

Habit Four: Be a hero

Our traditional work environment promotes heroism. An individual team member is applauded for her achievements on a project. This often encourages individuals to look after themselves. This behavior must be unlearned by the team members on a Scrum project. On Scrum teams, there are no heroes! For the greater good of the project, the team members must be willing to work with each other to drive the stories to completion. The team, as one unit, is responsible for success or failure of the project and must take the collective ownership of the project.

Habit Five: Sign off on a detailed requirements document

It is difficult for management to accept the fact that you can work on a project that has a fluid top line or scope. This is the most difficult trait to unlearn. On Scrum teams, we adjust the top line of the project at the end of every sprint. With each sprint, the team gets better, smarter, and learns more about the project and the environment. Based on what the team learns, the team adjusts the top line of the project.

Habit Six: Stick to the iron triangle

The traditional approach to project management refers to scope, schedule, and cost as the iron triangle. This iron triangle, though, is broken because it does not take into consideration the quality of the project deliverables. The requirements and priorities of the customers might change as they see more working software.  The management must unlearn the urge to box customers into committing to a pre-defined and well-documented set of requirements. Instead, Scrum teams should emphasize the quality of the product that the team creates through various levels of testing and inspections to achieve a done state. The team must learn to focus on quality and make it a central requirement of its work and deliverables.

Habit Seven: Be plan driven

The world is not standing still, so why should your project plan be written in stone? Traditional project management is very stubborn about setting the project plan and sticking to it no matter what. Project Managers spend many hours trying to come up with a perfect plan; the truth is, no project plan is ever going to be perfect. It might be perfect for the moment; however, the world is changing constantly. Your customer’s requirements and priorities will change, the work environment for the team will change—the plan must change in response. Management must learn to accept the truth of change, and allow teams to respond and adjust accordingly.

Habit Eight: Be IT driven

How many times (in your career) have you come across a situation where the IT management is driving the projects? Where IT is dictating what it can and can not do for the business? In Scrum, IT must learn to play a supporting role. The business must drive the projects (priorities, scope, what gets delivered and when—all to increase the ROI). IT should work with the Business to deliver the required artifacts. The Product Owner, thus, is the single most important factor for the success or failure of an agile project.

Habit Nine: Have a big bang delivery

With waterfall projects, you typically get a single, big-bang delivery, where the finished product is delivered to customers at the end of the project. The big misconception with the traditional waterfall approach is that any complexity can be effectively dealt with in a "big-bang" approach.
Scrum emphasizes the delivery of the product in an iterative manner. On a Scrum project, the team must learn evolutionary (and iterative) delivery of the product. With each delivery, the team learns from the customer’s feedback and communication of changed priorities. What the team learns is applied toward making subsequent deliveries better, delivering value to the customers, and in turn to the business.

Habit Ten: Tell teams “How,” not “What”

Management has learned to dictate how the team should complete the tasks at hand. In Scrum, management must unlearn this urge to tell the troops how to execute the tasks. Instead, they must learn to provide the priorities, and then trust the teams collective instinct and experience to complete the tasks. Let the troops on the front line (the folks who are actually going to work on the tasks) decide how to execute and get things done within the boundaries established by management.

Scrum is a simple framework, but executing it properly is not easy. You must unlearn certain long-held beliefs to be successful, and as we all know, breaking habits is never easy. Keep in mind the words of Jedi Master Obi-Wan Kenobi to Luke Skywalker: “Luke… Let go. Trust the force.”

Scrum, Virtually: Applying Scrum in a Global Delivery Model

By Jerry Buchana and Srikant Chellappa

Scrum has long been touted as an agile methodology that delivers results in an application development project. The methodology includes short iterative cycles called Sprints, typically 3-4 weeks. During each sprint, the team creates a version of user-ready software. The set of features that go into each sprint comes from the product backlog, which is a prioritized set of work to be done. Which items go into the sprint is determined during the sprint planning meeting held at the beginning of each sprint. During this meeting the Product Owner informs the team of the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint. This cycle can keep repeating itself until a product has met its release requirements or release date. The key factor is that the product is user ready at the end of any sprint (while it may not have all the features) and that the features that have been developed are the most important features. The teams who deliver this work are self-organizing. Scrum is intended to work best for collocated teams working in a team room with no walls and rolling desks so the teams can self arrange their working settings.

Global Delivery Model: Reality for a Flat World

Application development lifecycles have taken a new twist in a flat world. Rapid advances in communication and technology have led to teams collaborating in a global setting to deliver products in shorter timeframes, with better quality, and at a lower cost. This trend started with manufacturing, where companies like GM and Boeing built their products by sourcing parts from several different manufacturers around the globe in an effort to maximize cost, quality, and time, and then assembled them at their locations. This global delivery model found its way to application development in the early 90s, as the cost and quality of communication improved by magnitudes. In a global delivery model, teams are distributed geographically into separate groups within the application development teams. For example, the business analysis team may be placed near the users to have better interactions and fully understand the context of the business process while the core group of developers may be situated in an offshore location such as India or Russia.

Adapting Scrum for a Global Delivery Model

Scrum-based project delivery in a global or a distributed delivery model requires some creative modifications to the Scrum methodology set forth by Ken Schwaber. At eMids, we have adapted Scrum, adding some Rational Unified Process and PMI project management principles, to best support our global delivery team. Despite being distributed we communicate often. We call our daily standup Scrum Calls. Scrum Calls take place early in the morning via phone. Both the onsite teams and offshore teams participate. Our onsite business analysts and the offshore teams collaborate frequently on requirements, progressively elaborating them twice a week via phone. These meetings can be made more frequent as necessary but are not substitutes for the Scrum Calls.

This collaboration doesn’t stop with our delivery teams. We work closely with stakeholders during the entire process. The progress and the features delivered are made highly visible, and are developed collaboratively whenever possible. As a result, there is stakeholder buy in during the whole process. After all, the best way to validate software is to actually put it in the user’s hands!

We have augmented Scrum’s project metrics with metrics from Rational Unified Process (RUP) and Project Management Institute (PMI), including earned value analysis, resource utilization, and estimate-to–complete. We have also incorporated key PMI knowledge area tracking for issues, risks, and statuses. We share our consistent and measureable progress on a daily and weekly basis. This helps alleviate stakeholder concerns and facilitates their buy in.
As we prioritize our product backlog, we keep the RUP principle “do the most architecturally significant features first” in mind. This allows the risks to be taken head on without compromising the features later in the development cycle. We also have a consistent definition of done. When we say we deliver working software, we mean that the software delivered in each sprint must have gone through QA either offshore or onsite before being released to the customer.

We avoid project handoff by running multiple scrum teams in parallel. Each team has a ScrumMaster. The teams’ ScrumMasters report to a project-wide ScrumMaster for a Scrum of Scrums. Having multi-threaded teams avoids the serial delivery of functionality (mini-waterfall) and accelerates delivery timelines.

Above all, we strive for flexibility within the structure of a well-defined process. The key aspect to our blended methodology is that it should never be a stringent process where the users are frustrated with the inflexibility. No onerous change management is involved. There is a fundamental belief that requirements and the feature priorities can change but the onus is on the product manager to ensure that the impact of the change is communicated to the sponsors so that they fully understand the true cost of altering their requirements or priorities.

Scrum, Virtually

At eMids, we believe that Scrum can be adapted to work seamlessly with, and actually improve performance inside, the global delivery model. The best practices we use each day have resulted in a vast improvement in end-user satisfaction and a rapid product development lifecycle that has not only advanced the budgetary benefits of the global delivery model but also has resulted in higher quality and a more usable product.