Scrum and Group Dynamics

By Jörgen Fors

Given that Scrum has a very pragmatic view of getting things done and a strong focus on teamwork, how do the psychological aspects of group dynamics affect the likelihood that Scrum will succeed? Two interesting theories on the subject, FIRO and RAT, have implications for Scrum, yet I have not seen them referred to in any Scrum or agile material. Understanding these theories and their implications can affect whether a Scrum team succeeds or struggles.

FIRO

The theory of Fundamental Interpersonal Relationship Orientation, FIRO, was put forth by psychologist Will Schutz in 1958. He developed this theory during the Korea conflict, when he was assigned the task of explaining why teams with equal training and tasks achieved quite different results. Schutz found that team performance was directly related to the way team members interact and communicate.

FIRO divides the life of a team into three phases: Inclusion, Control, and Affection. Each of these phases measures how much interaction the individual team members desire in the areas of socializing, leadership, and responsibilities (and more intimate personal relations as well).

Inclusion describes an immature team, where individuals are focused on belonging or not belonging to the team. Individuals on an immature team are very polite as they attempt to orient among the other team members, achieve acceptance for themselves, and decide whether to accept others. The motivating need of the individuals is to feel important enough to be allowed to be a part of the team.

Control describes a team where individuals are focused on determining their relative position on the team. Individuals often have a confrontational or guardian behavior towards the rest of the team as they measure their own position in the group as opposed to the other team members. The motivating need of the individuals is to feel competent enough to be able to influence the team.
Affection describes the relations of a mature team, whose individuals focus on how close or far away from other team members they want to be. Team members in the Affection phase act openly and transparently towards each other and share both thoughts and feelings. The motivating need of the individuals is to feel loved and liked enough by the others.

Teams will become fully efficient in solving whatever task they have to do only when they have reached the affection phase. The task of the team leader (ScrumMaster), then, is to guide the team into Affection as quickly and efficiently as possible.

RAT

Elias Porter’s Relationship Awareness Theory (RAT) holds that all people want to have relationships with other people. From birth, human infants seek positive connections with their caregivers. Interaction and relationships with others give our world meaning. Therefore, our behaviors are expressions of our innate desire to be connected with others. RAT looks at how we behave to establish and maintain these relationships so that we have a positive sense of ourselves and our value as people.

1. Behaviors are tools used to get some result or confirm our sense of self-worth. Behaviors are also used to ward off things we do not want.
2. Motives come from our wish to feel a strong sense of self worth or self value.
3. Our individual Motivational Value System is consistent throughout our life and underpins all of our behaviors.
   Individual needs (and the resulting behavior) can change, depending on whether a person is stressed or not. So, a person’s behavior is predictable when calm and likewise predictable when under stress. However, calm behavior does not affect the stressed behavior. For example, a person can be friendly and helpful when calm, only to become controlling when under stress.

RAT divides individual behavior into three main types, all of which reside to some extent within an individual: Unselfish and caring (UC), Sure and controlling (SC), Analytic and independent (AI). In between these types are mixed behaviors.

All of the behaviors can be strengths of an individual and assets to the team, unless exaggerated. When the behaviors are exhibited to the extreme, they will be perceived by others as weaknesses of the individual. A common source of conflicts is when individuals of different behavioral types try to evaluate and judge each other. For instance UC and SC types of persons might experience the AI type as uncaring and uninterested.

FIRO in the Scrum environment

Now, let’s examine how these two theories affect the Scrum environment and see if we can use the information to find even more efficient ways of performing Scrum.

When we form a Scrum team and physically locate the individuals together, we create an undisturbed environment where the team is allowed to travel through the phases of FIRO. Scrum also sets a framework for how this journey is to take place by introducing a number of routines. During the inclusion phase, this framework allows new members to feel welcome and have some stability in an otherwise new world, where they are figuring out their roles.

The good news is that being located together and having routines lets Scrum teams make a fast transition to the Control phase. The bad news is that, once teams reach this phase, Scrum offers little help on how to get through this phase and become an effective team. On the contrary! Scrum explicitly states that the team shall be “self-organizing,” a directive which places a huge demand on the leadership skills of the ScrumMaster. One thing Scrum does provide, however, is some pressure regarding what is expected by the team (the sprint backlog) and during which timeframe it is supposed to happen (the length of the sprint). From a psychological point-of-view, the daily scrums and close cooperation enhance team spirit and enforce the bonds of the team. Forcing the team to focus on the task at hand also helps move the team into affection. At the same time, however, the pressure acts as a filter, where the weaker team members run the risk of being forced off of the team. Realize, too, that until an unfit member officially is lifted out, the team as a whole can not progress from Inclusion into the later phases.

While new Scrum teams will most likely perform better than teams using traditional development methods, no truly remarkable results can be expected by any team until they reach the Affection state. This is a good reason not to change the team between sprints, as every change in the team composition inevitably will throw the team back to the Inclusion phase. A strong team well into Affection will recuperate quite quickly, while newer teams might take considerable time to rebound, if in fact they ever do.

RAT in the Scrum Environment

RAT has different implications for the Scrum team. Just as different behavioral types apply different styles when acting as leaders, they also require different styles to be led.

A new group needs external stability and assurance. The team as a whole will have a need for a firm and self-assured leader—an authoritarian or, in RAT terms, someone with strong “Sure and Controlling” behaviors (SC). However, as the team passes into the Control phase, they no longer need this style of leadership. Since FIRO tells us that most of the group’s energy in this phase is spent finding internal team rankings, an SC-style of leadership will be seen as a direct challenge for rank, leading to confrontations. A better leadership style for teams in this phase is an Analytic and Independent (AI) leader, one who is skilled at “trickery.”

Once Affection achieved, the AI style will become obsolete. Any “trickery” that worked before to get the team to perform will be immediately seen through and ignored by this more mature team. Fortunately, the Unselfish Caring (UC) type of leadership is very well suited for leading a team that has reached this phase. This leadership style is also very much in line with the Scrum view of the ScrumMaster as “a remover of impediments,” i.e. both an authority and a servant to the team.

Based on this information, both FIRO and RAT theories suggest that selecting the right ScrumMaster is crucial to a team’s success. Not only must the ScrumMaster be well versed in the Scrum methodology, he or she must also be able to adopt different leadership styles, based on the current maturity of the team. Without a talented ScrumMaster to guide new teams through the early stages of their Scrum adoption, they may never move past the inclusion phase to one where they are truly productive. A good ScrumMaster serves as a catalyst for the team’s bonding process.

If your team is not performing as expected with Scrum, start looking at your own leadership style and ask yourself what can be done to help the team move into Affection. Keep teams intact or, if replacements are necessary, make them swiftly. Finally, be sure to appoint scrummasters that are able to use different leadership styles, depending on the situation at hand and the current needs of the team!

References

Schutz, W.C. (1958). FIRO: A Three Dimensional Theory of Interpersonal Behavior. New York: Holt, Rinehart, & Winston
Personal strengths publishing, 2007

Why switch a failing waterfall project over to agile?

By Anthony Heath

Many people assume that only new projects should switch to Agile. That’s not necessarily true. Switching a failing waterfall project can inject new life into a project, giving it a chance for success.  Moving to agile has both long-term and short-term benefits. 

Long-term benefits

Long-term benefits include increased project awareness for new team members, restored confidence in the original project concept, and the inclusion of clear and present business critical design requirements that were not evident at the project inception and thus fell out of scope.

While waterfall projects fail for many reasons, there is a direct correlation between failed projects and overall project timescale. Part of the reason for this is that long projects often see a fair level of staff turnover. New team members may not understand the original project or may have never been fully integrated when coming onboard. After a certain period of time, even the original team members have difficulty maintaining a clear view of project goals, no matter how well they were articulated at the onset of the project. Switching a failing project from a waterfall-based form of project management to agile methods gives organizations the opportunity to review project goals, analyze past performance, and refresh the project team’s understanding.

Short-term Benefits

There are clear short-term benefits in switching to agile.  As costs rise and no deliverables are produced, failing projects often fall under the critical eye of top-level management.  A switch to agile allows a project to start producing recognizable results in the short term.  This will help to raise the falling opinion and remind the organization of the initial perceived value of the project.

A switch to agile is especially beneficial when a project is struggling to pass the test and review stage. The agile method is especially suitable in this situation as it inherently promotes quick turnaround, fast response, and instant solutions.

For a project with an out-of-control budget, switching to agile will allow for tighter financial control across the much smaller agile iterations. When planning a far-reaching waterfall project, budget is often calculated incorrectly, as it is almost impossible to foresee every possible future problem. Agile, on the other hand, allows for shorter budgeting periods, clearer indication of future budget requirements and tighter controls on overspending.

Conclusion

Waterfall projects often bog down when plans don’t match reality. Switching these failing projects over to agile can yield both immediate benefits and long-term improvements. The implementation of the agile methodology, including its iterative approach to software development, allows a failing project team to quickly revisit and redevelop problem project areas as needed.  This single benefit alone is often enough to save the project, as results no matter how small are deemed preferable to no results at all.

Success Factors for Scrum Implementation

By A. Narasimhan

My company recently implemented Scrum on a large team developing an enterprise product. Three factors were responsible for our success: customer ownership, management commitment, and the cooperation of the development team.

Customer ownership

Our development was an internal initiative. We had a US-based business unit that was the sponsor and the direct customer for the product. We also had an Indian development arm. The end users were also involved with development in some cases. The enterprise product was targeted at hospitals worldwide.

The directive to use Scrum actually came from the US-based business unit (the sponsor and direct customer for the development unit.) This turned out to be a tremendous advantage. After all, one of the major components of Scrum is customer involvement; if the customer is not fully involved it is difficult for them to fully own the product features and prioritize and review the backlog every increment. Even when the customer is committed, some of them are not fully aware of how release management happens in Scrum. This was definitely not the case for us. Our customers not only understood Scrum, they were the first to get educated about Scrum and spread its use to the development team. Having customers that are well-informed Scrum proponents was instrumental in our success.

Management commitment

The second key to our success was the complete commitment of the Indian management to the Scrum process. Not only did they have a basic understanding of Scrum, the also clearly saw the need for proper infrastructure, training, and tools. Their commitment made it easy for the development teams to properly implement Scrum. 

Development cooperation

It often is relatively easy for a small team (ten to fifteen members) to successfully implement new methodologies. But our development team was large (several hundred members). This required a high level of coordination and cooperation among team members. Our large team had to work together as a single team, where previously we had independent design, development, test, and quality teams. The mix of skills in each Scrum team introduced new challenges. The scaled Scrum structure brought with it additional process needs. Team members were involved in more meetings and discussions, which required them to collaborate much more. All of these changes were implemented quite smoothly because of the development team’s enthusiasm and willingness to learn.

Naturally, there were many other factors that helped us in making Scrum implementation successful, but customer involvement, management commitment, and the cooperation of the development team contributed the most.

Predictability in Action

By Aaron Sanders

Earlier this year, I found myself in a familiar situation. I’d once again been wooed by a small start-up company that is growing in size and looking to hire senior expertise because of a major deal inked with a large organization.

The staff of the small startup were both exhilarated and stressed from working so hard to make the effort attractive to major players in the market. A year of doing whatever it took to get product out the door had taken its toll—two of the original developers had already called it quits. I wasn’t sure what I had gotten myself into, but I was excited about the possibilities. One thing I was sure of—their waterfall process was not going to get the job done. Let me take you back there and walk you through the switch we made and the results we achieved.

Rewind

It’s January 2007. I’ve just begun work at my new job. I immediately start pairing with anyone who checks out code. I notice that there is an infrastructure with some automation of builds, data replication and testing, so they definitely are not way off in the weeds. The product is web based and built with fairly robust open source systems.

The recently hired project manager is working with the creative director to come up with a fairly heavy process to accommodate the anticipated growth and to ensure success in the new partnership. They have printed out a graphic representation. The business development director is on a road show with the owner, promoting their wares. When the duo arrives back in the office, they find a note I’ve stuck to the graphic representation of the proposed process. It reads, “traditional waterfall.”

Meanwhile, I sit down with the project manager and ask if he enjoys writing use cases. Throwing down his pen on the desk and pushing back, he spins to me and states, “Heck, no! I can’t get anybody to read them, let alone approve them.” So I ask if he would be interested in hearing about a process where we wouldn’t have to have it all written down by him before we began. He’s interested.

After some education of the terminology of the practices, we invite the owner, business development director, and engineering manager to a discussion over coffee, where we go over what it would mean to introduce the agile methods of Scrum and XP to the organization. We discuss roles, how to generate and estimate the product backlog, length of iteration, and what day to start.

I explain the need to separate authority from responsibility by not placing the role of ScrumMaster with the engineering manager. We decide that this would be a good role for me. We determine that the project manager should be the product owner, as the business development director is gone too often. Since the project manager is also the system architect and has the most domain knowledge besides the owner, he is mentioned as a possibility for customer as well. Because this would stretch him thin, we convince our actual customer (partner organization TradeMe) to engage with us in that role. Already one incredible thing has happened, we’re now thinking more in terms of the product than of projects.

Since the team is already recording tasks and defects in an open source issue-tracking program, it is a simple matter to extend the fields to accommodate story points and hours remaining. Because people tend to be out of the office more often around a weekend, we decide to start sprints on Wednesday and have them run fortnightly.

The product owner and creative director convert all the tasks into user stories, breaking some things down, aggregating tasks together, and rewording them to be customer facing. Once the stories are written, the team gathers to play a game of planning poker. We find a small story that we all agree is worth one point, and then look at a couple of recently finished stories to help calibrate size. We then start to build historical data to help with initial velocity calculations.

Many of the interesting things involved with an estimation meeting start to happen: discussions over items too vague or big to be estimated, the true value of a particular story, breaking dependencies, and how to implement certain pieces. The meeting moves slowly. I try to break off discussion when it no longer seemed beneficial. After a few hours, we’ve only estimated a dozen items and have over a hundred items remaining. Still, the team declares the meeting a total success because they have enough for the first sprint.

Fast-Forward

It’s now mid-March. We have the majority of the backlog estimated and prioritized. Three sprints under are our belt, not counting sprint zero, which we used for preparation and learning (much like playing a hand of cards face-up). All this clarity into the effort involved leads to the director admitting that the contract negotiated with the customer (our partner, TradeMe) is fixed in both scope and deadline. It took six months to come up with the contract, and at this point we have only four more months until we’re supposed to launch the working product at the end of June. Our own estimates put the completion date for the product somewhere between mid-August and the end of October. We’ve got a bit of a problem.

The director and product owner work very hard to keep the product backlog prioritized. They sort things into themed stories well and do a good job of balancing out the work load. However, they want to be much further along and are constantly trying to push more work on the team. I decide to relent. Instead of planning April’s last sprint, we take on everything the contract specifies should be done by us at this point. Our best and last sprint finished fifteen story points; the work remaining is ninety points, seven times more work than has ever been completed in a sprint. Even with the director’s help coding, by the end of the sprint most of it is still incomplete. Neither the estimation date nor the velocity have changed too much.

In May, the suggestion is made that perhaps the stories are estimated incorrectly. How could the team be certain that something was worth five points while something else seemingly completely unrelated would be worth eight? We group user stories that have the same estimated point value to see if they are truly the same size, including finished stories. This comparison does show that some stories should be a different size or be re-categorized. We recalculate the velocity. Our estimated completion date still falls, at best, in September and, at worst, in November. Neither is close to the July deadline promised in the contract.

Fortunately we are now working in constant contact with our partner/customer because they are functioning as the customer for the sprints. They can check out our code and build in their environment. We have them on the phone for sprint reviews. The constant interaction clarifies that this project cannot go according to the contract. What they have seen accomplished to date makes them want different things, and some of these changes require direct input from them. This is a dependency we cannot control.

Eventually we all agree that the contract “nice-to-have” date is indeed more flexible than we thought, with a “drop dead” date beyond the fixed term of the contract. As I look at our sprint estimation, we are now knocking down about twenty points per iteration, with about 170 points yet to go. We are cruising to an October launch.

Play

After a couple more iterations, and well past the original deadline, it is made clear that the software needs to ship soon. Collaboration is high, with some of our developers working at our partner’s site. An incentive deal is reached: if people are willing to work weekends from now to launch, everyone will get a bonus week’s vacation immediately following launch. Perhaps this helps. The software launches on 7 September 2007, well within our original prediction of mid-August and the end of October.

Our agile estimates were proven correct. They helped to interject reality into an unrealistic contract. This agile estimation thing really works.

The Company: Vianet

The universal marketing system for tourism that utilizes the latest mapping technology and real-time booking capabilities to give travelers complete destination information.

The Partner: TradeMe

68 percent of New Zealand's internet traffic is to online auction site TradeMe, CEO Sam Morgan and Development Manager Rowan Simpson told me when I visited their Wellington office. TradeMe is New Zealand's version of eBay, even down to the color scheme. But it's more than just an auction site now. Over the past seven years it has expanded into major verticals such as jobs and motoring. Also it's probably New Zealand's biggest social networking platform (even though it's not strictly speaking an Social Networking System).

Even considering all that, when TradeMe sold for a cool $700 million New Zealand dollars earlier this year to Australian media company Fairfax, the price tag astounded many people in New Zealand and Australia. At the time, that amounted to nearly $500 million US dollars. To put that into perspective, it was a deal worth approximately 15 times more than the much more hyped sale of Flickr to Yahoo the year before.

Scrum is so easy! Why don't they get it?

By Chris Spagnuolo

Success is a funny thing. When we first started using Scrum, I think we got the go-ahead because management didn't think it would work. They cut us some slack to let us try something new, but were sure we'd be back to waterfall before we knew it. Now that we're using Scrum and producing quality, valuable software on time and under budget, everyone wants to know how we did it. They also want to start marketing it and selling it to potential clients. Fabulous, right? The problem is they don't really want to sell Scrum; they just want to sell the results. Although we have worked very hard to explain the basic practices of Scrum and other agile processes, most of the folks trying to sell our services (and our “process”) don't really get it.

For instance, I recently attended a short-list interview for a large, county-government GIS contract. We were among the top three vendors selected to compete for the contract. Our lead architect and I were asked to provide input on our software development practices. We had a few slides about our development environment, a few on our relevant project work, and one slide on Scrum. The Scrum slide had no text, just a diagram illustrating the Scrum process that we borrowed from Mike Cohn at Mountain Goat Software (we like being lean and like to talk about processes rather than try to put them in great big slide presentations). When I got to the pre-interview walk-through of the proposal team's presentation, the Scrum slide was conspicuously absent from the main presentation. In its place was a very impressive-looking program and software development workflow diagram—lots of boxes with labels like initial concept discovery, statement of work, draft work order, kickoff, work execution, testing, acceptance, and closeout. They were all lined up with nice little arrows connecting them in the traditional waterfall fashion. At punctuated, pre-determined points along the path, there were other boxes representing where we would have contact with the client. The only contacts prescribed for the client during the work execution were program financial status and schedule status.

I asked where in this melee of boxes our Scrum process fit. The answer I got was, “Oh, in the work execution box of course.” I couldn't believe what I had heard. To management, Scrum was just a little development process that worked inside the larger project management framework, just another little cascade in the larger waterfall. The way they saw it, they would have multiple projects running at one time, all working in a waterfall framework, with the only exception being that inside the work execution boxes teams would utilize Scrum to develop software.

We had been talking about Scrum as an overarching process for everything for months now. We had been emphasizing not only client communication, but very active client participation in the Scrum process, not just project financial/schedule status reports. For all of our hard work, we still hadn't convinced the management team that Scrum was an entire project management process.

Fortunately for us, we had a set of backup slides with our Scrum process diagrammed. When the interview panel asked how we would manage our projects, I was able to show the slides and give them the Scrum elevator speech. They asked about a half-hour of follow-up questions about Scrum and were genuinely interested in the process, especially in how Scrum would provide them valuable, useable software in a relatively short period of time.

The senior manager on the interview team backed our Scrum play and added some good insight into how our GIS development team was effectively using Scrum on other large-scale projects. However, he took the backup position of saying that we would provide whatever suited the client, be it Scrum or a more traditional waterfall approach. He wasn't being a jerk. He was just trying to sell our services—I understand that.

The point of all this is that it is very difficult to break the almost institutionalized acceptance of the waterfall approach to project management. Agile practices and Scrum in particular are scary to most people. Some mistake their relative simplicity for inadequacy in terms of project reporting and project management. Some underestimate the value of the iterative approach and the inherent increase in client communication and satisfaction that it provides. Most are just pre-conditioned to believe that if we don't understand everything up front, we can't run a successful project. So, I'm not upset with our management team. I know why our Scrum slide turned into a little box on the larger waterfall slide. They truly believe Scrum is just a software development methodology that fits neatly into one of their waterfall boxes. However, what we must continue to impress on them is that Scrum is a powerful project management process that works for many types of projects. I know of people in other industries using Scrum for projects that are much different from software development. I met a woman at a training class a few weeks ago who is using Scrum on real world construction projects for large hospitals. I've even heard of people using Scrum to plan their weddings.

So, keep selling Scrum to your management teams. Keep educating them. Keep correcting them when they misinterpret Scrum. But do it in a manner that helps them to understand and accept Scrum over time. It's our job as practitioners of Scrum to help others understand the process as more than just a software development methodology. We need to become Scrum evangelists of sorts, bringing the real message of the efficiency and value of Scrum to the non-believers.

On our flight home after the short-list interview, I referred our manager to Ken Schwaber's book Agile Project Management with Scrum. I also handed him a whitepaper called “A CIO's Playbook for Implementing Scrum” that I downloaded from the Scrum Alliance website. He's coming around slowly. Before we took off, he commented that he sees the value in Scrum, “It's basic common sense,” he told me. “How could it not work?”

I thought, “It's basic common sense, how could you still not get it?” Instead, I just smiled and said, “Yup, you're right!” and kept my hope up that he'd actually read the whitepaper and the book someday.

Why Fixed Bids Are Bad for Clients

By Andy Brandt

My outsourced software development company is based totally on the agile approach. We work in Scrum and have come to regard it as a natural approach to managing requirements, releases, and changes in a project. However, most prospects and clients we talk to are not as familiar with agile development. And almost all of them ask for a fixed bid on any project they want to build. They collect the bids, choose the best contender (usually taking the lowest bid), order the project, and then go away for the duration of the contract, hoping to get a working system in the end. More times than not, what they end up with is a half-finished system not fit for release. They then have to start over, this time stressing that they want an accurate price.

We don't work like that. We believe that fixed bids are a bad idea when it comes to software. First of all, you'll never get an "accurate price." Developing software, especially new systems built to individual needs, is a creative, inventive process. It is not possible to accurately say how long developing “Feature A” might take. It is possible to make a prediction, an estimate, but it's just that—an estimate. This is especially true when you consider the amount of information about each feature that is typically available at the project start.

Every software developer knows they can't accurately predict how long a particular feature will take, so they guess. There’s nothing wrong with that. The problem starts when this guess is presented as solid reality, which is exactly what happens in a typical bidding process. Since each company knows there is a risk in their estimates, they compensate for it by overestimating. Industry standard for security margin on estimates is somewhere around 25 percent, which shows how inaccurate they typically are. In any case, what you get as a bid is in actuality a guess, bloated by some margin so that the developer feels safe they won't lose money if things go wrong.

Let's say someone tells you a project will cost $25,000. We all know that in the end it might cost $24,998 or $25,231 but it won't cost exactly $25,000. In fact it's more likely that it will cost either $20,000 or $30,000. In the first case, you lose $5,000 in money or features that might have been developed. In the second case, you’ll receive an inferior project. Why? Because if the project is over budget but a contract is on a fixed price, every sane company will do all they can to limit their losses. In other words, they’ll finish the product as quickly as possible—just kick it out the door, the sooner the better. In software, kicking it out the door usually involves developing poor, undocumented code, solving problems via quick hacks rather than elegant solutions, and reducing testing to the absolute minimum. To further reduce costs, the company may replace senior developers with interns, working overtime. If, heaven forbid, not only the price but also the deadline was fixed and penalties apply, the software company has an even bigger incentive to lower the quality to limit losses. That’s one reason so many IT projects (be it software development or deployment) end up disappointing clients or failing altogether.

Another reason fixed bids are bad for clients is because the bidding process by its very nature requires the scope to be fixed as well. That means clients have to provide all the features they might ever want from the development team upfront, before any development starts. Many clients start by writing a list of everything they want from the envisioned software system. There is nothing wrong with writing that list; it is a very helpful effort. What is bad is fixing it, making it carved in the contractual stone. Why? Because you write this document thinking that if you forget to put something there you will never get it. Result: you end up putting many things there which are not needed, the “nice-to-haves.” Worse, you won't put there many things that will be needed only because you haven't thought of them yet. And you haven't thought of them yet because those ideas will occur to you only after you will start using the software, even in an early version. In other words, writing a fixed scope document and then freezing it by making it a part of a contract means trading many useful but yet unknown features for many nice-to-haves or things that no one will use.

Agile companies do think long-term planning is a good thing, but we don't sell the illusion that a plan is anything more than it is. At my company, we fix quality and release dates (every iteration, usually two weeks) and we fix the price of each iteration before we start that iteration. We don't fix scope and we don't fix the total price for the project. If a client has a great new idea two months into the project, that's fine; we'll just implement it. If by fourth month a client decides that what has been developed is enough - that's fine too; a client can end the engagement at any time. Agile companies offer flexibility that traditional development based around static documents can't match. Most offer services at a set, negotiated price. We'll build as much as possible at the best quality for the amount a client is willing to spend on the project.

One last thought: with an agile team you'll never be left with a heap of code that can't be used for anything except showing it around in hope someone will finish it. Why? Because at the end of each iteration you get a new, complete product release that is 100 percent tested and 100 percent functional. It might not contain all of the features you ultimately desire. In fact, the first release (two weeks after the project starts) probably won’t do much at all. But those features that have been finished to date are indeed done—fully working, fully usable. From the very beginning, you have a working software system that is upgraded every two weeks with new features. You're never held hostage by the development team: you own the code and you have something that is useful. The best part is that you decide which features are most important *now* and should be delivered in the next iteration. Flexibility, customer involvement, and working software. Now there’s a recipe for success.

Thanks to Paul Klipp whose podcasts on selling agile software development remain a source of inspiration. Many ideas for presenting the merits of the agile approach used in this article are based on those podcasts and discussions during our meetings with Paul.

What Scrum Can and Cannot Fix

By Angela Druckman

When introducing the concept of Scrum to an organization for the first time, I try to give a reasonably unbiased view of what to expect. I warn the new Product Owner that at first he may feel overwhelmed and struggle to articulate requirements in a clear and actionable fashion. I tell the new ScrumMaster that the innocuous duty assignment “ensure everyone follows the Scrum process” may make her wildly unpopular for a while. I also like to be clear with everyone which problems I think Scrum can fix—and which it cannot.

The Scrum framework brings a structure to projects that can right many wrongs, but it is not a silver bullet, and it certainly won’t make all problems disappear.

First, let’s look at three of the most challenging problems Scrum can not fix:

Endemic Organizational Problems

If you have long-standing organizational problems—passive aggressive behavior, people who are masters of “working around” the system, team members who don’t like or respect each other—Scrum will not fix this. On the contrary, Scrum will bring these tensions to the surface right away, probably in the first Sprint. I have had developers storm out of Sprint planning sessions, holding spirited shouting matches and just generally exude hostility at each other and at me.

And you know what? This is a good thing. It’s not like Scrum created these problems. Far from it, they were there festering under the surface, interfering with productivity all along. And while those are problems Scrum can’t solve, it does bring these issues to the light of day, where people can deal with them in a rational and actionable manner.

While resolution doesn’t happen over night, it usually comes about fairly quickly. However, as ScrumMaster, you should prepare your team and your management that some feathers are likely to be ruffled in the beginning.

Unwilling Team Members

Rest assured, if your team says to you as ScrumMaste,r “We think this Scrum thing is a stupid fad and we’re going to do everything we can to make it fail,” your Scrum project most certainly will fail. You need team members who are willing to give Scrum an honest try. I personally would take a team of enthusiastic newbies any day over seasoned veterans who won’t make an honest effort. Healthy skepticism is fine, but setting out to “prove” Scrum doesn’t work is a bit like the person who starts a diet but never manages to change his eating or exercise habits and then claims he “can’t lose weight.”

Along the same lines are the team members who fundamentally do not have an interest in improvement of any kind. Most of us have bumped into these souls at one time or another: maybe they are a year or two away from retirement, maybe the highlight of their job is a short commute and the actual work itself ranks a distant second. For whatever reason, they are very happy with the status quo, thank you very much, and do not need Scrum upsetting the boat. Trying to prod these people into action is like trying to get a turtle to gallop. Your time would be much better spent selecting a different team member who has the desire to learn and grow.

The Disengaged Product Owner

Finally, a true kiss of death for Scrum projects is the disengaged Product Owner. The reasons for this disinterest may vary. Maybe the Product Owner is too high up the food chain, such as a division head. These individuals have too many demands on their time already. Additionally, they are usually broad thinkers and used to delegating detailed work—not the person you want outlining the specifics of a Product Backlog. Perhaps the product owner is just not available on a regular basis. A Product Owner that you, as ScrumMaster, can’t get regular audience with is also going to have a hard time being successful. If you are building sales software, a sales executive that is out of the office twenty days a month is not going to make an ideal Product Owner. Choosing the right product owner is something only the team can fix. Scrum can’t fix it for you.

A good Product Owner has a vested interest in getting the Product Backlog right. They can tell you, in their own words, why the first item on the list is more important than, say, the fifth item. They worry about getting the backlog right—they don’t want to misstate the requirements and make their boss, their employees, and everyone in the division mad. In short, they have skin in the game. For this reason, in larger organizations, middle managers make great Product Owners. Their behavior is motivated by a high “pain factor” (life will be very unpleasant if they get the backlog wrong), so they have a vested interest in spending the time and effort to get it right

These are just a few of the most vexing issues Scrum itself cannot directly solve. You may be thinking “But wait – my organization has all those problems! What I can do about it?” Use the Sprint Retrospectives to lay it on the line: if you have team tensions, deal with it. If it appears the wrong person has been selected as Product Owner, state that you think this is true. In these cases, Scrum is best used as a means to facilitate an end: it may not solve all your problems but it can make them appear big and painful enough that everyone will agree they need some immediate attention.

What Scrum Can Fix

So if there are so many endemic problems Scrum can’t make go away, what problems will it help? This is a reasonable question and one I get from developers, business sponsors, and management all the time. Their basic question is: “This is going to take a considerable investment of time and effort to implement – what can I expect to get in return?”

There are a myriad of problems, small and large, that Scrum seems to clear almost magically. Here are a few that can yield wonderful results in a short amount of time.

Poorly Thought Out Requirements

A good business analyst is both a blessing and a curse. She is a blessing because she knows the finer points of business process and when to dig into details and get customers to think through their requests. But when a BA is too good, the customers may grow lazy. Their attitude becomes “Oh, you know what I need” and they no longer think carefully through their requirements or their prioritization.

Cut to a new Product Owner’s first experience at creating a Product Backlog. There’s no more semi-psychic BA to intuit his every need; he actually has to articulate what he is expecting. Saying, “The Add New Account screen is hard to use,” doesn’t cut it anymore. Why is the screen hard to use? What would make it easier to use? How would those changes affect downstream business processes? These are important questions for a Product Owner to think through. While I certainly don’t expect Product Owners to state requirements at the level a BA might and a BA may still be involved, I do expect them to be very clear on what they are asking for. Having this expectation vastly reduces the number of unpleasant surprises downstream.

Role Bleeding

Role bleeding is my affectionate term for what happens when a coworker doesn’t find her own job engaging or interesting enough so she decides she would like to help you do yours. These individuals end up assuming, or trying to assume, responsibility for decisions which they have neither the authority nor knowledge to make. This may take the form of business owners giving detailed “advice” about middleware tools. Or developers who change business requirements because they “know what the customer really wants.” In my pre-Scrum days, I once had a graphic artist responsible for website content maintenance who occupied long sections of meetings wanting detailed descriptions of server layouts.

Scrum puts all that to bed pretty much right from the start. The ground rules are clear: Product Owner, you are responsible for the backlog, the “what.” The team is responsible for the “how much” and the “how.” The ScrumMaster is responsible for keeping the whole process humming along, removing impediments and non-Scrum behaviors. And no one else has any in-Sprint role. Period.

Lack of Accountability

If you haven’t time-boxed projects before, as a first-time ScrumMaster you are going to be in for a breath of fresh air. So many project methodologies from the 1990s focused on scheduling to deliverables. We managed projects so as to complete “all” the requirements (though what exactly “all” meant had a strange way of flexing over time). As a result, schedule remained somewhat divorced from the project plan and its tasks. How each team member’s daily activities were contributing to a given feature being completed was something of a mystery. Not only that but, with an understanding that requirements were more important than schedule, developers often could not resist the urge to “gild the lily,” adding little features and extras that were never part of the original work statement in an effort to wow the customer and make up for all the delays.

For such team members, Scrum can be a wake-up call. It might take a while for it to sink in that the Sprint backlog represents a commitment but, once it does, I guarantee you will see a difference in attitude and actions. There is almost always an “Oh no!” moment when they realize 1) the Sprint is ending in 3 days 2) the demo with the customer is already scheduled and confirmed and 3) there is still have a heck of a lot of work they said they could complete that is undone. My experience is that teams improve their ability to estimate very quickly with Scrum—they want to avoid that “Oh no!” moment and the stress it brings more than you can imagine. There is no more time for gold-plating activities. Each team member needs to be able to come into the Daily Scrum and explain what they are working on and which backlog item that work is fulfilling. If you are hearing, “Well I worked on Activity X but I don’t know which backlog item it ‘goes with,’” you know you have some coaching to do.

The effect of this heightened sense of commitment is that you create a high-performing team that can quickly become a force of nature. Within just a few Sprints they are like a well-oiled machine: they estimate well, they develop efficiently, and they appreciate and trust each other. In essence, Scrum removes the “static” of project management such that the talent and experience that was there all the time can shine its brightest. I can’t fathom why, once experiencing this, anyone would want to work any other way.

If you are currently trying to “sell” Scrum to your organization, or to a client organization, I think it is important to give decision-makers a balanced view of the benefits of Scrum and a good idea of the fallout likely to come from implementation. I believe this balanced approach gives your pitch credibility, and will go a long way toward pre-empting overreactions when problems arise. At the end of the day, Scrum is about building high performing teams. And, as with all success stories, it is the good and the bad that shapes the final result.

Be There or Be Square: A Case for Collocated Teams

By John P. Puopolo

In today’s business environment, there are many teams working in a distributed manner. It is certainly not unheard of to have developers in the United States, Europe and India coordinating on core development, testing, deployment, etc. With the globalization of companies, availability of low cost multimodal communication, and the continuing use of outsourcing, distributed teams are here to stay.

And they don’t work well for agile development.

What we have come to realize is that the true power of agile comes from the social and synergistic interaction among a group of individuals who act as a team. This synergy translates into the team becoming more than the sum of its parts. For this to happen, however, the individuals who yield some of their ego to the collective, and truly commit to the goal, can only do so when trust, respect, and camaraderie are alive and well. Experience suggests that teams can achieve this level of interaction, and subsequent uplift, only after social bonds have formed and are actively maintained.

What kills team effectiveness, especially on agile projects, is summed up in one word: separation. Separation comes in different forms, each having a negative impact on team dynamics:

• Proximity (same building but on different floors, or different buildings on the same campus)
• Geography (different cities, states, or countries)
• Time (a function of geography or work habits)
• Skill (senior developers vs. junior developers)
• Culture (Americans, Europeans, etc.)

When people are separated by even short distances, they tend to rely on communication channels other than in person.¹ This means that people’s willingness to speak in person is somewhat inversely proportional to the distance between them. I believe there are many factors that influence this behavior including personality, laziness, and reliance on technology. You can see these forces at play when IM-ing someone across the hall or calling someone on the other side of the building. These types of interactions are perfectly fine in many situations, but are not robust or dynamic enough to be used by an effective agile team trying to deliver high-quality software.

When geographically separated, your only choice is to use dislocated communication – phone, IM, or e-mail, all of which are far less effective than talking in person. Part in parcel with geographic separation is that of temporal disconnection. It’s much more difficult, frustrating, and time consuming to work with colleagues several time zones away than it is to work with people on the same circadian rhythm. When separated by space and time, team members find themselves cramming meetings and conference calls into their days (for regular meetings, coordination, and side conversations), reducing the amount of time they spend producing shippable product. Managing distributed communications is pure overhead and results in low fidelity results. How many times have you been reading e-mail while “contributing” on a conference call where you are the only remote participant?

Another form of separation is that of skill. For our purposes, we can divide skill into two camps – domain knowledge and technical competency. When there is a significant divide among individuals along these dimensions, or within them, friction, misunderstanding, and miscommunication are inevitable.

Even though we live on "one small, blue planet that’s shrinking every day," we all come to the table with profoundly ingrained attitudes towards life, work, free time, money, productivity, interpersonal chemistry, family, and so on. People from different countries and cultures speak different languages natively, where context and subtlety convey deep meaning and are often lost in translation. To put a fine point on it, we must realize that there are inherent cultural dynamics that either aid or impede communication and understanding. The result: people from the same culture communicate more richly and effectively than those from different cultures.

With all of these forces at play, how in the world can separated team members communicate fruitfully and form the types of bonds required to reach enviable results? The short answer is that they can’t, since each separation factor multiplicatively impacts the positive effect that using agile development practices can have.

To illustrate, let’s take a fictional example of two Scrum teams. The first team is from Belgium. The individuals live in Ghent, speak fluent Dutch, work in the same physical office, and share core hours. The other team is made up of a balanced mix of Indians and Americans. The people on the American team are split between California and Boston, and the Indian team works out of an office in Bangalore. 

It’s immediately obvious that the Belgian team has tremendous advantages – people can work side-by-side, communicate effectively from both the language and bandwidth perspectives, are on the same time rhythm, can quickly discuss an important topic on a moment’s notice, enjoy social assumptions, and have the opportunity to form relationships that will help support their goals. They laugh together, peer program, eat lunch, debate, talk politics, and do what people do to develop relationships. If these people work in close physical proximity, the positive effects are enhanced.

It is these connections that enable team members to commit to one another, and subsequently to the sprint goal. No other forms of motivation, especially those imposed by “management,” are nearly as powerful as the promises made among the team members.

If you accept the assertions above, it is obvious that for a team to achieve the highest level of success with agile, you should provide an environment where the members share physical space² (a team room is a common example), work in a collaborative and dynamic fashion, and have the opportunity to form social bonds strong enough to sustain focus and commitment.

“All of this is well and good;” you say, “however, my teams are distributed, and I have expertise scattered about, so I have to have people all over the place.”

In these situations, strive to divide work so that you can form multiple, local teams. Each local team can work on independent user stories or tasks. In the example above, you could divide the American and Indian teams into two distinct groups. The American team could work on one set of interrelated stories, while the Indian team could do the same. These teams must commit to integrating early and often. Along these lines, if you have experts in a specific domain or technical area, send them where they need to be for short or long-term engagements (as possible), working hand-in-hand with the teams that need them most.

One worry against forming locally oriented teams is that they devolve into an “us and them” mentality. The team in the US, for example, who works together every day, starts to forget about and compete with the team in India, who are also working side-by-side. Although there is a remote chance of this happening, the benefits realized by the collocated teams far outweigh the potential costs of managing a rift that may form between them. Knowing that this social fissure can form, the proactive manager must constantly find ways to quickly break down any walls that form; e.g., regular coordination meetings, instituting a “catch and release” program where pairs of developers swap locations for extended periods of time, and so forth.

As an agile manager, you must continually focus the team and remind them that the only measure of success is shippable product, and that the whole team, in its entirety, is accountable for the results.
If working in dislocated teams is inevitable, help people coordinate via technology.  The important thing here is setting up multiple, reliable, and efficient communication pathways. On one distributed project I worked on, we used e-mail, IM, WIKIs, VNC, common servers, and always-on conference bridges to help make up for the lack of team members being physically present.

If you need to work this way, make sure to coordinate with your IT department early – you will need their help to make sure things run smoothly and to fix things when they break. The IT department can ensure conference bridges are available and working, servers have the proper software installed and have enough disk space, routers are configured to allow collaboration software to work properly, etc. You must do everything within your power to enable team communication, trust, and synergy. Every dollar that you spend supporting these goals, you gain back in spades in terms of team productivity. It’s a smart investment.

When teams fail to work in a tightly knit, collaborative fashion, “agile” devolves rapidly into an administrative practice. Under these circumstances, a Scrum team may still have Daily Scrum Meetings, use Burndown Charts, and manage backlogs, but they only realize a mere fraction of the potential benefit. 

The real power of agile lies not in administration or governance, but in the wisdom, chemistry, and commitment of collocated teams.

1. A study by Kiesler and Cummings found that when people are separated by thirty meters or more, they tended to interact infrequently. In addition, these distances drastically reduced the likelihood of voluntary collaboration. You can find their paper at http://www.ece.ubc.ca/~leei/519/2002-ProxmityDistanceWorkGroup.pdf
2. When setting up team friendly environments, remember to respect people’s need for occasional privacy. Have a room where people can make private phone calls, get away, etc.

Going Nowhere Fast: Scrum without a Product Owner

By Jim York

Like Donkey, riding in the back of the garlic coach on the way to Far Far Away in the movie Shrek 2, too many product owners are taking a back seat in Scrum by limiting themselves to asking, “Are we there yet?” Little wonder. Accustomed to decades of “over-the-wall” requirements handoffs and long delays before seeing a working system, many product owners are disenchanted and ill-prepared when faced with the immediate, persistent, and unrelenting demands of a Scrum team. What was “Far Far Away” is Now. Here. Today. Product owners aren’t prepared.

When acting as ScrumMaster, I’ve found that I spend at least 50 percent of my time working with the product owner and the myriad of stakeholders the product owner represents. When you introduce Scrum to a new team, find out who the business sponsor is and make sure she understands the pivotal role that the product owner plays. The product owner is ultimately accountable for maximizing the return on investment (ROI) for the project. To succeed, the product owner must establish and communicate the project vision — the elusive “it” that constitutes real value to a real customer. Then the product owner must nurture that vision by frequently inspecting the working features produced by the team and providing timely feedback. When reality deviates from the plan, the product owner works to adjust the plan to match reality while keeping the team focused on the vision and holding together the coalition of stakeholders.

The days of handing over a requirements document and then sitting back to wait for the delivery team to finish are over. Product owners don’t belong in the back seat. They must be immediately available to the team. My rule of thumb for a product owner is that they must ensure that 80 percent of the Scrum team’s questions are answered within five minutes of the question being raised. To achieve this level of responsiveness, the product owner really must be engaged and must engage subject matter experts to be available to the team when necessary. This isn’t a role to be taken lightly.

Get ready product owners because, like Donkey, you definitely aren’t in the swamp anymore.

Perfect Planning: Best Practices for Successful Sprint Planning

By Guy Beave

A successful sprint starts with the planning session. Taking the time to plan allows the team to review the work about to be undertaken, estimate the effort required to complete that work, and then commit to a prioritized list of stories and tasks that are within the team’s calculated capacity. This light set of procedures is well documented in Scrum and Agile literature [1],[2], but included here are some observable traits and best practices that have been found in well-formed, hyper-productive agile teams.

The purpose of the agile planning session is to present a collection of user stories to the team and allow them to be estimated. This is where team effort gets aligned with business direction, and is the essence of the agile phrase, “let the product lead.” At the end of the session, the team should feel committed to completing the work required to implement the agreed-upon list of user stories during the next sprint. An information radiator [3] should be loaded and prioritized with the sprint backlog of stories, and the team ready to begin the next day with a Daily Scrum.

A well-formed agile team has a product owner who is prepared for the planning session and is ready to present sprint goals and a prioritized list of stories for estimation by the team. This prioritization has a rhythm all its own. The product owner should review the product backlog frequently so that stories are staged and ready-to-go for planning sessions based on the latest business priorities. A best practice that helps make this happen is to visibly display the product backlog close the product manager’s office, so that he/she can has a constant reminder of the upcoming prioritization [4].

A well-formed agile team has a product owner who can clearly state the Vision (why the agile team exists) and can formulate clearly the goals for each Sprint [4]. This clearly stated vision and sprint goals should be used to begin the sprint planning session, so that guiding principles can be applied to each story considered for estimating. New stories are typically unfolded as the team asks questions of the product manager during the planning session.

Determining the team’s capacity is critical to a successful planning session and should be the first activity in the planning meeting. Two best practices for determining team capacity are:

1. The total capacity of the team should be based on the following equation:

   # of team members × # of days in the iteration × (no more than) six hours.

2. Start the planning session by establishing who has vacation time planned for the upcoming sprint and capturing that information in a vacation story. The vacation story has tasks for each team member’s time away, which accounts for some of the team’s capacity when stories are being committed. As the sprint progresses and the vacation days are hit, the burndown chart reflects these time-away tasks as being completed along with any other tasks. This prevents the burn-down from falsely indicating a problem.
   For example, suppose a five-member, well-formed agile team is planning a ten-day sprint. The capacity of the team is quickly established to be
   5 members × 10 days × 6 hours per day = 300 hours capacity.
   The ideal daily burndown is, therefore, thirty hours (300 hours of capacity ÷ 10 day sprint).

Since new agile teams typically have questions about how to handle time away (vacation, training, etc.), the following example helps illuminate best practice 2, mentioned above. A well-formed agile team is extremely tolerant of team members’ vacation and other time-away needs, as paired programming and role-sharing prevent silos of code territories to build up. When a team member is away, the well-formed agile team can easily adjust and continue creating business value. Suppose four team members are attending all-day training during the first day of the sprint. The team accounts for this by creating a time-away story that has four tasks, each with a six-hour estimate. These tasks get completed on the first day, so the burndown chart correctly shows the time burndown.

Notice that sprint capacity is calculated under the assumption that each team member has no more than six hours to commit per day. This buffer prevents the team from being over-committed, and is a responsible approach for accounting for distractions. This helps enforce the lean software development principle “limit work to capacity,” ensuring that a hyper-productive state is sustainable.

Planning is also the time for the agile leader to ensure that the agile team will create business value during the upcoming sprint. Effective agile leaders create an environment where each day is seen as an opportunity to close stories, and where daily progress is visible and is reinforced by a satisfied product owner.

The Perfect Planning session can be summarized in the agenda below. Try variations of it to plan your next sprint:

9:00–9:15
Daily Scrum (last scrum of ending sprint–discuss any unclosed stories and agreement on how to handle)

9:15–10:00
Demo of stories delivered over the course of last sprint

10:00–10:15
Break

10:15–11:15
Sprint Retrospective (what worked well, what can work better)

11:15–12:15
Lunch (Ideally catered)

12:15–1:00
Determine upcoming time-away and establish Team Capacity for the planned sprint

1:00–2:00
Visioning (product owner presents: Review OBT, discover Sprint Goals, discover Roles. Product owner presents each story in priority order)

2:00–4:00
Team reviews stories, creates estimated tasks for each

4:00–5:00
Team commits to chunk of stories to product owner, ready to start Daily Scrum tomorrow

A purely lean view considers planning and estimating a batch of stories as waste. Dave Anderson and Rick Garber (both of Corbis) gave a great presentation at the Lean Product Development Summit [5] where they demonstrated a pure Kanban implementation for software development that had no planning or estimating. Stories were instead pulled in to the iteration on a space available basis based on the current capacity. This approach has the potential to raise productivity.

It’s hard for me to imagine doing away with the planning session altogether. In my experience, the pause between sprints allows teams to celebrate and catch its collective breath while the retrospective provides feedback required for convergence of the complex adaptive system. However, it would be interesting to take a well-formed Agile team, and migrate it to pure Kanban to see what productivity gains could be realized.

For new agile implementations, though, the light rules of Scrum with agile/lean principles provide a proven transition to lean software development. The beauty of lean and agile principles is that they dictate that the best implementation is one that can be inspected and adapted. The Corbis implementation of this Kanban approach reinforces the application of situational agility, and I’m grateful for Dave Anderson and Rick Garber for illuminating this so well in their presentation.

References

1. Agile Project Management with Scrum, Ken Schwaber
2. Agile Estimating and Planning & User Stories Applied, both by Mike Cohn
3. "Information Radiator," by Alistair Cockburn
4. "Eye on the Prize: Best Practices for Aligning Agile Efforts with Business Goals," by Guy Beaver
5. "A Kanban System for Sustaining Engineering on Software Systems," by Dave Anderson & Rick Garber

Plan of Action: A Retrospective Technique for Creating Actions Tied to Long-Term Goals

By Bas Vodde

While I regularly change all other retrospective exercises, the action planning technique I’ve been using for the past two years has worked so well that I don’t want to change it. That has not always been the case.

Action planning in my earlier retrospective often had some problems. Some of the action items were just good intentions without enough concrete details to make them actionable.  These items focused on some longer-term goal that couldn’t be achieved during the next sprint. The result of this was that nothing actually happened. “Improve communication” is a good example for such an action. Other action items had the opposite problem. These items were very concrete but lacked a clear goal. For example, one action that came out of many retrospectives was to change the time of the daily scrum. We easily accomplished that action, but didn’t move any closer toward our overall goals as a result. If actions aren’t tied to goals, the team gets stuck in short-term thinking and leaves the longer-term, harder improvements simply because they cannot do them within the next sprint.

Action Format

To solve these problems, I ask the team to generate all actions in a specific format, as shown below.

Long-term goal:  Have test automation on acceptance-test level
Now-Action:  Pete will automate one test using Fit

This format helps the team consider a long-term goal for every action. It also helps them create very concrete actions to move the team a step closer to the long-term goal. The now-action has to be one that can be implemented in the next sprint and must be something the team can accomplish itself. The question to ask is, “What can we do?” This does not mean that the action or the goal has to be within the team’s authority. For example, the team might need new, expensive test equipment. The team might not have budget authority to make such a decision. In this situation, the long-term goal could be, “Have enough test equipment so there is no waiting waste”. The now-action might be, “Make a cost analysis for purchasing test equipment and share this with the person authorized to approve the purchase.”

Every sprint retrospective starts with a review of the previous now-actions. If the now-actions are not completed, we invest time, perhaps the whole retrospective, discussing why not and how we could change that. If the now-actions from retrospectives are not complete, then it’s probably no use to even have retrospectives since no improvements are being made.

Action generation and prioritization

Having an action format is of little value if we do not have a method for generating those actions. The first step in action generation is to have every team member individually generate as many actions as possible. Every action is written in the established format (goal and now-action) and written on an index card. This activity is timeboxed to about ten minutes. After the individual actions are generated, we divide the group into pairs. The individuals in each pair explain each other’s actions to each other. The pair selects the most important actions out of their combined actions, trying to limit the total to a handful of actions, for example five. In this phase they can, of course, generate new actions. This activity is also timeboxed, though it’s often finished before the end of the allotted time. Next, the pairs join with another pair to form groups of four and repeat the process, this time sharing only the most important actions they selected from the previous activity. The foursome further pares down the chosen actions, to for example four. This process continues until there is a whole team discussion. At that point the team selects the actions that have slowly emerged to be the most important.

At the end of the selection process, I write all the actions on one flipchart sheet and hand it over to one of the team members. This sheet is then hung in the team’s workspace as a visual reminder. Those actions not selected can be discarded.

For example, in a retrospective with eight people, the following steps would be taken:

• 10 min – Individual action generation.
• 10 min – Pairs select the top five of their shared actions
• 10 min – Groups of four select the top four of their ten shared actions
• 10 min – The whole group selects the top three of their eight shared actions

The process is based on having team sizes that are a multiple of two; however, with some creativity it works for any size group. It might mean that in the first step there is one group of three or in the second step one group of six and one group of four. (The calculations did give me and my co-facilitator a headache in a group of around forty.)

The advantage of this action generation technique is that it combines individual action generation with group action generation. It then slowly, step-by-step, creates consensus on the actions. Everyone tends to stay involved in the process mostly because they have all been involved in the process from the beginning. Also by slowly increasing the group sizes, the more silent personalities tend not to be excluded.

While we generate as many actions as we can, we ultimately select only a few, typically three, to be done in the next sprint. Selecting too many actions is a common mistake in action planning. The effect is a loss of focus and a huge amount of time spent on tracking the actions.

Linking retrospectives

Sprint retrospectives should be linked so that they build on each other and focus on long-term, continuous improvements. One way to link retrospectives is to bring the actions from the previous retrospective into the current one and discuss whether they are complete or not.

Another way of linking retrospectives is to keep the long-term goals from every retrospective, typically by writing them on a flipchart sheet. In every retrospective, then, we display the long-term goals and use them as input for the action generation.

Can we generate new now-actions for these long-term goals? Do we have any new long-term goals that we need to add to the list? Every now and then we go through the list to see which goals are still valid and which ones we achieved. We remove all invalid or complete actions.

Conclusion

I’ve used the action planning technique presented here in countless retrospectives over the past two years.  Without fail, it has resulted in a small number of agreed-upon actions. Whatever other retrospective exercises you use can serve as input for the action planning. This action planning exercise should happen at the end of a retrospective. I hope that sharing this technique will help other teams improve their own retrospectives.

The Daily Meeting Trap

By Alexandre Magno

One of the main practices of Scrum is the daily meeting. These meetings are characterized as fifteen-minute activities that should be done every day. In the meetings, the team members must answer the following questions:

• What have I done since the last meeting?
• What will I do before the next?
• Am I having any problems?

When I do Scrum presentations, I notice how simple this activity seems to most people. But this simple meeting is an important thermometer of your sprint.

Daily meetings are not coffee breaks

Some teams, in the course of the project, start to think that daily meetings are trivial things, and there's no need to formalize them with schedules and facilities. The consequence is that they start to meet in the coffee room, at smoking places, or even in a bar. The team eventually replaces the "daily meeting" with "fifteen minutes of informal chatting about the project." Daily meetings should always happen at the same place and time (at least during the current sprint). Good places to meet include: meeting or training rooms, or any place with enough room to accommodate the whole team. The boss' office is the worst option.

I once read an article that suggested mornings are the ideal time for daily Scrum meetings, but in practice I don't see it that way. I’ve worked with teams who meet at the beginning of the day and others who meet at the end of the day, and both have pros and cons. In the morning, all participants are rested and ready for a new day. But mornings also find people running late (traffic, weather, kids, etc.). You rarely have the entire team present, and that’s not good. At the end of the day, everyone is a little (or very) tired, which decreases the enthusiasm during the meeting. On the other hand, you usually have the whole team in the meeting, and that's very good. So, analyze the scenario (company, project, and team) and choose the better of the two options.

Daily meetings are not chat times

If you intend to allow those people only somewhat involved with the project (chickens) in the meeting, make it clear when you invite them that they only have the right to participate as listeners. Only people really committed to the project (pigs) should speak in the daily meeting. By letting "chickens" speak in the meeting, you are allowing the people who don't follow the project on a daily basis give their opinion about its course. This could cause a breach between "pigs" and "chickens" and worse yet, the fifteen minutes will end before you even notice.

Daily meetings are not technical meetings

Many teams use these fifteen minutes to expose and try to fix problems. On many occasions I’ve had to interrupt a programmer while he was talking about an obstacle: "I'm having problems with the XYZ framework, there's that anything class that I need to instantiate, but I can't because it's inherited from the otherthing class which implements interface nothing. If I instantiate it directly I'm going to have a redeclaration method problem, blah, blah, blah." Well, this single paragraph would create technical debates which would surely exceed the meeting's fifteen minutes. What would be the best way to report those obstacles in the daily meeting? Something like: "I'm having difficulties with the XYZ framework and I think I need some support/help to get in compass." End! Now, after the meeting, it's a ScrumMaster’s duty to provide a solution for the programmer's problem, be it scheduling a technical meeting, asking for technical support from the vendor, organizing a pair programming with someone more experienced, or what have you.

I usually use feature-driven development’s rat hole strategy during the daily meetings. The rat hole is nothing more than a flip-chart or whiteboard where we list all related issues that are brought up but won't be discussed in the meeting. After the meeting, the ScrumMaster decides when and how those issues will be discussed.

Daily meetings are not court trials

This is by far the most frequent mistake in daily meetings. The teams, mainly those in which the members are not used to being part of self-managed teams, use the meeting to report to the ScrumMaster, in many cases justifying a delay or some other problem. The daily meeting was created mainly for the team, not for the ScrumMaster. And it is to the team that each member should report. The daily meeting helps us get a current idea of the following: Where did we come from? Where are we? Where are we going?

If the team uses these precious fifteen minutes to penalize a member, hear excuses, issue moral lessons or the like, it won't be successful.

If you, as a ScrumMaster, can't evaluate whether or not your team is grasping the daily meeting's purpose, try skipping the meeting—without notifying anybody. If, when you get there, the team tells you that the meeting was cancelled because you were absent, you’ve got problems! They really don't understand that the daily meetings are there because of them.

Therefore, understand—and make sure the team understands—that the daily meetings:

• Help us evaluate our timing;
• Make the entire team better informed about what's happening in the whole sprint; 
• Identify obstacles; 
• Make the team into a team daily; and mainly,
• Give us an updated thermometer of "How is our sprint going?"

References:

Broderick, S. 2006. "Daily Standup Meeting Withdrawal in Scrum Teams." Scrum Alliance.
Palmer, S., and J. Felsing. 2002. A Practical Guide to Feature-Driven Development. Prentice Hall.
Schwaber, K. 2004. Agile Project Management with SCRUM. Microsoft Press.

Closing the Gap

By Roger W. Brown

Our coaching group recently received requests for help from three teams that needed to make changes in their agile practices. The first was a team that had adopted a set of agile practices with no external guidance. They had veered off course. The second was a team using some agile practices with no formal knowledge of agile principles or practices. The third was an established agile team that has been acquired by a new company and is now required to conform to a different agile framework. In all three cases, we applied a simple, yet effective, tool: a facilitated gap analysis.

Our first case is an example of the type of issues we encountered. As an introductory step, the team invited us to join the Daily Scrum. This is what we heard:

• Twenty people from multiple locations met for thirty minutes on a conference call.
• All focus was on a collaboration tool used to log each member’s time-in-task.
• An authoritative voice directed each person to answer three questions:
  o What task did you work on since the last meeting?
  o How much time did you spend on it?
  o Why is it taking so long?

Anyone who has had Scrum 101 could find the warning signs in this scenario right away. But we don’t want to just send the team a list of our recommendations. A basic principal of Scrum is team empowerment. When a team makes its own decisions, the motivation level is higher and success is more likely. Similarly, a team requesting outside assistance is likely to have better results when the help is facilitated rather than directed. Our challenge, then, was to get the team to find their problems, own them, and fix them. That’s where gap analysis comes in.

What is Gap Analysis?

Gap analysis is a conceptually simple technique for identifying the differences between one system state and another. In business it is often used to compare current performance with potential performance. In software development it is often used to compare the current system with a target system that offers some advantage. For our purposes, we used gap analysis to find the difference between current team practices and desired team practices and then to help the team define a strategy for moving from the current state to the desired state.

This is the general recipe we developed to guide these teams in a favorable direction.

1. Define the Current State

We want the team to tell us what practices they are using now. Our role as coach is simply to facilitate the collection of data. At the same time, we are watching for clues to the motivating factors behind the current choice of practices. For example, is the team aligned on the current set of agile practices or were they mandated by someone in the corporate hierarchy? Motivations can reveal additional opportunities for improvement.

Occasionally, we may need to ask leading questions when we detect omissions in the story. For example, if the team does not seem to be aware of a particular agile guideline such as small team size, we might ask a question about the size of the team or division into sub-teams to help make an issue more visible. These questions are best asked in a value-neutral manner.

2. Describe the Desired State

Next, we make a presentation describing the target process and recommended practices. Again, no value judgments are made regarding the current processes and practices. We simply present a vanilla case that is common agile practice in the organization. We answer questions as they come up. From the context we can determine which questions are best answered directly and which can be leveraged to elicit a comparison with the current state regarding both practices and motivations.

3. Facilitate the Gap Analysis

The third step is to invite the team to compare and contrast the current state with the desired state. We use fairly standard retrospective facilitation techniques here. Create an opportunity for each team member to contribute. Make it safe to speak. Un-invite authority figures if that will help. Keep a running list of differences on the whiteboard. We reserve the right to propose items at the end if we feel that important differences were not listed. The team can accept or reject our suggestions.

We keep a second list of “challenges” that the team may mention along the way. These are things that the team identifies as impediments to productivity but are not necessarily related to an agile process. Some examples are expensive deployments, a disengaged Product Owner, or high demands on the team for support of the current product. These may relate to the gaps or may be orthogonal. In either case, they may show up as additional opportunities for process improvement.

4. Prioritize the Gaps

At this point, we treat the list of differences much like a backlog and ask the team to prioritize them. The priority can be a multi-parameter function as it is with software features. Which items are easiest to implement? Which will have the biggest impact on improvements? Which are likely to be the least or most disruptive to the work already underway?

5. Define Action Items

Now that we have identified the gaps and their relative importance, what can we do to bridge each gap? Working with the prioritized list of differences between the current and the desired state, we invite the team to define action items. The action items may include self-assignment of gap owners and timelines for implementation. We may offer suggestions from experience or the literature. We test this before giving much “advice” because unsolicited recommendations are not necessarily welcome.

Action items also may include approaches to meeting the list of additional challenges we identified in the gap analysis. We stick to the general theme of process improvement rather than compliance to agile philosophies or practices.

Conclusion

This simple recipe for gap analysis is easy to follow but is full of challenges. Here are some keys to success:

• Do not assume that you know the best solution for a particular circumstance.
• Let the team own the discoveries, decisions, and action items.
• Encourage all team members to participate.
• Pay attention to both verbal and non-verbal clues to identify team relationships and other opportunities for improvement.
• Stretch the analysis over a few days. It may bring up complex issues that need some mental processing time.

Empowering Teams: The ScrumMaster's Role

By John Hill

The number of “unempowered” teams alleging to be doing Scrum is appalling! Two significant factors often prevent Scrum teams from becoming empowered, ultimately leading to their failure:

1. Organizational command and control behavior
2. Specific ScrumMaster failings

Both of these factors are something a ScrumMaster can (and should) address.

Symptoms

You can tell a team knows they are powerless when you observe them going through various Scrum "motions." These motions include the following dysfunctional sprint meetings:

• Sprint Planning Sessions. Symptoms include managers or ScrumMasters:
  • Questioning (or influencing) team task estimates.
  • Directing the order in which tasks should be completed during a sprint.
  • Directing which team members should be assigned to specific tasks.
• Daily Scrums. Symptoms include:
  • Providing status to the ScrumMaster instead of providing status to the team.
  • Zombie-like monotone responses, such as "I did this. I will do that. I have no impediments." Daily Scrums of this nature rarely lead to the collaborative post-Scrum discussions where decisions are made and impediments are circumvented.
    • For a great discussion on how to get your daily Scrum back on track, see Stacia L. Broderick’s “Daily Standup Withdrawal (DSW) in Scrum Teams.”
• Sprint Reviews/Demonstrations and Retrospectives. Symptoms include:
  • Managers and/or ScrumMasters who take charge of the session and state their observations first. This often influences the team to stifle their best observations for fear of contradicting the manager.
  • Little meaningful feedback from the team. The result is that no “go-forward” improvements result from the sessions.
• General Meetings. Symptoms include team members that:
  • Ramble aimlessly.
  • Hijack meetings and won’t relinquish control back to the team.
  • Do not participate.
  • Get up and leave meetings.
  • Force their “expert” opinion on the team inflexibly.
  • Argue about everything.
    • For great techniques to handle these team meeting dysfunctions, see Jean Tabaka’s Collaboration Explained: Facilitation Skills for Software Project Leaders, Upper Saddle River, NJ: Addison-Wesley, 2006: 242-251.

Causes

"Command and Control" Style Managers (including ScrumMasters)

All of the problems described under “Dysfunctional Sprint Meetings” are caused directly by managers (including ScrumMasters) who usually come to Scrum armed with years of ingrained, directive behaviors. The ScrumMaster needs to work with these managers to get them to let go. It’s the ScrumMaster’s responsibility to educate management and help them understand that the process is all about trust. If team members cannot be trusted to determine their work, teams will never properly “commit” to completing a sprint goal, nor will they ever feel the desire to make the key decisions that they should be responsible for.

The ScrumMaster also needs to work with managers to help them to allow others to provide feedback during sessions before they chime-in. If the manager cannot be controlled in this area, they may need to be removed from the process.

If the ScrumMaster is the problem, then an agile coach needs to be brought-in to educate the ScrumMaster (or have the ScrumMaster removed and replaced if necessary).

I would also like to add another cautionary note. Converting line managers into ScrumMasters sometimes will not work. The team behaves as though the ScrumMaster is "the boss" and looks to that individual for guidance while doing Scrum. Teams thus feel that their power comes from the ScrumMaster, and not from the team. Converting "strong" project managers into ScrumMasters can be problematic for the same reasons.

In both instances, the team will likely provide status to the ScrumMaster during the daily Scrum, instead of using the session for its intended purpose of sharing status with the team. Fortunately, there are numerous exceptions where former line managers and project managers are now successful ScrumMasters (although this transformation can take a while).

General ScrumMaster Failings

I strongly recommend that ScrumMasters refer to the book by Jean Tabaka referenced above and make use of its wisdom. If a ScrumMaster is unable to resolve these issues, a professional facilitator should be consulted. In my experience, teams will never feel in control if members do not properly participate together in meetings as a cohesive unit. I therefore believe that it remains the ScrumMaster’s responsibility to ensure that these issues are resolved, even if by a third party.

Cure

To ensure team empowerment, the Scrum Master must work diligently on all of his or her responsibilities.

Resolve Conflicts: The ScrumMaster is responsible for removing certain barriers, including barriers:

* Between individual developers (or between any individual team members)
* Between developers and test engineers (especially when first working together cross-functionally)
* Between the development team and the product owner.

If the ScrumMaster does not have the skills to deal with team conflict, a professional facilitator should be consulted. A team will never be fully-empowered with even one dysfunctional relationship within the team.

Handling Impediments: A ScrumMaster must actually work to help remove impediments reported during the daily Scrum. If it looks like an impediment cannot be removed for some reason, it becomes a condition of reality. For these conditions, the ScrumMaster must work with the team to circumvent the impediment. If an impediment requires more than one day for removal, the ScrumMaster must communicate this information back to the team so that they know the ScrumMaster is making an effort on the team's behalf.

Protecting the Team: The ScrumMaster must protect the team from disruptive outside influences. (Examples include salespeople directly requesting estimates from team members for prospective clients, support staff directly contacting team members for help with customer bugs, consultants at client sites calling team members with installation, conversion, or configuration problems for a new installation, etc.) Even if a team member is truly needed in these situations, the ScrumMaster must provide a filter. The ScrumMaster must also protect the team from attending unnecessary meetings. Most meeting owners will be able to tell if a team member really needs to attend a meeting. If so, the ScrumMaster should still be the filter.

Conclusion

Scrum teams feel truly empowered when they understand that the ScrumMaster is actually looking out for the team and will protect the team from outside influences that can rob the team of its power. More specifically, the ScrumMaster needs to

• Eliminate (or sufficiently reduce) “command and control" management practices so that teams can run their own sprint planning sessions in the areas of task estimates, task sequencing, and task assignments, as well as run sprint reviews and retrospectives openly and honestly so that they actually make a difference going forward.
• Ensure that dysfunctional meeting participants are controlled, even if by a third-party facilitator.
• Ensure that barriers between team members are removed, even if by a third-party facilitator.
• Effectively work with the team to remove impediments, proving a level of true commitment to the team.
• Protect the team from stressful outside influences and unnecessary meetings, enabling the team to work together with reduced interruption.

The bottom line is that teams will not feel truly empowered until they realize that the ScrumMaster is serious about the ScrumMaster role. This is most of the battle (and the toughest part of the battle, requiring a ScrumMaster that “gets it”). Until this commitment by the ScrumMaster is proven to the team, teams will rarely understand the nature of a "commitment driven sprint" themselves, and backlog items will continue to slide from sprint to sprint.

The Right Skill Set, the Right Mind Set, The Right ScrumMaster

By Benoît Houle

Over the past several months, we have learned the importance of having the right person in place as the ScrumMaster. Can a ScrumMaster make or break a sprint or a release? Definitely! That’s why it’s important to choose a ScrumMaster who not only has the right skill set, but the right mind set as well.

Here are the attributes and skills we are looking for at BioWare when we hire and evaluate our ScrumMasters:

Attributes (natural but can be developed)

Focused and meticulous

• Ensures that the team’s actions are always aligned with the acceptance criteria and project goals (vision);
• Minimizes errors by taking an organized approach to work assignments.

Team player

• Does not shy away of any tasks that could help the team and leads by example (e.g., if the team decides to work extra hours to meet the sprint goals, the ScrumMaster should be there with them).

Great problem solving ability

• Go-getter who rapidly obtains information to solve problems
• Helps the team identify conflicting priorities, then frames and escalates issues that cannot be resolved quickly.

Trustworthy

• Reliable and walks the talk (executes on what they say every time)

Accessible

• Easy going personality and personable

Skills (learned and experienced)

Outstanding communication and decision making skills

• Propagates information promptly, clearly, and unambiguously
• Knows when to make the call on a decision; no analysis
• Identifies trade-offs between short and long term and promptly reaches a shared vision between the team and product owner

A capacity to make the team work together

• Ability to develop and foster teamwork. Able to diagnose, understand, and facilitate team dynamics.
• Consistently gauges how the team is doing and drives the necessary actions to

  improve.

Inspires and motivates

• Facilitates team mechanics and energizes the people. Motivates, draws out, and rewards the best work from individuals on their team. Highlights exemplary behavior, skills, or accomplishments.
• Great working attitude. Always looks for ways to make changes work rather than only identifying why changes can’t be done.

Emotionally stable and works well in stressful situations

• Stays calm and composed under stress.

Conflict resolution

• Facilitates constructive debate to enable better decisions and shared vision
• Resolves disagreements and conflicts constructively. Knows when to involve others.
• Demonstrates emotional maturity (discretion, objectivity, integrity, confidentiality) in all interactions.
• Supports decisions that have been made, even when he/she does not personally agree.

While choosing the best ScrumMaster is critical, remember that it’s also very important to create the right working environment for the ScrumMaster to succeed: they need to be able to make decisions "stick" and they need to have the authority to remove roadblocks.

The attributes and skills listed here can be a good starting point for creating a list specific to your own company’s unique needs. Choosing the right ScrumMaster is well worth the upfront effort.