Unlike some of those fervent Agile proponents who think the Agile process is "the end all and be all" solution of our IT ills, our approach to IT process improvement is based not on some vague process improvement for the sake of process, but on an organization's business needs and goals—the only condition for any process improvement effort to have a measurable and lasting success.



Step 1: Identify the Business Sponsor and Her or His Needs and Goals

As long as we recognize that the main objective in building software is to support a business, it will become obvious that for a software delivery improvement program to be successful, we have to link it to some specific business goals. This is the reason why the first step is to identify the owner of these business goals for whom you are supposed to implement this IT improvement effort.

Identify the Business Sponsor
Knowing whose business goals this IT effort is supposed to help achieve will help you identify the goals that will drive your improvement effort, as well as determine the metrics you should use to measure your achievement.

Identify Business Problems and Issues
Whether the idea to improve software delivery capability comes from within IT or from the business, it will always address some business problems and issues, which the business sponsor tries to solve.
For illustration purposes, examples of problems or issues that have to be corrected can be one of the following:
- Complaint that software delivered does not meet requirements, to better serve the company's customers
- Complaint that the software delivered contains a very high number of bugs, which make the customers' experience very unpleasant
- Complaint that it takes too long to deliver software while the competitor usually brings out new software in half the time
Identifying specific problems like these will help identify business goals and their measurements that help lead the IT improvement effort, which we address later.

Identify Business and IT Goals
Business goal:
Increase the number of customers who visit our website by 5%.
IT goals:
It should take the customers less than 1 minute to register their information.
The number of bugs should be reduced by 50%.
Business goal:
Increase the number of newly registered customers by 3% every quarter.
IT goals:
Project deadline should be reduced by 10%.
Key features should be delivered 10% times faster.

Identify Measurements
From the previous list of goals, we can identify the following as their respective measurements:
Number of unused features by users
Variance in delivery timeline



Step 2: Perform Environment Boundary Identification and Assessment

Even though the title of this book mentions IT-wide improvement, this does not mean that the whole IT department is going to be the object of an immediate and big-bang rollout. Rather, what we have seen work in the majority of cases is a phased implementation strategy that progressively takes the IT organization from an unsuccessful situation to a controlled state where the IT project is well undertaken and delivered. For this, what you will need to do first is to identify the boundary of organization that will be impacted by this IT-wide implementation.

Identify the Boundary
To do this, first meet and ask your business sponsor for the environment under her or his direction that will be the target of this IT improvement effort.

Environment Assessment
After identifying the boundary, contact everyone who will be impacted by the improvement effort, on both the business and the IT side, to find out what they think about the current situation and to gather suggestions and ideas that could help facilitate their buy-in for the success of this IT implementation effort.

Findings Summary
Because the result of the assessment could be lengthy, you are advised to sum up the findings in some sort of executive summary. Doing this will help facilitate both the discussion with the executive sponsor(s) and your own vision of what the future solution should address, in terms of key improvements from the current environment.



Step 3: Envision Scenarios and Risks

Before selecting one (best) improvement plan, experience has led us to believe that having two or three scenarios (options) is always something we would like to first come up with. Not only does this give top management and some key leaders an opportunity to see which scenario will address most of their needs, but it also provides them with an opportunity to provide input. This will, then, in turn allow them to take ownership of the solution as theirs and not that of an outsider.

In building these scenarios (options), please also remember to identify all the risks that are associated with each one of them. You should carefully point them out to the management team to ensure that they are fully aware of their impact on the future implementation.



Step 4: Detail the Chosen Action Plan

Once management and some of the key leaders have had the opporutnity to go through the pros and cons of the various scenarios (options), ask them to chose one of these scenarios or a combination of them to create a single plan from which to implement the improvement effort.



Step 5: Implement the Chosen Action Plan

Once the plan has been detailed and presented back to the management team for review, it is time to get prepared for execution.

Depending on what section of the business will be impacted by the chosen plan, the composition of the steering committee to follow up on the execution will be essential. The key thing is to make sure that the committee has access to up-to-date and accurate information for their understanding and help with removing impediments.

As the late management guru Peter Drucker often said, "Strategy is execution." What this means, in our case, is that having a plan is a good first step, but knowing how to execute it is what counts the most.



Step 6: Inspect the Implementation's Progress

As the popular saying goes, "A plan is only a plan." This is to say that we should expect some deviation from the chosen plan when it comes time to execute it. This is also to say that it is key to continuously inspect the execution's progress and remove impediments to help keep it moving.



Step 7: Adapt the Chosen Action Plan (as Needed)

While inspecting the plan's progress, you may need to make adaptations to the plan to make adjustments to the changes in the organization and surrounding business environment, depending on the level and nature of their impacts.

• 0 comments »

Data professionals, whether they go by the title of database administrators, database engineers, or something else, can be among the most resistant to adopting Scrum. Much of what the preceding section said about programmers will also be true about database administrators. Additionally, data professionals will be faced with learning how to do incrementally what has traditionally been viewed as a part of a project's up-front work.

Standard advice in database design has been to do a complete analysis of the system's needs, create a logical or conceptual database design, and then map the concepts to the constraints of a real-world database during physical database design. Success at this series of steps is predicated on a full and accurate analysis up front. The traditional data professional's view was best summed up to me by a fellow traveler on a plane from Chicago to Sacramento. He was a vice president of database development for a relatively large healthcare company. His view on the world was "applications change; data is forever."

This type of thinking leads to an intense focus on doing a complete analysis up front. This is nice in theory, but while we're taking the time to do that complete analysis, the world is continuing to evolve. Users' needs are changing. Competitors are releasing their products. Databases need to evolve to support the evolving applications built on them.

Much of a DBAs day-to-day work will not change significantly, but how the DBA approaches and schedules that work will change dramatically.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010

• 0 comments »

What do programmers do on a Scrum team? They program. They test. They analyze. They design. They do anything necessary to help the team complete the work committed to for a sprint. Although it is OK to have specialists on a Scrum team, specialists need to be willing to work outside their specialties whenever needed for the greater good of the team. There are exceptions. A game development project may, for example, benefit from specialists in artificial intelligence programming. Because of the highly specialized nature of their product, these specialists may do nothing outside their specialty. The majority of programmers on a Scrum team, however, should be willing to contribute in any number of ways to optimize the throughput of the overall team. This means they will test when necessary, sometimes program in a non preferred language, and so on.

One of the most striking changes for programmers on a Scrum team is that they can no longer sit in their cubicles and wait to be told exactly what to program. They need to become active participants in understanding product requirements. Surprisingly, there are many people who simply want to be told what to work on. I've heard this expressed as "if they tell me what to work on and I do it, then I can't be fired." Programmers on a Scrum team—like all others on the team—are expected to share in the responsibility for the overall success of the product. When this responsibility is fully felt, it is easier to do the things that go beyond one's normal job description.

Programmers will also be expected to talk to customers and users. The amount of this can be adjusted up or down based on the programmer, the organization, the strengths of other team members, and the nature of the project. Programmers do not need to develop the personalities of gregarious, glad-handing salespeople. But they do need to be comfortable occasionally talking to a user or customer, even if it's just over the phone.

Similarly, programmers can expect to spend more time interacting with their coworkers. A programmer may not be allowed to come in at 11 and clamp headphones on until quietly leaving at 7. Instead, programmers may be expected to sit in a group space, engage in discussions, help others with problems, and participate in pair programming.

These changes can be quite unsettling for the many programmers (including myself) who got into this field because we thought we could sit alone in our cubicles all day. Prior to my first programming job, I worked in a six-foot by four-foot totally enclosed dark room developing photos all day. I would pop out for regularly scheduled breaks and lunch; otherwise I was alone in the dark all day and loved it. Moving to the lighted world of cubicles was a big change. Moving from quiet cubicles to an energetic, talkative culture is an even bigger change. Programmers on a Scrum team will be expected to make this transition. Fortunately, though, the change isn't that hard for most of us. We may like to be alone, but we find participating in structured conversations (as in the meetings and decision-making discussions on a Scrum project) much easier than unstructured conversations as at a cocktail party.

Beyond the communication and interaction changes, programmers will almost certainly experience changes in how they do their work. The team may not choose to adopt all of these practices at first (or ever in some cases), but I suggest all be considered and tried.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010

• 0 comments »

Functional managers, such as development managers, QA directors, and so on, who are used to working in a matrixed manner will continue to work that way on Scrum projects. A typical functional manager will likely experience some diminution in power after the transition, but this will depend greatly on how the role was defined in the organization prior to transitioning.

Functional managers usually retain the job of assigning individuals to projects. They will be expected to continue to make these decisions based on the competing needs of all projects, project locations, developmental needs and career aspirations of individuals, and so on. In some organizations, functional managers are accustomed to going beyond assigning individuals to projects and have been involved in the assignment of tasks to individuals within their groups. They will no longer do this after transitioning to Scrum. Individual selection of work is a fundamental aspect of how the members of a team self-organize and must be left to the team.


The Leadership Role of the Functional Manager
Functional managers have always been leaders. Broad leadership trends over the years have affected individual style. While I was growing up, for example, my father managed Sears stores. This was back in the era when Sears was the world's largest retailer. My father's management style was very much top-down. He would establish goals, quotas, and other measurements; communicate them to store employees; and then measure each employee against those targets. This was also an era when prevailing wisdom was that a good manager could manage anything. My father should presumably have been able to take his experience managing a retail store and manage a bank or manufacturing operation with equal skill.

In an organization using Scrum, functional managers should operate in the
top-right quadrant, where they combine a deep understanding of the work with
a bottom-up style. A functional manager is responsible for providing guidance and coaching to members of the group. ScrumMasters and product owners also
provide guidance and coaching, but their views are limited to a single project or
product. A functional manager will have a broader perspective, including the ability
to establish cross-project standards and set expectations for quality, maintainability,
reusability, and many of the other -ilities or nonfunctional requirements.

Functional managers also retain responsibility for developing the people in their groups. Securing the budget and time to send them to conferences, challenging them with appropriate projects, and encouraging them to join or form communities of practice are all part of the functional manager's role.


Personnel Responsibilities
In most organizations, functional managers will retain responsibility for writing periodic reviews of the personnel in their departments. Although the functional manager has hopefully always incorporated input from each employee's coworkers and customers into the review, the need to do so is greater in a Scrum environment because the employee will likely be working less closely with the functional manager on a day-to-day basis.

In many organizations, functional managers also retain responsibility for making hiring and firing decisions. Neither the ScrumMaster nor the product owner has this level of authority over individuals on the product development teams.

After the organization adopts Scrum, most functional managers find themselves with more time available than they had before. This time is most often used to stay in closer touch with their direct reports, to know more about each project the group's employees are working on (by attending various sprint reviews and so on), and to pay more attention to cross-project standards and future directions.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010

• 0 comments »

On a project using a sequential development process, the project manager has the difficult job of ensuring that the product a customer wants is the one that is developed. To do this, the project manager must try to manage everything about the project, including scope, cost, quality, personnel, communication, risk, procurement, and more. Some of these responsibilities really belong to others. Scope control, for example, rightfully belongs with the customer. No one else is in the position to make the necessary trade-off decisions that will arise during product development, as priorities, team velocity, and market conditions shift. Prioritization is not a static, one-time, all-at-the-start activity that can be managed by a project manager.Yet time and again, sequential projects demand that project managers make educated guesses to deliver the right product.

On Scrum projects we acknowledge the untenable role of the project manager and eliminate it. Eliminating the role, though, does not mean we can do away with the work and responsibilities. As you might guess, since self-organizing teams are a core tenet of Scrum, a great deal of the responsibility previously shouldered by the project manager is transferred to the Scrum team. For example, without a project manager to assign tasks to individuals, team members assume the responsibility of selecting tasks themselves. Other responsibilities shift to the ScrumMaster or product owner.

Former project managers often assume one of the roles that have taken on some part of their past responsibilities—the project manager becomes either a ScrumMaster, product owner, or team member, depending on experience, skills, knowledge, and interests.

Some people became project managers because they considered it the next step in a desirable career path, yet they don't enjoy project management. These individuals miss the technical challenge of working as a programmer, tester, database engineer, designer, analyst, architect, or so on. Many of these individuals will take advantage of the elimination of the project manager role to return to work they found more satisfying.

Other project managers have used their roles to become knowledgeable about the business and its customers. A project manager in this situation will leverage that knowledge into a role as a product owner. This can be an excellent fit, especially for the project manager who is having a hard time completely relinquishing the ability to tell the team what to do. As part of their role, product owners are allowed to tell the team a bit of the "what to do" as long as they stay largely away from telling them how to do it. This can satisfy a former project manager whose nature makes it hard to stop occasionally directing the team. If a project manager can overcome the old habits of directing the team and making decisions for it, it is likely such a project manager can become a good ScrumMaster. This is the most common new role for project managers in organizations adopting Scrum. The new role will likely be difficult at first for the former project manager as she learns to bite her tongue and let the team learn how to work through its own issues and make decisions. Often, new ScrumMasters are put in the challenging position of coaching teams at something that they are not yet good at themselves—being agile. The best strategies for a ScrumMaster in this situation include the following:

• Stick as close as possible to doing Scrum by the book. Initially follow the advice of this or another Scrum book closely. Or engage an on-site trainer or coach and follow her advice to the letter. Only begin customizing the process after you have real, hands-on experience with it.

• Talk to other ScrumMasters as much as possible. If there are multiple ScrumMasters in your organization, form a community of practice with 7 5 . SEE ALSO the other ScrumMasters and share good and bad experiences. Look to . . Communities of learn by extracting lessons from commonalities among these experiences.

• Learn as much as you can as quickly as you can. Read books, articles, blogs, and websites. Look into local agile interest groups and attend their meetings. Try to attend one or more of the major agile or Scrum conferences.

Doris Ford, a software engineering manager with Motorola, was a classically trained project manager and a Project Management Professional (PMP). However, despite having a traditional background in project management, Doris's approach has always been about supporting and enabling her teams. Because of that, she was able to easily move from project manager to ScrumMaster. She writes of how her job has changed with Scrum.

Over the years in managing agile development I have learned not to sweat the task details. As a traditional project manager, I always needed to stay on top of who was doing which tasks, what were their dependencies, and would they be done on time. I spent countless number of hours just asking these questions to get the answers in attempt to meet the scope/schedule/budget/quality constraints and reporting upwards on the progress (sometimes using earned value). In an agile environment I had to learn to trust the team members that they would identify and do the tasks necessary to complete the scope for each sprint. It was hard letting go at first, but I quickly learned that the team could do this. I now spend the majority of my time supporting the team members by addressing impediments that they raise and keeping external noise from diverting their focus.


Why the Title Change?
If it's possible for a project manager to become a team's ScrumMaster or product owner, why do we need to change the person's title? Let's consider the term ScrumMaster. Years ago, when I first started running Scrum projects, the term ScrumMaster didn't exist, and it never dawned on me to call the role anything but project manager. This worked well enough. But, I was hiring new individuals into these roles; I was clear with these new hires about my expectations for how they'd interact with the team. I avoided domineering, command-and-control-style individuals. Also, these new project managers reported to me, which allowed me a lot of influence over how they interacted with their teams. Calling them project managers worked fine.

As our company continued to succeed and grow, we began to acquire other companies. In those companies I would inherit project managers who sometimes did have very traditional mindsets about the role of the project manager. I was confronted with helping them shift that mindset to one more compatible with agile development. I found this much harder than just hiring project managers with a collaborative approach suitable to self-organizing teams.

Years later in a discussion with Ken Schwaber, he helped me understand why transitioning existing project managers had been more difficult than I had anticipated. Schwaber informed me that by allowing the project managers to retain their titles, I was allowing them to think that the changes were less allencompassing than they were. He invented the word ScrumMaster in 1997 in part because it would remind everyone that this was not just the project manager role with a few additional responsibilities removed or added. Schwaber told me that "the vocabulary of Scrum is a vocabulary of change. The words are often intentionally ugly—burndown, backlog, ScrumMaster—because they remind us that change is occurring."

Although I recommend it, you do not necessarily need to banish the title project manager. If you or your organization is enamored of it, continue to use it. But be mindful of Ken Schwaber's advice and my experience that using the old words will slow or prevent the adoption of the new approach. Retaining an old title discourages thinking in the new way. Further, if people are unwilling to relinquish something as insignificant as a j ob title, they will probably also be unwilling to make the far harder changes necessary to adopt Scrum.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010

• 0 comments »

With an intimate knowledge of the product and strong communication skills, some analysts will tend to shift into product owner roles. This is especially common on large projects that make use of a hierarchy of product owners. Someone with product manager on her business card, for example, may act as the chief product owner for the overall product, spending most of her time looking outward at users and the market. An individual with analyst on her business card, on the other hand, may act as product owner for the various teams, working with the chief product owner to translate her vision into product backlogs for her teams.

Many teams find that having an analyst on the team continues to be very beneficial, although the ways in which the analyst works will change. On traditionally managed projects, the analyst's mission seemed to be to get as far ahead of the team as possible. On a Scrum project, just-in-time analysis becomes the goal. The analyst's new aim is to stay as slightly ahead of the team as possible while still being able to provide useful information to the team about current and near-term features.

Analysts can be instrumental in achieving the goal of shifting the emphasis from writing about requirements to talking about them. Because analysts are not working as far ahead of the team as they may be used to, they need to become more comfortable sharing information with the team more informally, rather than through a large document. As much information as possible should be shared through verbal discussion, but analysts will still need to document some requirements, especially when working on a distributed team. Often though, what the analyst writes will be less formal—more often a wiki than a document with a signature page.

On traditional projects, analysts often become intermediaries through whom other team members and the product owner communicate. On a Scrum project the analyst should become more a facilitator of team-product owner discussion than an intermediary. Team members and product owners need to talk. Rather than be the conduit for all conversation, the good agile analyst focuses on making sure those conversations are as productive as possible given the time constraints the team or product owner may be under. This may mean that the analyst steers the product owner and team toward talking about one user story rather than another because that is where there is more risk of going astray. Or it may mean that the analyst conveys a top-level understanding of a new feature to the team before bringing the team and product owner together to discuss the details.

On a traditional project, an analyst may say to the team,"I've talked to our key stakeholder, understand what he wants, and have written this document describing it in detail." By contrast, on a Scrum project, the same analyst should say, "I've spoken to our product owner and have a feeling for what he's after. I wrote these six user stories to give you a start, and I've got a bunch of additional questions to ask the product owner. But I want to make sure that I bring along a couple of you when we have those discussions."

With all this talk of analysts looking ahead, it can be tempting to think that analysts work a sprint ahead of the team. They don't. Gregory Topp, an analyst with Farm Credit Services of America, describes how using Scrum has allowed him to concentrate on the current sprint: "Before Scrum, I had to focus on requirements that were not going to be developed for several weeks, if not months. Now, I focus on the current sprint (two weeks for us), so more time can be spent on user story details, development, and testing." An analyst's first priority is to achieve the goals of the current sprint. An analyst on a Scrum team will assist in testing, will answer questions (or track down answers to questions) about features being developed, will participate fully in all regular sprint meetings, and so on.

However, it is quite possible that these activities will not fully consume the analyst's time. Time that is not needed to complete the work of the current sprint can be used to look ahead. However, being a part of the team on this sprint and spending some time looking ahead is not the same as working a sprint ahead of the team. Topp explains how jumping too far ahead actually put him behind: "I tried working ahead a sprint or two, defining user story details. I found that this caused the current sprint to suffer. I also found that many times the details of a user story changed by the time the team actually started working on the story."

A common question is whether the effort analysts spend looking ahead should be included on the sprint backlog. My recommendation is to include on the sprint backlog any specific analysis tasks that can be identified during sprint planning. For example, suppose the team is working on an application that approves or rejects loan applications. If the product owner and team agree that the next sprint will include work on calculating the applicant's credit score, then preliminary analysis tasks related to that should be identified, estimated, and included in the sprint backlog. On the other hand, if the next sprint's work is unknown, no specific tasks related to the next sprint should be included on the sprint backlog. Overall, many analysts enjoy the change to Scrum even though they relinquish the role of sole interpreter of customer desires. Two years after adopting Scrum, Topp commented on how his relationship with others on the team had changed.

Because we are all on the same team and all work on the same user stories at the same time, the team seems to have more unity. Before using Scrum, it seemed each function (analyst, programmer, tester, DBA) was done in a silo. There was more fingerpointing when in that mode. Now using Scrum, the team is all focused on a small set of stories. The finger-pointing has been eliminated with an "as a team" mindset.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010

• 0 comments »

There are many potential pitfalls when selecting the initial product owner. Some of the most common early-stage problems and what you can do to address them include


The product owner delegates decision making but then overrules the decision maker. To fit the new duties of the product owner into their schedules, some
product owners delegate decisions about specific parts of the product. Other
product owners enlist a business analyst to be a "feature owner" over some part
of the system. This can work well because the product owner has more time to
dedicate to areas that are not as easy to delegate.

Problems arise when the product owner says that decision-making authority has been delegated but then continues to approve or sometimes reverses decisions. Before delegating, product owners should be sure they are really willing to delegate without later second-guessing. Because of the pressure of the short, timeboxed sprints, Scrum teams often move much more quickly than they did before transitioning. It is inevitable that some decisions that the product owner delegates will turn out to be wrong, and these should be revisited. What we want to avoid, however, are situations where the product owner says,"Get your answers from Dave; he owns this part of the system," and then consistently overrules Dave's answers.

My advice to a new and overloaded product owner is to free some time by delegating just beyond the point at which you're comfortable. You may be pleasantly surprised and find no important decisions to reverse. But you'll occasionally find some decisions you would have made differently. Often the best thing to do in this case is the same thing we're all taught when learning to drive: If the car starts to slide, steer into the slide. Rather than pull against the decision (assuming it is not a horrendous one), allow that decision to persist through the end of the sprint; then decide if it should be changed. When the cost of reversing a decision is compared against all the other valuable work on the product backlog, you may find that the decision wasn't so bad after all.


The product owner pushes the team too hard. Product owners are often under pressure to deliver financial results to the company; more features delivered sooner is one way for them to achieve it. As I've said, I have no objection to a product owner who announces at the start of a project, "We need to build a product that is smaller, better-performing, and cheaper than our competitor's, and we need to do it in three months less than we spent on the last product." As long as a challenging goal like that is accompanied by appropriate freedom in how the goal is achieved, the team will do its best. The problems arise when the team is kept under constant and changing pressure from sprint to sprint. One difficult goal of "do this amazing thing in 6 months" is in many ways less stressful for the team than 13 successive two-week sprints of "I need more, more, more!" If you have product owners who are pushing teams this way, the ScrumMasters should first push back and then work with the product owners to set longer-term goals for the teams while ensuring teams have commensurate degrees of freedom in how those goals are achieved.


The product owner wants to cut quality. Cutting quality is an oh-so-tempting decision when trying to deliver a challenging set of features by a difficult date. It can lead to the short-term appearance of having met the objectives established at the start of the project. Eventually, however, the cost of having cut quality becomes apparent as more post-release bugs than usual are reported, the team's velocity decreases, and customers clamor for the product to behave as they thought it would.

Ken Schwaber has called quality a "corporate asset" (2006). As such, no one except the chief executive has the authority to sacrifice quality in exchange for achieving a short-term goal such as making a release date. A decision to cut quality may be the appropriate one; I can't tell you otherwise without knowing the full context of a situation. But, that decision is one that needs to be made sufficiently high up in the organization and with such openness that no one is surprised by the negative impacts that will almost certainly follow

Selecting product owners who understand this is sometimes challenging in organizations that are consistently focused on this quarter's numbers. Pushing back against attempts to reduce quality is the job of the ScrumMaster. The ScrumMaster does not need to prevail in these early disagreements. The ScrumMaster does, however, have to succeed in making the decision visible.

Time is on the ScrumMaster's side. If the ScrumMaster successfully raises the visibility of decisions to cut quality, he should eventually be able to win later arguments against reducing quality. "Remember on the Gouda project how I told you that cutting quality on version one would hurt us during version two?" the ScrumMaster can say. "Well, here are the graphs of velocity on the two projects. Note that version two had a lower velocity even though we added two experienced people. That was because we left bugs behind during version one (here's a graph showing that) and because the team didn't feel it had the time to do a good job of keeping its code clean. We even skipped the automated unit tests on a few modules. Here's a comparison of the number of defects found during the six months following release, broken down by whether the module had automated unit tests. It's up to you if we do this again on this project, but I think you know my opinion."


Our product owner is in a different city than the development team. With more projects being developed by remote teams, this is an increasingly common situation. Both the team and product owner in this situation should assume some of the burden of over communicating with the other. I have worked with many remote product owners, and it can work very successfully as long as the product owner does the following:
• Remains engaged in the project
• Establishes a rapport with the team
• Performs all usual duties of the role
• Is available to the team for phone calls for at least some part of the day, even if it is after the usual workday for the product owner
• Responds by e-mail or phone when not available in person

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010

• 0 comments »

As when describing what to look for in selecting or hiring a good ScrumMaster, I've culled the long list of desirable product owner traits down to five must-have attributes.

Available. By far the most frequent complaint I hear from teams about their product owners is that they are unavailable when needed. When a fast-moving team needs an answer to a question, waiting three days for an answer is completely disruptive to the rhythm it has established. By being available to the team, a product owner demonstrates commitment to the project. The best product owners demonstrate their commitment by doing whatever is necessary to build the best product possible. On some projects this includes doing things like assisting in test planning, performing manual tests, and being actively engaged with other team members.

Business -savvy. It is essential that the product owner understand the business. As the decision maker regarding what is in or out of the product, the product owner must have a deep understanding of the business, market conditions, customers, and users. Usually this type of understanding is built over years of working in the domain, perhaps as a past user of the type of product being developed. This is why many successful product owners come from product manager, marketing, or business analyst roles.

Communicative. Product owners must be good communicators and must be able to work well with a diverse set of stakeholders. Product owners routinely interact with users, customers, management within the organization, partners, and, naturally, others on the team. Skilled product owners will be able to deliver the same information to each of these different audiences while at the same time tailoring their message to best match the audience. A good product owner must also listen to users, customers, and perhaps most important the team. Especially as team members learn more about the product and market (as they should over time, especially on a Scrum project), they will be able to offer valuable suggestions about the product. Additionally, all teams will have much to say to the product owner about the technical risks and challenges of the project. Although it is true that the product owner prioritizes all work for the team, the wise product owner will listen to her team when it recommends some adjustments in those priorities based on technical factors.

Decisive. Another common complaint teams make about their product owners is their lack of decisiveness. When team members go to the product owner with an issue, they want a resolution. Scrum puts a lot of pressure on teams to produce functionality as quickly as possible. Teams are frustrated when a product owner responds to a question with, "Let me call a meeting or convene a task force to work on that." A good team will understand that this is sometimes necessary, but teams are very perceptive at knowing when a product owner is actually just trying to avoid making a hard decision. Just as bad as a product owner who won't make a decision is the product owner who makes the same decision over and over but with different answers. A good product owner will not reverse prior decisions without a good reason.

Empowered. A good product owner must be someone empowered with the authority to make decisions and one who is held accountable for those decisions. The product owner must be sufficiently high up in the organization to be given this level of responsibility. If a product owner is consistently overruled by others in the organization, team members will learn to go to those others with their important questions.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010

• 0 comments »

The Agile community is a tightly knit and extremely supportive group of professionals who are passionate about using – and refining – Agile practices and techniques to provide the greatest benefit to their organizations. The only problem is that the work that they do – and the language that they use – has been so heavily focused on two specific sectors (IT and manufacturing) that other industries have had minimal exposure to the benefits of these approaches.

For example, books on Agile project management techniques have focused, almost exclusively, on how these approaches can improve software development projects, even though much of the content could be equally applied to any time-, cost- or resource-constrained project work in other industry sectors.

This focus on industry-specific activities is, arguably, a primary reason why these exceptionally dedicated Agile practitioners have often had a difficult time convincing senior management within their own organizations to support these approaches – let alone convincing clients in other organizations. This lack of management support has often meant that the adoption of Agile approaches within an organization has needed to come from a series of smaller successes in “grass-roots” work (i.e. “Agile-by-stealth”), instead of a collaborative initiative between staff and

management.

In addition to an overall lack of awareness about Agile approaches, there may be other factors that would make an organization initially hesitant to adopt these approaches, including:

» Technical terminology: much of the language that is currently used to describe Agile practices and techniques (e.g. Test-Driven Development) is quite specific to the IT and manufacturing industries, which makes it more difficult for people to see the potential beyond these two industries. Also, some of the terms used (e.g. eXtreme Programming) can create the impression that these are “rogue” practices instead of proven approaches.

» Agile myths: rumors about Agile approaches that have grown from misunderstanding. For example, the mistaken impression that using Agile approaches means no documentation when, in actuality, it means using more effective communication channels to work together (e.g. face-to-face communication) and using

documentation where required to record the outcomes of

this work.

» Misapplication: there are instances where an organization has endeavored to apply Agile approaches in the past, without fully understanding the underlying principles. For example, an organization that moves to an “Agile” iteration-based project management model, but still requires all of the work to be signed-off in an upfront specification. Truly Agile organizations

understand that responsive planning is only valuable when the organization is in a position to adapt ongoing work as it progresses. Otherwise, iterative work just becomes shorter delivery cycles that are limited by the same core constraint; and Agile approaches get an unjustified bad reputation when this pre-constrained process inevitably fails.

» Trusting employees: at the heart of Agile approaches is the firm belief that people can – and will – do the right thing by the organization if they are given the opportunity. If the senior management of an organization sees employees as unmotivated people who have to be

supervised closely in order to get any work done, they will be far less willing to entrust delivery teams to selfmanage. The irony is that these same managers rarely appreciate that a corporate culture of mistrust breeds unmotivated people.

» “Business as usual” mindset: there is no doubt that Agile approaches require organizations to act – and think – differently to the way that they have in the past. Those organizations which are self-aware (and humble) enough to recognize that their business practices of the past may not sustain them into the future, will be more amenable to considering Agile approaches, especially given their

widespread support and long history of success. In contrast, executives who are committed to “the way we do things around here” are likely to see Agile approaches as too radical for their organization. The bottom line is that Agile approaches are a significant change in the way in which organizations operate – but change can be for the better.

The previously referenced statistics from Forrester and VersionOne identified that organizations are both aware of Agile approaches and are receiving benefits from their use of these approaches. To date, these statistics have predominantly been focused on the experience of organizations in the IT industry, but they are good indicators that Agile approaches really do result in positive outcomes for the organizations that are forward-thinking enough to apply them. So, the most likely reason for the

limited uptake of Agile approaches outside the IT and manufacturing industries, is simply that organizations in other industries may not be aware that they, too, could achieve real productivity gains from these approaches.

Source of Information : IT Governance Publishing-Agile Productivity Unleashed 2010

• 0 comments »

Agile approaches are designed to provide organizations with a combination of the immediate benefits of having fitfor-purpose outputs, as well as a number of long-term benefits for the organization overall, including:

» more efficient business processes
» reduced overheads in ongoing service and productbdelivery
» greater customer satisfaction
» stronger competitive advantage
» higher employee retention rates.

The success of Agile approaches creates a dynamic in theborganization that feeds off itself. Departments arebencouraged to interact and communicate with each otherbmore often, which means that an iteration planning sessionbwhich was intended to identify upcoming work can also
become a forum where staff exchange organizationalbinformation and share ideas. Employees feel morebempowered to influence and improve the organization,bwhich motivates them to proactively think about other waysbin which their work can be done more efficiently. Everyonebinvolved in the process gets the satisfaction of seeing realboutcomes from their work, which can create anbenvironment that is focused on outcomes delivery insteadbof paperwork generation.

All of these factors mean that Agile approaches can create abclimate of productivity, delivery and possibility that willbbetter position the organization to respond to inevitablebinternal and external changes. This can create a morebsustainable environment to move the organization forwardbin a service-driven global marketplace.

Source of Information : IT Governance Publishing-Agile Productivity Unleashed 2010

• 0 comments »

In the same way that Agile approaches protect the organization from the risk of large upfront commitments, they also do not require a large upfront commitment from the organization in order to be used.

Agile approaches are not highly regimented management structures that require hundreds of staff to attend workshops (and receive doorstops of documentation) before they can be used in the organization. You can immediately apply many of the core Agile approaches (and principles) described in this book to your current business activities, without attending week-long training courses, acquiring mounds of manuals, or enlisting the services of high-end consulting firms.

That is not to say that organizations cannot benefit from more formal guidance on adopting and applying Agile approaches. The IT industry, for example, has benefited greatly by having formal training and certification courses to teach people how to more effectively apply Agile methods (such as Scrum) in their software development projects. As the adoption of Agile approaches grows and matures in your organization, you can refine your use of Agile by enlisting qualified consultants, attending training courses and reading industry-specific resources, such as those listed in the Bibliography.

Equally, Agile approaches do not require a significant upfront commitment from internal and external stakeholders. For Agile approaches to succeed, stakeholders minimally need to be available to guide and review the outputs of each iteration. Generally, this is no more than eight hours of their time each iteration (i.e. every two to four weeks). Their active involvement throughout the delivery process can substantially reduce the time that is normally required of them at the end of the process to address problems in the deliverables that they received. All of this can make trialing Agile approaches in an organization a cost-contained activity, which the organization can opt to extend (or reduce) without having jeopardized a significant upfront investment. The downside, of course, is that employees will not have the opportunity to bury their “certificates of completion” for the latest cure-all management trend in the mounds of paperwork on their desks, but that is a risk that most organizations will happily absorb.

Source of Information : IT Governance Publishing-Agile Productivity Unleashed 2010

• 0 comments »

One of the key business benefits to Agile approaches is their ability to protect the organization from controllable risk. Market fluctuations, employee turnover and variable resource levels are all factors that, to a large extent, organizations cannot control. However, an organization can control the way in which it plans for – and responds to – these risk factors.
Each Agile principle works in a different way to protect organizations from controllable risk, but these principles also complement each other.


Responsive planning
Every time an organization commits financial, human or physical resources to a business activity, it is taking a calculated risk that the cost of supplying these resources will provide a significant enough return to justify the initial expenditure. The more that these resources are committed upfront, the greater the risk to the organization that the intended outcomes will not yield the level of return that was anticipated if circumstances change. The ideal position for an organization is to undertake a moderate upfront investment in time, money and resources, and then monitor the ongoing return on that investment before additional resources are committed.

Responsive planning is designed to enable organizations to commit small amounts of resources towards their objectives, monitor the progress of these resources against both internal and external influencing factors, and adjust the ongoing commitment based on the most current information available. This does not eliminate the potential for unforeseen issues to affect the work that is being done, but it minimizes the impact of these issues when they arise.

Frequent and continuous business value Even when Agile work is stopped due to unforeseen risks, the initial commitment that the organization made can be partially (or fully) recoverable. Agile approaches require delivery teams to produce high business value outcomes in every iteration, such as:

» sales reports that include real customer data
» working (and releasable) website functionality
» efficiencies to business processes that have been applied (and measured) in live conditions.

These are not thought papers or conceptual discussions, they are tangible outputs that the organization can continue to utilize, even if the Agile work is postponed or stopped altogether. (If you stopped the year-long projects in your organization after three months, how many of them would be able to deliver more than a pile of project plans and status reports?)

Agile approaches enable the upfront investment that the organization has made to deliver at least a portion of the intended returns. Moreover, because that portion represents the highest-priority work for the organization, there are times when receiving only these initial outcomes is sufficient for the organization to have achieved its intended objectives.


Direct stakeholder engagement
One of the biggest risks that organizations take is the assumption that the work that they are doing will meet the needs of the intended audiences. The further removed work is from the people that require these outputs, the greater the likelihood that these outputs will be misaligned. At a minimum, this means that the organization is risking absorbing the cost of rework (or discarded work); in more critical circumstances, it means that the organization is risking market share, customer loyalty, staff productivity and employee retention.

In any competitive marketplace, there is always the risk that other organizations will deliver a product or service that is more appealing to audiences. Equally, there is always the risk that customer needs will change over time. The differentiator here is controllable risk.

Agile approaches encourage the direct involvement of internal and external stakeholders so that, to the largest extent possible, their input will reflect their most current requirements, including:

» the most up-to-date information that staff members have about the organization (e.g. resource availability, changes in corporate direction)
» hands-on feedback on whether (or not) interim deliverables are meeting the needs of internal staff
» input from external customers on their projected shortand long-term future needs
» the most current information that both internal and external stakeholders have about competing products and services.

Although this does not guarantee that every possible requirement will be known in advance, it significantly shortens the window of time between when the organization identifies a need, and when it delivers the outcomes that are intended to address that need.


Regular face-to-face communication
In the same way that direct stakeholder engagement reduces the risk of business requirements not being known, face-toface communication reduces the risk of business requirements not being understood. One of the biggest factors in the failure of IT projects in the 1990s was insufficient communication. This was particularly evident in both the reliance upon upfront documentation to articulate business requirements, and the isolation of the staff members who were doing the work from the business areas that required the outcomes.

Even when organizations involve internal and external stakeholders in the identification of requirements, the value of their involvement is directly correlated to how well the people who are doing the work clearly understand what is needed. This is particularly true when the people who are doing the work do not have the same level of specialist business knowledge as the stakeholders. The more that the business requirements are misinterpreted, the greater the risk to the organization of rework and discarded work.

Regular face-to-face communication not only ensures that work will not be done in isolation of the people who best understand the business requirement. It also minimizes the potential for employees to act on the assumptions or misinformation that can arise from the one-way
communication channel of documentation. Combining regular face-to-face communication with tangible outputs in fixed iteration timeframes can remove this ambiguity (and the corresponding risk) altogether.


Minimizing waste
Until now, the focus of risk management through the use of Agile approaches has been on risk mitigation by minimizing upfront commitments in planned business activities. Included in this, is waste management by reducing the risk of resources over-producing (or going too far off-track) before their work is contained. There is also an equivalent ongoing risk when organizations allocate
resources for business processes that are inefficient.

Maximizing resource utilization involves giving staff the tools that they need to get the work done. In the same way that faulty equipment can stop a production line from moving forward, ineffective communication channels, lowquality outputs and excess movement can bring work to a virtual standstill. Organizations not only risk productivity leakages in these inefficient processes, they also risk delays in deliverables and employee frustration.


Tangible outputs
The requirement for delivery teams to produce tangible outputs in each iteration, provides significant risk mitigation beyond the ongoing business value that these outputs provide; it also reduces the potential for theoretical concepts (or prototypes) to oversimplify the work that is required for production-level deliverables to be generated. This can include everything from a physical product that takes more money to produce than the prototype indicated, through to mock-ups of corporate reports that cannot actually be produced because the information required is unavailable (or too costly to acquire). The more information that an organization has about the real costs involved in producing a required output, the better positioned the organization is to determine whether ongoing investment is justified.


Empowering the team
The very nature of Agile work provides employees with levels of satisfaction and self-motivation that go far beyond what they can get from traditional approaches to work. With Agile approaches, teams have input into the estimation and planning process. They can see tangible outputs of their work on a regular basis. They can interact directly with the stakeholders to avoid wasted effort and rework. They can produce business value instead of writing up status reports. Furthermore, because management is able to see the outputs of their work in short timeframes, these teams often get a level of independence and trust that is generally not available to them in the workplace. Selfmotivated and empowered teams are a critical part of the success of Agile approaches, and the rewarding nature of Agile work creates an ongoing source of motivation for employees, which reduces the risk of staff turnover.


Quality by design
The direct (and indirect) costs of low-quality outputs can put an organization in a greater position of risk than even the most inefficient business process. Internally, organizations risk lost resource time as defects are addressed and outputs reproduced. Externally, organizations risk their reputation in the marketplace and ongoing customer loyalty.

Agile approaches mitigate this risk by putting active checkpoints in place throughout the process to confirm (to the largest extent possible) that ongoing work is delivering high-quality results for stakeholders. These approaches further mitigate the risk of low-quality outputs by encouraging continuous improvement throughout the process, including simplified (and more sustainable) business processes. This positions the organization to not only identify risk, but to be able to respond more quickly, and cost-effectively, to any unexpected issues that arise.

Individually, each of these Agile principles has the ability to protect organizations from some degree of risk. When they are combined in Agile approaches, however, the level of risk mitigation for the organization increases significantly – and, when they are used systematically across the organization, the level of protection from risk can increase exponentially.

Source of Information : IT Governance Publishing-Agile Productivity Unleashed 2010

• 0 comments »

Agile approaches have been successfully used by hundreds of organizations worldwide, most notably in the United States and Europe. Although the list of companies which are currently using Agile approaches covers a range of industry sectors, the vast majority of these organizations have only adopted Agile approaches in their software development activities to date. Therefore, market research related to Agile approaches has been generally undertaken only in this context.

Forrester’s September 2006 survey of technology decision makers27 identified that 17% of North American and European businesses use Agile practices, while another 29% are aware of them. A more recent survey undertaken by VersionOne28 indicates that organizations that use Agile
approaches are achieving increased productivity (80% of respondents), faster time to completion (64% of respondents) and improved ability to manage changes in requirements (90% of respondents).

Over the past five years, a number of prominent IT organizations have actively promoted their use of Agile throughout the industry by publishing case studies and experience reports. Selected examples of these are provided in the following sections:


Yahoo!
Gabrielle Benefield has been a highly prominent figure in the Agile arena, having championed the use of Agile practices within Yahoo! since 2005. Ms Benefield, who was the Senior Director of Agile Development at Yahoo!, advises that Yahoo! has “more than 200 teams using Agile development processes to create software for the highly volatile general-public Web application market” where they “can easily get 200 to 300 percent productivity improvements.” Yahoo! is an avid user of the Scrum method of Agile project delivery, including the use of user stories to confirm their customers’ requirements. In Yahoo!’s approach to Agile, “active stakeholder involvement” is getting feedback on proposed features from their millions of customers, and refining their products based on customer input prior to full release. One of the co-founders at Yahoo! said that “Agile has been one of the most positive things to happen to the company.”


Nokia Siemens Networks
Petri Haapio has lead Lean and Agile transformation in some of the world’s largest organizations, including Nokia Siemens Networks. Petri advised that over 40 products at Nokia Siemens Networks have used Agile software development practices with projects undertaken in one- to four-week time-boxed iterations. These products employed a range of Agile practices, including Scrum, continuous integration, testdriven development, pair programming, refactoring and multi-skilled teams. Petri further advised that Nokia Siemens Networks’ primary drivers for moving to Agile practices were:
» to be more responsive to changes in the business environment
» to increase productivity and quality
» to increase customer satisfaction by focusing on the most value added features first
» to establish a culture that is focused on continuous improvement.
In Petri’s work with Nokia Siemens Networks, Agile product development has involved teams with 10 people working in a single location, to teams with 500 people working from multiple locations and across multiple time zones.


BT
Agile practices have become a central part of BT’s transformed ways of working. The move away from traditional waterfall methods in BT Innovate & Design − which designs and develops all BT’s technology − has come as telecommunications networks have become more software driven. Agile became the logical approach to take. At the start, five years ago, a comprehensive training and education regime was put in place. BT developed “The BT Agile Cookbook, an online guide to Agile delivery as applied to BT” which recognized five core Agile practices:
» customer involvement
» user stories
» iterative development
» automated testing
» continuous integration.
In addition, BT instituted a program for pairing Agile coaches within the organization to exponentially increase their training activities, and established learning events such as The Agile Road Show, Agile Program Days and Agile Learning Projects. The five core practices and the Agile approach are now completely embedded in the operating model that BT uses to design and develop its networks, and the products and services it offers to its customers.

Source of Information : IT Governance Publishing-Agile Productivity Unleashed 2010

• 0 comments »

As when describing what to look for in selecting or hiring a good ScrumMaster, I've culled the long list of desirable product owner traits down to five must-have attributes.

Available. By far the most frequent complaint I hear from teams about their product owners is that they are unavailable when needed. When a fast-moving team needs an answer to a question, waiting three days for an answer is completely disruptive to the rhythm it has established. By being available to the team, a product owner demonstrates commitment to the project. The best product owners demonstrate their commitment by doing whatever is necessary to build the best product possible. On some projects this includes doing things like assisting in test planning, performing manual tests, and being actively engaged with other team members.

Business -savvy. It is essential that the product owner understand the business. As the decision maker regarding what is in or out of the product, the product owner must have a deep understanding of the business, market conditions, customers, and users. Usually this type of understanding is built over years of working in the domain, perhaps as a past user of the type of product being developed. This is why many successful product owners come from product manager, marketing, or business analyst roles.

Communicative. Product owners must be good communicators and must be able to work well with a diverse set of stakeholders. Product owners routinely interact with users, customers, management within the organization, partners, and, naturally, others on the team. Skilled product owners will be able to deliver the same information to each of these different audiences while at the same time tailoring their message to best match the audience. A good product owner must also listen to users, customers, and perhaps most important the team. Especially as team members learn more about the product and market (as they should over time, especially on a Scrum project), they will be able to offer valuable suggestions about the product. Additionally, all teams will have much to say to the product owner about the technical risks and challenges of the project. Although it is true that the product owner prioritizes all work for the team, the wise product owner will listen to her team when it recommends some adjustments in those priorities based on technical factors.

Decisive. Another common complaint teams make about their product owners is their lack of decisiveness. When team members go to the product owner with an issue, they want a resolution. Scrum puts a lot of pressure on teams to produce functionality as quickly as possible. Teams are frustrated when a product owner responds to a question with, "Let me call a meeting or convene a task force to work on that." A good team will understand that this is sometimes necessary, but teams are very perceptive at knowing when a product owner is actually just trying to avoid making a hard decision. Just as bad as a product owner who won't make a decision is the product owner who makes the same decision over and over but with different answers. A good product owner will not reverse prior decisions without a good reason.

Empowered. A good product owner must be someone empowered with the authority to make decisions and one who is held accountable for those decisions. The product owner must be sufficiently high up in the organization to be given this level of responsibility. If a product owner is consistently overruled by others in the organization, team members will learn to go to those others with their important questions.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010

• 0 comments »

Today's surgeons are highly trained and skilled individuals who have had years of formal education followed by extensive internships. This was not always the case. Pete Moore has written that "the first surgeons had little anatomical knowledge, but plied their trade because they had sharp instruments and strong arms. They often did surgery in their spare time while working as the local barber or blacksmith".

Many organizations choose their first ScrumMasters in much the same way; but instead of seeking sharp instruments and strong arms, they look for management or leadership experience. As they become more experienced with Scrum, organizations eventually realize there are many more factors to consider in selecting ScrumMasters. To help save you from picking a ScrumMaster whose sole qualifications are strong arms and sharp instruments, I have listed the six attributes I have found to be common among the best ScrumMasters I've worked with.


Responsible
A good ScrumMaster is able and willing to assume responsibility. That is not to say that ScrumMasters are responsible for the success of the project; that is shared by the team as a whole. However, the ScrumMaster is responsible for maximizing the throughput of the team and for assisting team members in adopting and using Scrum. As noted earlier, the ScrumMaster takes on this responsibility without assuming any of the authority that might be useful in achieving it. Think of the ScrumMaster as similar to an orchestra conductor. Both must provide real-time guidance and leadership to a talented collection of individuals who come together to create something that no one of them could create alone. Boston Pops conductor Keith Lockhart has said of his role, "People assume that when you become a conductor you're into some sort of a Napoleonic thing— that you want to stand on that big box and wield your power. I'm not a power junkie, I'm a responsibility junkie". In an identical manner, a good ScrumMaster thrives on responsibility—that special type of responsibility that comes without power.


Humble
A good ScrumMaster is not in it for her ego. She may take pride (often immense pride) in her achievements, but the feeling will be "look what I helped accomplish" rather than the more self-centered "look what I accomplished." A humble ScrumMaster is one who realizes the job does not come with a company car or parking spot near the building entrance. Rather than putting her own needs first, a humble ScrumMaster is willing to do whatever is necessary to help the team achieve its goal. Humble ScrumMasters recognize the value in all team members and by example lead others to the same opinion.


Collaborative
A good ScrumMaster works to ensure a collaborative culture exists within the team.The ScrumMaster needs to make sure team members feel able to raise issues for open discussion and that they feel supported in doing so. The right ScrumMaster helps create a collaborative atmosphere for the team through words and actions. When disputes arise, collaborative ScrumMasters encourage teams to think in terms of solutions that benefit all involved rather than in terms of winners and losers. A good ScrumMaster models this type of behavior by working with other ScrumMasters in the organization. However, beyond modeling a collaborative attitude, a good ScrumMaster establishes collaboration as the team norm and will call out inappropriate behavior (if the other team members don't do it themselves).


Committed
Although being a ScrumMaster is not always a full-time job, it does require someone who is fully committed to doing it. The ScrumMaster must feel the same high level of commitment to the project and the goals of the current sprint as the team members do. As part of that commitment, a good ScrumMaster does not end very many days with impediments left unaddressed. There will, of course, be times when this is inevitable, as not all impediments can be removed in a day. For example, convincing a manager to dedicate a full-time resource to the team may take a series of discussions over several days. On the whole, however, if a team finds that impediments are often not cleared quickly, team members should remind their ScrumMaster about the importance of being committed to the team. One way a ScrumMaster can demonstrate commitment is by remaining in that role for the full duration of the project. It is disruptive for a team to change ScrumMasters mid-project.


Influential
A successful ScrumMaster influences others, both on the team and outside it. Initially, team members might need to be persuaded to give Scrum a fair trial or to behave more collaboratively; later, a ScrumMaster may need to convince a team to try a new technical practice, such as test-driven development or pair programming. A ScrumMaster should know how to exert influence without resorting to a dictatorial "because I say so" style. Most ScrumMasters will also be called upon to influence those outside the team. For example, a ScrumMaster might need to convince a traditional team to provide a partial implementation to the Scrum team. Or, a ScrumMaster might need to prevail upon a QA director to dedicate full-time testers to the project. Although all ScrumMasters should know how to use their personal influence, the ideal one will come with a degree of corporate political skill. The term "corporate politics" is often used pejoratively; however, a ScrumMaster who knows who makes decisions in the organization, how those decisions are made, which coalitions exist, and so on can be an asset to a team.


Knowledgeable
Beyond having a solid understanding of and experience with Scrum, the best ScrumMasters also have the technical, market, or other specialized knowledge to help the team pursue its goal. LaFasto and Larson have studied successful teams and their leaders and have concluded that "an intimate and detailed knowledge of how something works increases the chance of the leader helping the team surface the more subtle technical issues that must be addressed" . Although ScrumMasters do not necessarily need to be marketing gurus or programming experts, they should know enough about both to be effective in leading the team.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010

• 0 comments »

Much has already been written about the job of the ScrumMaster in removing impediments to the team's progress (Schwaber and Beedle 2001, Schwaber 2004). Most ScrumMasters quickly grasp that part of their job. Where many falter— especially during the critical first 6 to 12 months of using Scrum—is in their relationships to their teams, which is why we will focus on that topic here.

Many who are new to the ScrumMaster role struggle with the apparent contradiction of the ScrumMaster as both a servant-leader to the team and also someone with no authority. The seeming contradiction disappears when we realize that although the ScrumMaster has no authority over Scrum team members, the ScrumMaster does have authority over the process. Although a ScrumMaster may not be able to say, "You're fired," a ScrumMaster can say, "I've decided we're going to try two-week sprints for the next month." Ideally, the ScrumMaster tries to get team members to decide this on their own. But, if they do not, the ScrumMasters authority over the process allows for this decision.

The ScrumMaster is there to help the team in its use of Scrum. Think of the help from a ScrumMaster as similar to a personal trainer who helps you stick with an exercise regimen and perform all exercises with the correct form. A good trainer will provide motivation while at the same time making sure you don't cheat by skipping a hard exercise. The trainer's authority, however, is limited. The trainer cannot make you do an exercise you don't want to do. Instead, the trainer reminds you of your goals and how you've chosen to meet them. To the extent that the trainer does have authority, it has been granted by the client. Scrum-Masters are much the same: They have authority, but that authority is granted to them by the team.

A ScrumMaster can say to a team, "Look, we're supposed to deliver potentially shippable software at the end of each sprint. We didn't do that this time. What can we do to make sure we do better the next sprint?" This is the Scrum-Master exerting authority over the process; something has gone wrong with the process if the team has failed to deliver something potentially shippable. But because the ScrumMaster's authority does not extend beyond the process, the same ScrumMaster should not say, "Because we failed to deliver something potentially shippable the last sprint, I want Tod to review all code before it gets checked in." Having Tod review the code might be a good idea, but the decision is not the ScrumMaster's to make. Doing so goes beyond authority over the process and enters into how the team works.

With authority limited to ensuring the team follows the process, the Scrum-Master's role can be more difficult than that of a typical project manager. Project managers often have the fallback position of "do it because I say so." The times when a ScrumMaster can say that are limited and restricted to ensuring that Scrum is being followed.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010

• 0 comments »

Fike diehards, followers are more opposed to changing the status quo than they are opposed to adopting Scrum in particular. Unlike diehards, however, followers present passive resistance to the change. Dexter, a mid-level programmer at an ecommerce company was a follower. He asked questions like a skeptic but always with an undercurrent implying that he knew Scrum was a bad thing. Where a skeptic would ask, "How does Scrum work on projects where getting the user experience perfect is absolutely critical?" Dexter would ask, "Scrum doesn't work when getting the user experience perfect is critical, does it?"

I remember one conversation with Dexter in which he asked how many times I would be back to visit his company. "I'm scheduled back in July and October," I said. This was June.

"Nothing after that?" he asked.
"Maybe, but we haven't scheduled anything past October."
"Good. This will be done by the end of the year, then."

I was impressed by his enthusiasm, but I thought his timeline for adopting Scrum was a little aggressive considering the size of his company. "Well, probably not," I cautioned. "There will probably still be some work next year. Not everyone has even started running sprints. But you probably won't need me next year."

"Oh," Dexter replied, "I didn't mean it that way. I meant we'll be onto our next new process by then. After the Christmas shopping season is over, we always change our process."

No one had told me about these annual process changes prior to my first visit with this company, but considering the company's history of adopting a new process every January, it wasn't surprising that Dexter would take a wait-it-out approach to Scrum. In fact, many followers adopt this approach, reasoning that this change will be followed by some later change and they might as well skip a few along the way.

On his own Dexter didn't present a significant hurdle to a successful transition. But, have enough Dexters in your organization, and they can impede a successful transition. Fortunately, followers are not usually very vigorous in their resistance. They will put up minor, passive resistance, mostly hoping that the change goes away. In addition to some of the tools described already, there are a few more tools that can be useful in dealing with followers:

• Change the composition of the team. Some coworkers bring out the best in us; others bring out the worst. Changing the composition of the team will undoubtedly change the nature of resistance. Replacing a grumbling, always-negative saboteur with a skeptic may remove a follower's motivation for resisting.

• Praise the right behavior. Rather than focusing on changing the behavior of the followers, praise some aspects of appropriate behavior whether you observe it in a detractor or supporter. Followers will notice and resistance in some will weaken.

• Involve them. A great way to reduce the resistance of a fence-sitting follower is to involve her in the design of the new process. For example, you might ask a follower to join an improvement community figuring out how to do automated unit testing on your challenging legacy application or to work with others putting together a presentation for the sales group on how Scrum impacts your ability to put dates in contracts.

• Model the right behaviors yourself. Followers need someone to follow. Increase the odds that they follow someone who is exhibiting the right agile behavior by modeling those behaviors yourself. For example, given that collaboration is an essential part of Scrum, strive to demonstrate this in your interactions with others.

• Identify the true barrier. "ADAPTing to Scrum," determine whether a follower is resisting because she lacks the awareness, desire, or ability to use Scrum. Then provide the appropriate support to break through that barrier. If she isn't aware of the reasons for transitioning to Scrum, have a private conversation in which you share them. If she currently lacks the ability to be agile, look for an opportunity to pair her with someone who can help her learn those skills.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010

• 0 comments »

Katherine worked as the director of metrics and measurement for a large division of a financial data provider. I had been told she was a supporter of the division's shift toward Scrum but that she had a few questions for me so that she could more effectively do her job of collecting process and product metrics. I have a natural interest in this subject, and such discussions are usually a great chance for me to learn something new I was looking forward to meeting with Katherine as a chance to discuss some creative, innovative metrics.

Was I ever wrong! Katherine had mastered the art of appearing to support the transition to Scrum while trying to hold onto the status quo. Three years prior to our meeting, software development within this organization had been characterized by missed deadlines and buggy software that didn't meet customer expectations. At that time, Katherine was the newly hired test manager. She instituted some new procedures that dramatically improved things. As a result, teams seemed to be meeting their deadlines (mainly because schedules were padded by what I considered astounding amounts) and quality improved (by creating a separate test group that would spend months testing after a product was handed over to them).

For her efforts in solving these problems, Katherine had been promoted and was now running what was essentially a project management office (PMO).As she told me more about her background and about how she had previously helped her company by introducing various process improvements, I was sure I had found an ally in transitioning her division to Scrum. Instead, what I found was someone who had built herself a very nice empire (through good effort directed at earlier company goals). She was now so enamored of her current status, the number of people reporting to her, and her level of prestige that she was unwilling to consider further changes. Moses could have come down from the mountaintop with the ideal process engraved on stone tablets, and Katherine would have resisted.

Katherine, like other diehards, was opposed to Scrum not because of anything inherent in it but because she did not want to let go of the current state. She was very actively resisting the change but always in ways that allowed her to claim to be supporting it.

A common technique of diehards, and one Katherine employed, is to stall the transition by controlling resources. This is possible because diehards are often found at the middle and upper levels of management where they have enough status to want to keep it. In Katherine's case, she controlled a shared pool of testers. This allowed her to harm the transition by profligately moving testers between projects. There were always plausible reasons: A critical project needed an additional tester, another project needed the expertise of a specific tester, and so on. Katherine's tactics had the effect of ensuring that no team retained the same personnel from start to finish and that many Scrum teams didn't have a tester for the first few sprints.

Many of the tools appropriate for overcoming the resistance of the saboteur will work with the diehard as well. Some additional tools you may want to employ with diehards include

• Align incentives. Diehards are tied to the status quo because of the benefits (either tangible or intangible) that it brings them. If you find a lot of resistance from diehards, consider all incentives that exist in the organization and make sure each aligns well with being agile. I am not referring solely to financial incentives. Nonfmancial incentives such as who gets promoted or otherwise recognized should also be reviewed. If having a large number of people reporting to you creates clout in your organization, for example, you shouldn't be surprised when people resist losing their direct reports.

• Create dissatisfaction with the status quo. Diehards like the status quo. They are not opposed to Scrum because of what it is; they are opposed to it because they like how things are. So, try to create dissatisfaction with the current state. I don't mean to go create a crisis, but if one looms, point it out. If market share is declining, make sure people know. If calls to tech support are on the rise, show people. If an industry newsletter recently heaped praise on a competitor's product, hang copies of the article where everyone can see them. This is consistent with the advice of Stewart Tubbs, author of a textbook on small-group interaction: "A prescient manager is always looking for ways for the organization to improve continuously. She or he is constantly on the lookout for ways to make the organization more effective, and looks to communicate these ideas as a way to generate dissatisfaction with the status quo".

• Acknowledge and confront fear. Diehards resist in part because of the uncertainty of what their jobs will look like with Scrum. They are usually very happy with their current positions. Fear of an uncertain future can be very powerful. How will my role change? How will I be evaluated? What will come next in my career? These are all powerful questions often in the mind of the diehard. If you know the answers and are in a position to give them, do so. If the answers are unknown, say so but commit—if you can and if you value the work of the diehard—to working with him to find the answers. You can also help calm these fears by clarifying what is expected not just of the diehard but of others with whom he may work.

In Katherine's case, her vice president (Christine) and I sought to find the right role for her in the new organization. We talked with her about our confidence that her past experience in guiding the company toward dramatic process improvements put her in a key position for helping the company again. Christine clarified Katherine's role in the new organization. Unfortunately, Katherine's sense of identity and self-worth were so tightly coupled to the process that she had helped put in place that she could not help the company move beyond it. In the end, she left the company.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010

• 0 comments »

It can be easy to mistake a saboteur for a skeptic—after all, some amount of uncertainty about any change can be a good thing. I made the mistake of confusing a saboteur with a skeptic while teaching a class at a search engine company. Elena, a participant in the class, was asking a lot of good, challenging questions. I didn't know her role in the organization, but because many class participants were deferential to her, I figured she was important in one sense or another, and so I spent a lot of time answering her questions. If I was right and she was an opinion leader, and if I could convert her by overcoming her objections one by one, I knew that would be a big step forward for this company.

At the end of the day, I met with the director who had invited me to teach that class in her company. We talked about how the class went and I told her how I hoped I'd made progress helping Elena to see the light.The director said,"I should have warned you about her. She hates Scrum. She runs a shared user experience design group and is completely opposed to everything about Scrum. She's been fighting it since we started six months ago. I was surprised to see that she'd signed up for your class."

Elena was a saboteur—opposed to Scrum and actively resisting it. Like most saboteurs, she had been soliciting others to her cause. Despite mounting evidence within her company that Scrum was helping create better products more quickly, she continued to argue that it would not. I asked Elena directly why she was so strongly opposed. She said, "I have the best stateroom on the Titanic and I'm not moving!"

In addition to some of the tools offered for overcoming the resistance of skeptics, the following tools have proven useful with saboteurs:

• Success. As long as there is any doubt about whether Scrum is the appropriate approach, saboteurs will use those doubts to spread resistance. "Yes, it worked on our web projects," they may grudgingly offer, "but, it won't work on our back-end projects." Success on many different types of projects is a surefire way of weakening those arguments.

• Reiterate and reinforce the commitment. Saboteurs need to know that the company is committed to the transition. Any sign of weakness and—like a lion eyeing a tasty-looking antelope—the saboteur will attack. Faced with a large number of saboteurs, a strong message from as high up the executive chain as possible will at least let them know resistance is futile.

• Move them. If possible, find another team, project, or division and move the saboteur there. Unless you are a small organization or are doing an all-in transition, it is quite likely that a saboteur can continue to be a productive team member elsewhere—until Scrum starts to permeate that team, project, or division, that is.

• Fire them. This is the extreme end of moving someone. But if someone is opposed to a stated corporate direction and is actively resisting it, then this is quite possibly the appropriate action.

• Be sure the right people are talking. A thriving set of communities focused around topics of special interest can be invaluable in producing enough momentum to overcome resistance. Hearing how others within a community of practice are succeeding with Scrum can lessen a saboteur's resolve to continue resisting.

Elena was fortunate to work in a large organization in which she could be moved to a different department that was still taking a wait-and-see attitude toward Scrum. She eventually came around to the point where she is again a productive team member, though even today she will admit she is secretly waiting for a change back to the old way of working.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010

• 0 comments »

Thad had no choice but to adopt Scrum. His company had been acquired and was being told by the new owners to begin using Scrum immediately. This wasn't a direction Thad would have chosen himself, and he had serious concerns about it. Would the daily scrums add value, especially with a product owner who worked from her home 600 miles away? How could a new product as complicated, large, and novel as theirs be done without a lengthy up-front design phase? He could see the value of iterating through the construction phase, but surely an up-front design was still needed.

Thad was a skeptic. I knew this from his willingness to admit that Scrum was fine for other domains, technologies, or environments—-just not his. Thad openly acknowledged the appropriateness of Scrum for web development but questioned it for his company's scientific applications.

As the most experienced member on his team and one of the longest-tenured developers in the organization, Thad was an opinion leader. Others looked to him to see how he would behave under the mandate to adopt Scrum. Thad exhibited a healthy amount of doubt; people should not be expected to change how they work without the opportunity to ask hard questions or be expected to fully embrace Scrum until they've worked on a Scrum team and experienced the benefits for themselves. Thad's uncertainty, however, went beyond doubt to the point where he was resisting the transition in small but important ways.

Because he didn't see the benefit of daily scrums, Thad consistently pushed to skip them. At the end of one meeting he said, "It sounds like we're all on stuff that will take at least today to finish. So let's skip tomorrow's daily scrum and just meet again the day after. Every other day is probably good enough anyway." Sometimes his ScrumMaster could successfully counter these arguments, but not always. After all, the ScrumMaster was new to Scrum, too.

Additionally, like many skeptics, Thad would sometimes claim to support a Scrum practice but would then continue to work as he always had. For instance, he said that he supported working iteratively and claimed to understand the value of having a potentially shippable product at the end of each sprint. In truth, though, Thad didn't believe that all parts of their product could be designed, coded, and tested within a single sprint. Consequently, he habitually pushed the team to bring more work than it could handle into each sprint. Overcommitting was his way of making sure that some features were worked on over at least two sprints.

Some of the tools that are useful in overcoming the resistance presented by skeptics include

• Let time run its course. If you can keep the transition effort moving forward, evidence of the benefits of Scrum will start to accumulate. Even if this evidence is merely anecdotal, it lessens the amount of resistance a skeptic can put up.

• Provide training. Some of a skeptic's resistance is a result of not having done something or not having seen it done before. Training—whether formal classroom training or as provided by an external coach brought in to work with the team—helps by giving the skeptic the experience of seeing firsthand how it can work.

• Solicit peer anecdotes. If you've never experienced something yourself but your friends or those you relate to have, their personal stories will resonate with you. If there are Scrum success stories from other teams in your organization, make sure the skeptics hear them. If Scrum is new to your organization, invite experienced agile outsiders in. Inviting a local software architect to speak at lunch about her company's success with Scrum will do wonders in persuading your own skeptical architects.

• Appoint a champion skeptic. In their book Fearless Change, Mary Lynn Manns and Linda Rising suggest designating someone as the company's "champion skeptic" (2004).The champion skeptic should be influential, respected, and well connected but should not be openly hostile to the change. The champion skeptic is invited to all meetings and is given a chance to point out problems. Use this information to sincerely address the concerns the champion skeptic brings up. Doing so demonstrates open-mindedness and prevents any one concern from escalating into a crisis.

• Push the issue. Put the skeptic in charge of some part of the transition. Suppose you are struggling with a skeptical tester who does not believe testing can be done in the same sprint as the design and programming of a feature. Challenge that tester to identify five ways to help bring the team closer to the goal of testing within the same sprint. The tester won't be able to come up empty for fear that the next person who takes on the task successfully identifies five items. Then, ask the team to either try all five things or to select the one or two ideas that seem most promising initially.

• Build awareness. Presumably you have chosen to do something as difficult as introduce Scrum because there is a compelling need to do so. Perhaps a new competitor has entered your space, perhaps your last product took a year too long to release, or perhaps you have any of a number of similar reasons. Make sure that those involved in the transition are aware of the better future that will follow a successful transition.

In Thad's case, we were able to overcome his skepticism by pushing the issue. We put a stop to his passive resistance to iterating by switching to shorter sprints. The team had been using four-week sprints but was bringing in about six weeks worth of work in each sprint planning meeting. I told them we were going to try two-week sprints until they got a handle on how much could actually be completed in a sprint. Thad didn't like this idea. In the next sprint planning meeting, to point out the foolishness of working in such short sprints, Thad pushed the team to commit to what he thought was a ridiculously small amount of work. It turned out to be the right amount; for the first time the team finished all its work inside one sprint. As team members came to see the value of completing what they committed to,Thad's subtle efforts to force the team to overcommit were thwarted by the team's new insistence that it bring in to the sprint only what it could handle.

Although pushing the issue helped in Thad's case, the biggest factor in eradicating his resistance was time. It just took time (and a mounting pile of anecdotal evidence that it could be done) to sway Thad.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010

• 0 comments »