SM / PO Cheatsheet: Simple guide to the difference between a Scrum Master and a Product Owner

By Edward Scotcher

This is a simple one page aide memoire that can be used to help explain the responsibilities of the role of Product Owner and Scrum Master. It's great to print off and hand out to people when you are explaining what the roles are and what the differences are between them. So next time you need to talk about these roles, you can use this as a basis for a simple discussion or presentation.

Scrum Master's Responsibilities

• Responsible for helping the team deliver work to the Product Owner
• Makes sure the team can meet its commitments by removing any impediments they face, including Managing dependencies, escalating blockers that they cannot remove themselves
• Facilitates process & meetings (eg Reviews, Stand Ups, Planning, Estimation, Scheduling, Prioritization)
• Makes sure the team is fully functional, productive and improving quality
• Shields the team from distractions and interferences (including the Product Owner)
• Enables close co-operation across all roles and functions, removes barriers
• Responsible for reporting progress, including producing standard outward-facing artefacts
• Manages Product Owners expectations of the team
• Responsible for keeping time and quality requirements

Continue reading this article.

The Product Owner on One Page: Overview of the Product Owner Role

By Roman Pichler

The following diagram summarises the product owner's responsibility together with the role's key activities and artefacts.

Continue reading this article.

An Example ScrumMaster's Checklist

By Michael James

An adequate ScrumMaster can handle two or three teams at a time. If you're content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation at your organization, and probably nothing catastrophic will happen.

But if you can envision a team that has a great time accomplishing things you didn't previously consider possible, within a transformed organization -- consider being a great ScrumMaster.

A great ScrumMaster can handle one team at a time.

We recommend one dedicated ScrumMaster per team of about seven, especially when starting out.

If you haven't discovered all the work there is to do, tune in to your Product Owner, your team, your team's engineering practices, and the organization outside your team. While there's no single prescription, I've outlined some things I've seen ScrumMasters overlook.

Continue reading this article.

Ouija Board Estimation: A fun technique for agile estimating

By Paul Goddard

During a recent training course I ran, one of the delegates made a joke about the nature of agile estimation in Scrum teams resembling a "séance"; whereby the team gathers around the table and stares at a number of user story cards expecting something unnatural to happen. How true!  This gave me an idea for a different type of iterative estimation that I tried in practice with ‘Team Woodstock’.  I sat the team around a table and wrote the Fibonacci sequence’s numbers “1,2,3,5,8,13” and a “?” on post-its around the table in the design of a Ouija board.  Once everyone was sitting comfortably, had cleared their minds and entered a trance-like state the product owner read out the story and the team clarified the acceptance criteria.  Then the story was placed in the middle of the table and each team member put one finger on the story – in silence. Without discussion or argument the story started to move towards the number which reflected its size, by the act of the team members pushing or pulling the story towards their chosen number.

Continue reading this article.

Owning an Agile Product: One CSPO's Experiences Driving Scrum Projects.

By Edward Wehr

Being a product owner and having responsibility for a product's development using agile methods can be a bit overwhelming. Creating any product can be challenge. With a product being developed at the speed of agility, these challenges increase. Nothing is more frightening than feeling out of control while going at a high rate of speed. Let me reassure you, though, that it does get better. The first time you drive down that agile highway (even if you aren't yet going fast enough), it's scary. But with practice and a good understanding of what to watch for, driving an agile project becomes easier.

Because training and certification for product owners is fairly new, I've included some wisdom I've gained from my time on the agile road, which includes guiding four different teams over the past several years.

Priorities Are Priority One.

What teams need most is a product owner who is able to prioritize the product backlog. This includes adjusting priority based on new information and juggling the team's needs for work against customer features. A product owner must understand and be willing to have the critical conversations with team members regarding stories (work) that are not direct customer features, yet will develop an architecture that will enable the team to achieve more work (higher velocity) in the future. Balancing all of these competing stories, and the emerging importance and changing priorities that come with them, is a constant struggle.

Continue reading this article.

From Meager Beginnings to Masterful Ends: Taking Scrum beyond IT One Iteration at a Time

By Maria Matarelli

I’ve used Scrum on many software development and IT projects.  In addition to the projects I was working on, I received a request to work on a role-advisory team tasked with analyzing the effectiveness of a specialized project role.  This new team was pulled together with minimal allocations and replaced a full-time team that had just been disassembled due to budget cuts.  Given the constraints and uniqueness of the project, we decided to use Scrum for our approach.  It worked—flawlessly.

Demanding Circumstances

The going was uphill from the start.  We were a team of ten, allocated to contribute only 20 hours per person over the entire calendar year.  The team was just told, “Go.”  Success was undefined and the scope was unclear.  With a meager budget and minimal direction, we had to guide role development, training, knowledge sharing, and create a solution to provide overall direction to support more than 150 people.  The only thing we knew for certain was that the requirements were bound to change as work progressed.

As we discussed our options, it became more and more apparent Scrum was the right approach.  The limited ingredients and project constraints were the perfect recipe for a self-directed team.  Though we could have easily made the business case for additional funding, we were told from the beginning that “additional funding is not possible.”  Any solutions we found would have to be found within the team itself.  Frequent, incremental deliveries would help bring clarity to the project vision.  Though only few of us had used Scrum outside of IT (and most of the team had never used Scrum at all) we felt it was the perfect solution for the constraints facing our team, constraints that probably sound familiar to many teams out there.

Continue reading this article.

Go with the Workflow: Focus on process instead of definitions to help new teams deal with product backlog items

By Henri Stegehuis

I love my work. Implementing Scrum is fantastic. Every company I work with has different processes and cultures. Coaching teams in this drastic new approach we call Scrum is always fun (afterwards). Working with people, breaking traditional patterns in common sense, creating a physical/visible presence, and fostering honest communication is a roller-coaster experience. Every team is unique, every time surprising me with interesting reactions and sometimes unexpected results.

In the past, some of these unexpected results have sprung from my attempts to explain the concept of a product backlog item (PBI). For teams raised in traditional development, the ins and outs of product backlog items can be difficult to grasp. When I talked with these teams about PBIs, I made the mistake of going into too much detail too early. I would start with the definition, explaining that a PBI is "up to half of an A4 page describing a requested feature from a market point of view." This, while a correct description, opened the floodgates for the skeptics and perfectionists within the team, who asserted that there was no way they could write a complete product backlog item in that amount of space. We would get off track, and it would take me some time before I could refocus the team.

Continue reading this article.

Effective Retrospectives & Reviews: A CSP’s perspective on continuously improving both the process and the product.

By Marco Mulder

Continuous improvement is a key principle of Scrum. Yet, though most Scrum teams conduct a sprint review and a retrospective at the end of each sprint, too many teams fail to implement the improvements they identify. In my experience, there are two common causes for this:

• Teams don’t have or maintain explicit standards for their product and process;

• Teams don't use the product backlog to schedule improvements.

Set a Dynamic Standard

A definition of done in Scrum defines general acceptance criteria to which all implemented features should adhere. This ensures that everyone has the same understanding of what it means for a feature to be “done.” Team members must all know these general acceptance criteria so that they know when they’re finished. The product owner and stakeholders need a definition of done so that they know what they can expect from the features delivered by the team. That does not mean, however, that the initial definition of done is the one you will want to use throughout the project's lifecycle. In fact, one of the reasons why an explicit definition of done is important is that it not only says what will be included in each feature, it also makes explicit what is not included. Some of the things not included may be planned additions later in the project.

Continue reading this article.

Common Product Owner Traps

By Roman Pichler

Product owners play a key part in creating successful products with Scrum: They are in charge of the product and lead the development effort. But this new, multi-faceted role can be challenging to apply. For many organizations, the path to effective product ownership is littered with traps and pitfalls. This article helps you recognize and avoid some of the most common traps.

Editor's Note: The following article was originally published by InformIT and borrows heavily from the author's latest book. It is included here for your convenience and with permission.

The Product Owner in Scrum

“The Product Owner is the one and only person responsible for managing the Product Backlog and ensuring the value of the work the team performs. This person maintains the Product Backlog and ensures that it is visible to everyone,” writes Ken Schwaber in the Scrum Guide (Feb 2010 edition, p. 7). This definition sounds rather harmless until we consider its implications. It requires the product owner to lead product discovery, to help identify and describe requirements, and to make sure that the product backlog is ready for the next sprint planning meeting. It also means that the product owner has to engage in product planning, visioning and product road mapping. The individual decides on the content of a release, carries out release planning, reviews work results and provides feedback to the team, and manages customers, users and other stakeholders. So many diverse responsibilities make the product owner a multi-faceted and challenging role. What’s more, the product owner duties often cut across existing roles including the product marketer, product manager and project manager roles. It’s not surprising that organizations can find it challenging to apply this new role encountering traps and pitfalls along the way. Let’s have a look at some of the most common ones.

Continue reading this article.

How to Sustain Adaptive Planning

By Rahul Sawhney

Scrum and other agile methods recognize that responsiveness to change is an important aspect of delivering projects. They also recognize that software development is evolutionary and creative. By managing changes through Adaptive planning, Scrum provides a simple yet effective method of planning and tracking project progress. In this article, we will examine what is needed to sustain Adaptive planning and improve Team's responsiveness towards customer needs.

We will examine the following factors:

• Just-enough planning
• Evolving plan, scope driven by budget and/or time
• Grooming the scope
• Trust, involvement and collaboration
• Management support

Consider a scenario where the project is progressing as per plan, and in the middle of the project the customer approaches project manager with a request:

Customer: "I really need this functionality delivered in the project. But it is not part of the current scope. Can we make it happen as part of this project?"

Possible response #1:

Project Manager: "Unless you are okay with budget overflow and/or schedule delay. Alternatively, we can revisit the project scope but it will require us to drop certain other functionality from the scope of this project. As the effort already spent on estimation and analysis of that functionality will be wasted, please be aware that it will impact productivity."

Possible response #2:

Project Manager: "Well, I am afraid the change control board (CCB) needs to decide this. The CCB meets in two weeks and once they approve that an investigation is needed, we can investigate and inform them about the impact on our plan. The CCB can then decide whether or not this functionality can be implemented."

Possible response #3:

Project Manager/Product Owner: "I do not see a problem as long as you are okay with dropping certain low priority items from current scope of the project and getting this functionality at the end of next Sprint, assuming it fits. Let's get together and discuss."

Although many responses are possible depending on the context, if the project is using Adaptive planning then a response similar to response #3 is more likely. Such a response demonstrates that the Team is well prepared to respond to change.

Making Adaptive planning work

- Just-enough planning

To begin with, requirements are understood at a very high level and thereafter, the rest of the planning is driven by priority. As a rule, lesser time is spent on figuring out the details of those requirements that do not have a very high priority. High priority bigger requirements are split into smaller ones so that details can be explored. Only relative size estimates (at a high level) are done at this point to get an idea of how "big" the work is. Once the work is quantified, tasks and effort are estimated for the highest priority requirements. That gives an idea of how much the Team can deliver in a Sprint. This idea is tested in the first Sprint and gives the Team a better understanding of its Velocity (or the size it can deliver in one Sprint). Using the Velocity, the Team is now in a better position to give commitments for later sprints.

- Evolving plan, scope driven by budget and/or time

As the project gets underway and the Team executes multiple sprints, the Team has better visibility on the customer needs. Likewise, the customer also understands the requirements better. This understanding results in evolution of the Product Backlog (e.g. changes in functionality and scope, priority).

As the Product Backlog evolves, the size estimates are done for newly added requirements. The Product burndown chart shows how much work is remaining based on the revised scope in the Product Backlog. The work remaining is controlled usually by removing some low priority requirements (of size equal to the added requirements) from the scope. This ensures that scope is managed continuously based on highest priority requirements.

Adapting the plan in this manner helps in providing better visibility to all stakeholders by tackling many important issues, such as:

• How do we deliver what is most important for the customers?
• How do we address customer feedback on what has been already delivered?
• What are the key changes that we need to make?
• Have we addressed all the key risks for the project?
• How much work is remaining for the project? Do we need to adjust the project scope?

- Grooming the scope

At the beginning of each Sprint, the Team makes a commitment on the functionality it can deliver. In order to make a commitment, the Team may need some time to investigate certain aspects and risks in the preceding Sprint itself. In other words, sometimes it makes sense to look-ahead and reserve some time for investigation on risky items in the backlog that may be part of the next Sprint. Better insight into risky items in the Product Backlog helps the Product Owner make conscious decision on the item's priority, makes the Sprint planning exercise easier and the Team more confident.

Additionally, new functionality requests by Customers can be expected at any point during the project. Sometimes, especially when the functionality is complex or due to other reasons, identifying enough details for quickly giving commitments on these new items at the beginning of the Sprint can be difficult. Grooming the scope during a previous Sprint makes sense.

- Trust, involvement and collaboration

Working with an adaptive plan requires a lot of trust, involvement and collaboration between the Team, the Product Owner and other key stakeholders of the project. Unfortunately this is much easier said than done. Individual stakeholders have different motivating factors and it requires time to build the trust.

Things may become extremely difficult and unsustainable if the trust is lost. The effect of losing trust could result in failures such as poor quality, dramatically reduced velocity, inability to meet commitments for multiple Sprints, arguments over small stuff, high team attrition and loss of face in front of the customers.

Building trust requires a lot of commitment and collaboration. The Product Owner and management should give the Team freedom to decide how much it can deliver in a Sprint. The Product Owner needs to set the right expectations between the customers and the Team. Setting unreasonable expectations can misfire in the long term. The Team may succumb to pressure of delivering more functionality and may succeed in doing so by cutting quality, or by introducing too much technical debt that becomes difficult to handle later. The ScrumMaster needs to support the Team by guarding the scope and the practices of Scrum. The Team needs to understand the needs of the Product Owner and help in achieving that goal. The Team can help in several ways, such as improving its engineering practices, making the most out of feedback, ensuring that it acts on its retrospective actions and highlights issues that are beyond control.

The mechanism of "inspect and adapt" should not be interpreted as a "self-repairing system." The system will not fix the problems unless everyone involved in the process devotes the time needed and is committed to the process. The Team members (ScrumMaster, developers, testers etc.) need to work with each other to achieve the Team's sprint goal and continuously improve their ways of working. They need to work with the Product Owner to groom the scope and understand what is needed.

Likewise, the Product Owner needs to collaborate with the Team throughout. If the Product Owner becomes complacent in engaging with the Team after a few Sprints then the visibility of the Team can reduce drastically, benefits achieved can be quickly erased and situation can deteriorate. The Product Owner needs to ensure that the business users and customers are appropriately engaged in the process. Without an appropriate level of engagement, there is a risk of misunderstanding the business and customer needs.

- Management support

In order to sustain Adaptive planning with Scrum, it becomes important that the culture of the organization understands and respects change. Organizations, where teams go agile but the management thinking does not, run a risk of quickly losing all the benefits from Agile and becoming worse than they were before. Some of the things that managements need to do include

• Provide long term vision, direction and priorities
• Trust and motivate their Teams
• Focus on addition of business value
• Encourage Teams to deliver quality, act on technical debt, enhance engineering practices
• Ensure continuous flow of work
• Minimize non-work related disruptions
• Facilitate removal of impediments outside the control of Teams
• Support the process of learning, inspecting and adapting
• Communicate

Conclusion

Adaptive planning helps Teams handle changes to scope in a continuous manner but may become unsustainable when practiced in isolation. Other practices of Scrum, along with critical management support and understanding are critical for sustain Scrum in an organization.

Can Scrum Support Six Sigma?

By Heitor Roriz Filho

INTRODUCTION

This article discusses briefly how Scrum could support Six Sigma projects. Issues of whether Six Sigma is used specifically in software or other product development are not considered. If you ask yourself "Why should Scrum support Six Sigma projects?" I can promptly reply, "Why not?"

Moreover, the question of how Scrum, a lightweight framework for project management and other predictive and detailed methodology have led to process improvement has already been addressed in [2] [3] [4] [7].

SIX SIGMA ASPECTS OVERVIEW

Six Sigma can be considered a detailed and structured methodology to execute projects in a company. To ensure the success of Six Sigma methodology implementation, some critical factors must be verified. A study by McAdam and Lafferty reveals the necessity of employer's empowerment applied with the right tools and methods, in order to achieve the Six Sigma proposed goals in an autonomous and responsible way [14].

Six Sigma as a new paradigm of excellence can result in a huge amount of investment, and it can be questioned if there are other methods that require fewer resources and achieve similar results. Six Sigma still has a long road ahead until it can be accepted as a change philosophy applied to companies in general [14].

In parallel to this movement, another methodology called Lean Manufacturing or Lean Production was developed, and the union of these two process improvement methodologies is called Lean Six Sigma. Originally focused on improvement with a special attention to losses reduction, the concept became one of the most important points of Taiichi Ohno's philosophy, the mentor of the Toyota Production System (TPS). Combining JIT, KANBAN, Quality Circles and CEP, he focused on saving Toyota from a big crisis during the 50´s, which they not only overcame but also won the Japanese Quality Award, the Deming Prize.

Nowadays, many consulting companies look for Six Sigma experts as well as experts in Program and Lean Production, and even though training costs remain above average, many companies are still embracing these programs. On the other hand, some online communities such as TreQna (www.treqna.com) are freely sharing Six Sigma and Lean Production concepts, ensuring many options to people interested on acquiring such knowledge.

The deployment of any program or strategy always depends on people's behavior. In [18] this behavior is divided into two independent and important groups, the top management and the people in charge of the program implementation. The behavior of these two groups is strongly related to their creeds and values, and significantly contributes to the implementation success of a process improvement program such as Six Sigma.

SIX SIGMA ROLES AND METHOD

Six Sigma is based on a people structure of three main roles, Champions, Black Belts, and Green Belts working in a framework such as DMAIC (Define-Measure-Analyze-Improve-Control), a 5-phase method based on PDCA and focused on problem-solving. The Champions have the responsibility to properly define the project scope (during the Define phase) and support the project during the other phases. The Black Belt has the responsibility to communicate frequently with Champions and team members during the project execution, and act as a project leader. Green Belts act as team members and play an active role in the Measure, Analyze, and Improve phases. Finally, all members work together to ensure the sustainability of improvements during the Control phase.

THE SCRUM ROLES

Scrum is focused on its process, three roles, and some artifacts. The three roles in Scrum are the Product Owner, the ScrumMaster, and the Scrum Team.

The artifacts in Scrum are the Product Backlog, the Sprint Backlog, and the Burndown Graph. The Product Backlog contains a prioritized list of the client's needs, i.e., all activities to be performed in order to get the product done. This list is prioritized according to the client necessities; the more business value, the higher on the list the activity will be placed. The Sprint Backlog is a list of activities broken into tasks that are selected in the beginning of a Sprint (a time-boxed iteration usually ranging from two to four weeks). A Burndown Graph displays the remaining work in a Sprint. The literature about Scrum artifacts is vast. More on the artifacts can be found at [10] [11] [12].

The Product Owner (PO) has several responsibilities in a project ranging from defining the product vision to managing the Return on Investment (ROI). The PO represents the needs of the client in a project and is in constant and close contact with the client as well as with the Scrum Team and ScrumMaster. The ScrumMaster is a facilitator in the Scrum process. He is the one responsible for ensuring that Scrum is correctly understood and is correctly followed by the team and PO. The Scrum Team is comprised by those who actually perform the activities necessary to get the product done during the several Sprints.

The Product Owner builds the Product Backlog, a prioritized list of the client's needs. These needs are expressed and/or written in the form of User Stories [14]. Before starting a Sprint, the Scrum Team, the ScrumMaster and the Product Owner perform the planning in a ceremony called the Sprint Planning Meeting. During this meeting the stories with higher priorities are thoroughly discussed and understood by all involved in the process. The Scrum Team then takes these stories and breaks them down into activities, which are the tasks needed to be performed in order to get each story done. These activities comprise the Sprint Backlog.

With the Sprint Backlog the Scrum Team starts to perform in the Sprint. During each day of the Sprint, the Daily Scrum takes place. During this 15-minute standup meeting, each member of the team answers three questions: What did I do yesterday? What I am going to do today? Are there any impediments? It is important to point out that the ScrumMaster acts as a facilitator during the whole process. During the Sprint he will be the one responsible to check whether the Scrum Process is being correctly followed and will protect the team from external interferences, including facilitating the removal of all possible impediments for the tasks.

At the end of the Sprint an increment of the product is delivered. Two ceremonies are performed, the Sprint Review, where the potentially deliverable product increment shall be accepted by the Product Owner, and the Sprint Retrospective, where the team discusses improvements that can be done during the next Sprint. These improvements range from changes in artifacts to better personal interaction.

We can see in this section that Scrum has a very simple yet immutable core process. It is important that this remains unchanged; otherwise we will not be speaking about Scrum, but something else. The next section will talk about how to blend this Scrum kernel into Six Sigma's.

BLENDING SCRUM INTO DMAIC

Scrum is extremely critical regarding the pureness of its architecture while Six Sigma is focused on reaching high quality products performance through variation reduction. The combination of these two concepts can be extremely powerful to bottom-line applications, mainly because Scrum has a strong alignment with lean principles. Furthermore, Six Sigma implementations blended with Lean principles (Lean Six Sigma) can be found in the industry and have become subject to many studies. We believe this diversity ranging from Lean and behavioral aspects and thoughts to predictive and detailed ideas can lead to better performance [5]. As pointed out by [15], Six Sigma should not focus only on the "how to do" the continuous improvement, evaluating the processes performance and business results, but also verify the people engagement and motivation. Therefore, both concepts can combine and complement each other, improving results.

Focusing on high quality products performance and establishing metrics based on statistics, Six Sigma manages a strong, continuous improvement of the manufacturing process. On the other hand, Scrum is a people-centered approach. Its essence surrounds its process and it has a profound effect on people's behavior: it affects the level of commitment in projects tending to facilitate the adoption of new ideas, i.e., it fights the resistance to change.

I start by grouping Six Sigma in six perspectives as shown in Figure 1 below.

The focus on clients' perspective aims to determine the VOC (Voice of Client) variable. Scrum has a very strong focus on the client. The client has its voice through the role of the Product Owner, which acts as a proxy of the client and communicates to the Scrum Team her vision and goals in the scope of the project. The fourth perspective is strongly based on statistical measurements. While Scrum has no predefined statistics in its core, it does aim to achieve improvement through collaboration and communication, i.e., developing strong and fruitful interactions among people. For these two perspectives it does not matter what process tool is used: DFSS, DMAIC, DMADV, etc.

DMAIC is one of the tools found in the perspective number 3 above. The steps defined by DMAIC is where Scrum can produce more tangible results and establish how both concepts intermingle as this is where project management initiatives in Six Sigma are located.

In order to apply Scrum in a Six Sigma project, we propose the following correlation among the roles of both concepts, shown in Figure 2 below.

One of the common mistakes that organizations make when implementing statistical thinking as in Six Sigma implementations is using measurement for motivational purposes [6]. Scrum as a PM framework can collaborate with Six Sigma leveraging the commitment of the team in both Operational and Managerial levels as depicted in Figure 3 below.

In order to blend Scrum and Six Sigma concepts, we consider that an organization comprises two parts, namely the managerial and operational level. We can then visualize the enterprise in terms of project management, where in the managerial level we find all types of executive work, except project management itself. Project management activities can be found in the operational level.

In the managerial level, Scrum would leverage the premise of any Six Sigma implementation, i.e., the support of senior executives. Applied to this level one can setup business-specific Sprint and Product Backlogs and run their activities according to Scrum's Heart and Soul [11]. This approach has been termed Executive Scrum by Magno [8].

The operational level is where DMAIC comes into play. Defining, measuring, analyzing, improving, and controlling are done during project execution. Champions (executive board) determine priority of upcoming tasks according the last DMAIC cycle. This prioritization comprises the Sprint Backlog for one Sprint.

CRITICAL ASPECTS TO CONSIDER

Six Sigma's VOC is a critical aspect of the methodology. This is generally not considered as much as it should be in any Six Sigma implementation. Deming's system of profound knowledge has four points [16]:

1. Appreciate the system.
2. Understand variation.
3. Theory of knowledge: PDCA as constant improvement.
4. Psychology. In our case, understand what engages people in their work.

Generally, Six Sigma is seen as being focused mostly on points 2 and 3. The point is that it does not matter how precise or improved a process can be if it does not meet the client's needs. Points 1 and 4 of Deming's system are those that interface with client's needs. This is where Scrum comes into play, as it has a strong focus on this and aims to work in collaboration with clients during every Sprint.

REFERENCES

[1] H. TAKEUCHI AND I. NONAKA, The New New Product Development Game, Harvard Business Review, 1986.

[2] JAKOBSEN, C. R. AND SUTHERLAND, J. Scrum And CMMI – Going From Good To Great. Are You Ready-Ready To Be Done-Done? In Agile 2009, Chicago, 2009.

[3] SUTHERLAND, J. ET AL. Scrum and CMMI Level 5: The Magic Potion For Code Warriors. In Agile 2007. IEEE Computer Society.

[4] GLAZER, H. ET AL. CMMI Or Agile: Why Not Embrace Both! Software Engineering Institute, Carnegie Mellon University. November 2008, Technical Note Cmu/Sei-2008-Tn-003.

[5] PAGE, S. The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies. Princeton University Press, 2007.

[6] PAULK, M. C. AND HYDER, E. B. Common Pitfalls in Statistical Thinking. Carnegie Mellon University. In ASQ SOFTWARE QUALITY PROFESSIONAL, VOL. 9, NO. 3, JUNE 2007, PP. 12-19.

[7] PAULK, M. C., Extreme Programming from a CMM Perspective. IEEE Software, Vol. 18, No. 6, November/December 2001, pp. 19-26.

[8] MAGNO, A. Scrum Executivo. AdaptWorks, São Paulo, 2007.

[9] SIVIY, J. M. AND FORRESTER, E. C. Accelerating CMMI Adoption Using Six Sigma. Carnegie Mellon University, Software Engineering Institute, 2004.

[10] SCHWABER, K. The Enterprise and Scrum. Microsoft Press, 2007.

[11] SCHWABER, K. Agile Project Management with Scrum. Microsoft Press, 2007.

[12] SCHWABER, K. AND BEEDLE, M. Agile Software Development with Scrum. Prentice Hall, 2001.

[13] http://www.scrumalliance.org. Scrum Alliance website.

[14] COHN, M. User Stories Applied.

[15] MCADAM, R. and B. LAFFERTY, A multilevel case study critique of six sigma: statistical control or strategic change? International Journal of Operations & Production Management, 2004. p. 530-549.

[16] http://deming.org/index.cfm?content=66. The W. Edward Deming Institute. Accessed: 2010-01-29.

[17] CORONADO, R.B. and J. ANTONY, Critical success factors for the successful implementation of six sigma projects in organizations. The TQM Magazine, 2002. p. 92-99.

[18] PFEIFER, T., W. REISSIGER, and C. CANALES, Integrating six sigma with quality management systems. The TQM magazine, 2004. pp. 241-249.

Beware of the Evil “85% Done”

By Marko Majkic

Years ago, in the dawn of my Scrum voyage, I was asked by my colleague from the sales department to estimate a project. The situation was kind of complicated; I would say kind of weird from the beginning.

The project was a web application, which was supposed to service about a thousand simultaneous users. The client was in another country, so we communicated only over Skype and e-mail. I got this estimation task in late January and was told that the application should be finished in a beta version by February 1, and a final version should be released on March 1. "Tight schedule, very tight," I thought. And we didn’t even have the team assembled because our developers were on other projects and pretty busy. So, we needed to gather the team, to find developers, and to finish the project (beta) in two weeks. "Pretty challenging," I told my colleague. He already had some contacts with a recruiter and told me that finding a "few programmers" wasn’t a problem. "Ok, let’s have an online meeting with the company owner," I suggested. So, we had the meeting. Apparently, they had started this project six months prior with just one developer. I thought this was interesting. A few days prior to our meeting, the developer told the client (“Jack”) that he had to leave the project for personal reasons. “Even more interesting,” I thought and smiled to Gary (my colleague from sales department). Now, the Client had promised the stakeholders that they would deliver the beta version in two weeks and the final version after a month. If they couldn’t deliver, they would have to refund money with penalties. So, Jack was ready to pay big money to have this project finished on time, and Gary saw a nice opportunity for our company. I saw an opportunity to show the power of Scrum, but I was a little worried that the team didn’t exist at that moment.

"Hey Jack," I asked, "do you have an idea what has been done and what is supposed to be done by our team?"

"No problem, I have an online demo," answered Jack, "and I reviewed the application thoroughly with our developer. He told me that application was 85% finished."

"This is great!" I said, "Why don‟t you release this version with all the completed functionality, and we can work on the remaining 15%! This way you and your partners would have a faster return on investment."

"No, no, you don’t understand," Jack told us, "We have all the functionality developed. The developer told me that each feature is 85% finished."

I was speechless. "Ok," I said, "so, you have a definition of done with seven items, and for each functionality, six items are finished and one remains to be finished, correct?"

"Errr…sorry, I didn’t hear you well,” answered Jack. "You were talking about some, definition of done,‟ right? What is the definition of done?" At this moment I was almost terrified. He didn’t have any idea what was done on the project.

I tried to be calm. "Ok, but how do you know that the project and each functionality was 85% done?"

"Well, the developer told me so," he said.

The good thing was that he had full confidence in this guy. I was pretty skeptical. I was interested to see what was really done on the project.

"Ok," I told Jack, "would you send to us some online demo info and a list of requirements, please? We will analyze this and get back to you with our estimates."

"Great," Jack said. I suppose that he was thinking we were already on the project. The work day was almost over and Gary and I decided to work until we had some estimates for Jack. So, we worked hard for the next four hours. I did estimates for programming work and Gary was testing the "almost finished" functionalities. I did optimistic (but still realistic) estimations. Gary was working on the functionalities list, comparing it with the online demo.

After the job was finished we had a conversation. Gary showed the functionalities to me, one by one. After each one, we were more and more worried. At the end we did a draft estimate of the developers‟ work needed for finishing the project. The best-case scenario was that, with a good team of experienced (read: more expensive) developers, the beta version could be deployed on March 15 and the production could start on May 1. This was an optimistic estimate. Jack’s (or developer’s) "85%" wasn’t 85% - but actually between 15% and 50%.

I told Gary, "Let’s drop all of it. We should do everything from scratch and do it right. Let’s suggest this to Jack." And by "right," I meant "in Scrum way." I knew that we couldn’t do a good job by continuing to work on the existing code. It was pretty messy; no tests, no code documentation, no basic documentation at all. And I was sure that we couldn’t commit to finish a beta version in two weeks. Not to mention that we didn’t have the team yet.

After four hours of working on the estimate and analyzing the project, we got back to Jack. I suggested to him to start from the beginning right away and told him that he needed to speak with the stakeholders. He didn’t like what he heard. “Hey, we need to go beta in two weeks. I don’t care how much it will cost. Add ten developers if needed!” he was upset; I could hear it in his voice.

I didn’t know about Brooks‟ law at that time, but I had some experience with adding more developers to a project, and I did explain to him that it would probably not solve the problem.

I suggested that the only way to make the project healthy and avoid failure was to get real, to present the stakeholders with the real situation, to accept responsibility, and to deal with it. We would help this project to succeed at a lesser cost than what they already had spent, and produce it three times quicker than they had planned at the beginning.

"No," he said, "my project is 85% done. I will find some other team that will finish it in time. Thank you for your time."

I was amazed. He was hypnotized by the evil magic of "85% done." I knew this project was doomed. And very soon, unfortunately, we could see that I was right. The website has never seen daylight.

Years after this experience, I faced the "evil magic of 85%" several times. We didn’t get this job, but I gained great experience from it. Whenever I heard that I should join/save a project that was in trouble and "85% done," I knew that something was wrong. Some of those projects I finished successfully and saved them. Some of them failed. But almost every time when failure occurred, people (top managers) were seemingly hypnotized, repeating "we‟re almost done!" I like Scrum, among other things, because it emphasizes a clear definition of done. A story is done or not done. There is no such thing as "almost done." There either is or isn’t business value, no matter what tasks developers have finished. There is no such thing as "85% done." And once again, I don’t mean 85% of all user stories. I mean 85% of each user story. By Scrum criteria, this means 0% of project. With 85% of all user stories "done done," I would probably go live with my application and would be very happy about that.

I was thinking about this evil magic of "85% done." Why is it so powerful? Here are some of possible reasons.

First, it makes us think we‟re almost there. “Hey, just one small effort and we‟re there.” This number gives us a comforting feeling that we can relax, because the job is almost done.

Second, this number is ideal, because it’s not too big – so in case someone wants to check the work, the missing 15% can be always be blamed on something not working – even if it is at the very beginning. This number is not small either, preventing someone from saying you are far from finishing the job. This evil number is perfectly chosen for its evil purpose – to keep us from establishing a definition of done and really finishing the story/project.

Third, this number is not quickly verifiable. You can say it and nobody could check if it is true, without getting deep in the code.

All in all, don’t trust a manager or developer who claims that 85% of a story is done. You can run away from these situations or you can use Scrum and a definition of done as powerful tools for fighting this evil and save the world (of the project at least).

And to all of you Scrum guys – don’t measure progress within the story. A story is done, or it is not done. Please, make a definition of done suitable for your project with your Scrum team and stick to it. Make your user stories small and doable in a Sprint. A user story is a measurement for the business value of your software. So, deliver done user stories, deliver complete business value, and, of course, don’t forget; beware of the evil “85% done.”

Scrum In A Nutshel

By Dan Rawsthorne and Douglas E. Shimp

Scrum is about Teams producing Results in an agile way. Scrum Teams achieve results anyway they can by using a simple set of rules to guide effort. We will describe Scrum as a simple applied model so that a central understanding of Scrum can be built. Other complexities of applied Scrum such as scaling, distribution, etc. will be explored elsewhere.

The Team

The fundamental element of Scrum is the Scrum Team (or "Team"), which is a small (usually fewer than ten) group of people that provides useful Results/Products for Stakeholders.

Arguably, the most important role involved in Scrum is the Stakeholder, as the Stakeholders are the ones who have desires, wants, and needs, and are the reason the Team is developing the software in the first place. Often, there is a special Stakeholder called the Business Owner, who actually controls the budget for the Team. The Business Owner is often the one who called or asked the Team to form.

While the Stakeholders are the most important source of validation for the project, the most important person on the Scrum Team is the Product Owner (PO). The Product Owner works with the Stakeholders, represents their interests to the Team, and is the first person held accountable for the Team’s success. The Product Owner must find a result that will satisfy the Stakeholders’ needs and desires. The Product Owner provides direction and goals for the Team, and prioritizes what will be done.

The Scrum Team Members, including the Product Owner, are the people who actually do the work that satisfies the goals and priorities the Product Owner has set for them. The Product Owner must work with the Team to find a rate and direction that the Team can go, to achieve a desirable result. Each Team Member is accountable to the rest of the Team for his/her performance, even as the Product Owner is accountable to the Stakeholders for the Team’s performance. The Scrum Team is cross-functional; that is, people on the Team (collectively) have all the skills necessary to do the work (analysis, design, code, test, documentation, marketing plan, drawings; whatever is required for the desired outcome). The Team is self-organizing, self-managing, and constantly trying to improve; they work on the priorities the Product Owner has set. The Team Members commit to the amount of work they can do without undue influence from the Product Owner.

In order to aid the Team (Product Owner included) in doing its work, there is a role on the Team called the ScrumMaster (SM). The SM's responsibilities are to be a facilitator, moderator, and coach, with particular emphasis on helping the Team mature its self-organization and management. The ScrumMaster manages the relationship between the Product Owner and the rest of the Team, and facilitates removal of impediments for the Team, often working with the Product Owner, the Business Owner, and other Stakeholders to do so. Impediments can come from within the Team and outside the Team. The ScrumMaster understands the Scrum process and how the Team is using it, recommends process improvements, and assures that the Team is following the process they have agreed to. If the Team does not follow its process this becomes an impediment. Most impediments can be addressed by simply causing them to become a center of focus. The SM stimulates that center focus by calling attention to the impediment. Creating a smart center of focus is the art of being a SM.

The Backlog

A Scrum Team's work is managed with a Product Backlog ("Backlog"), which is a prioritized list of Product Backlog Items ("PBIs," "Backlog Items,” or simply "Items"). When the list is small it is just a straight list of things, but as it grows we add grouping mechanisms to organize many little things and help us keep track.

These Items represent the Stakeholder's needs and wants – each of them is a request for something of value from the Scrum Team. These requests can be for anything, including software functionality, marketing, non-functional requirements, technical and infrastructure requests, business support, maintenance of existing systems, and so on. It is a rule of Scrum that the Team shouldn't do anything for any Stakeholder unless it's on the Backlog. The Team will be actively working on the top few Items of the Backlog during the Sprint; this part of the Backlog is called the Sprint Backlog, which is often thought of as a separate list of its own. The Product Owner is responsible for prioritizing that Backlog and thus, creating a distinction between the Sprint Backlog and Product Backlog. From the Team’s perspective, the Product Backlog is work that we might do some day, and the Sprint Backlog is work we are committed to doing.

The Backlog contains Items at all levels of fidelity, from vague wishes/wants/needs to finely detailed requirements. The higher the priority of the Item, the more detailed the request should be, so that it will be ready for planning and execution. Note: “ready” does not imply excessive detail but, instead refers to enough detail. The Team working with the PO will determine what “enough detail” is.

When a Scrum Project starts, the Product Owner should initiate the Backlog by working with the Stakeholders and other Team Members and capturing their needs, wants, and requirements as Backlog Items. As the Project progresses, the Product Owner and the Scrum Team should continuously work with the Stakeholders to (re)prioritize the Backlog, identify new Backlog Items, eliminate noise, and refine and generally clean the items list to get it ready for planning. The project effort will result in product that will often clarify and identify Backlog Items. This process is called Backlog Grooming, and is a continuous process throughout the Project.

Now that we have the notion of the Backlog to work with, let's describe the process, which involves discussion of both Releases and Sprints.

The Release

The goal of a Scrum Team is to produce and release results that meet the goals and priorities that have been set down by the Product Owner (hopefully as a result of working with Stakeholders).

Typically, before a project formally begins, there is a Visioning phase (this could also be the first phase in a project), when the Business Owner, Product Owner, and the Stakeholders produce a Product Vision and a Product Roadmap. The Vision provides the overall focus for the Project, while the Roadmap gives guidance about Releases and their Goals.

The Scrum Team’s purpose is to create a result that satisfies the Stakeholders’ needs, wants and desires, often so that more demand for their services is generated. This production is done through a series of relatively short, fixed-length iterations, called Sprints, in which results are produced by working on Items. The Sprint length can vary, but this requires more discipline on the part of the Team and is not advisable for new, less mature teams. The steps of a Release are relatively simple, and I'll describe them here.

Usually, the first thing that happens in a release is Release Planning. The Stakeholders, the Product Owner, and possibly other members of the Team, get together and negotiate what will be accomplished in the Release. This negotiation considers the Product Vision and Roadmap, balances the needs and wants of the Stakeholders against the abilities of the Scrum Team, and results in a set of Release Goals and a Release

Strategy to achieve them. The Product Owner and Team must update the Backlog so that there are prioritized Items on the Backlog that support the Release Goals and Strategy and are ready for planning.

Once we have a Backlog that supports the Release Goals and Strategy, the Team starts sprinting. The idea is for the Team to do as many Sprints as the Release Strategy calls for, and then Release the Results. Each Sprint looks basically the same, with the Release activities as part of the last one.

The Sprint

The fundamental process flow of Scrum is the Sprint, which is a relatively short period of time in which Backlog Items are converted into Results.

The first thing to do in a Sprint is Sprint Planning. In Sprint Planning the Product Owner works with the Team to negotiate what Backlog Items the Team will commit to for the Sprint in order to support the Release Goals and Strategy. Each of these Items has an agreed-upon definition of "Done," and collectively these Items are called the Team's Sprint Backlog. It is the ScrumMaster’s responsibility to ensure that the Team commits to a realistic amount of work, and that the Product Owner does not unduly influence this commitment. Often, the Items on the Sprint Backlog are tasked out in order to give the Team confidence that it can complete the Item, and thus commit to it. The tasking of Items can help the Team mature by paying attention to the work agreements they make with each other. The tasking can also help the SM detect when the Team is working well.

Once Sprint Planning is over, the Team begins work in the Sprint. The Team self-organizes to do the work and self-manages as it does the work. The Team’s work pattern is described as a swarm to get the job done. Team swarm is a pattern of performing Teams that looks like a swarm to an observer. While the Sprint is in progress, the Team will have Daily Scrums in order that each Team Member understands what the Team's status is. This allows the Team to detect when to adjust in order to be as effective and efficient as possible. These adjustments often take significant time and occur after the Daily Scrum.

During the Daily Scrum, and continuously throughout the day, the Team Members notify the ScrumMaster of any impediments they encounter. It is the ScrumMaster’s responsibility to facilitate the removal of these impediments. Often, this requires working with Team Members, the PO, the Business Owner, and other Stakeholders.

The ScrumMaster must also ensure that the Team does enough Backlog Grooming in order to be prepared for the next Sprint's planning meeting. The Backlog Grooming is a strategy to prepare enough work to begin next so that a rhythmic flow of work can happen.

When the Sprint is over there is a Sprint Review, when the Product Owner and the Team show the Team's Results to their Stakeholders. This is done for two reasons: to prove to the Stakeholders that the Team is moving in the right direction, and so the Team can get feedback on what they've done. If necessary, the Release Goals, Release Strategy, and Backlog are updated as part of the Review (or soon thereafter), considering the Review and any "business reality" changes the Stakeholders may have. When Teams are small they can rely on more intuitive reasoning to determine what the "right direction" is. As a Team grows they will see a need for more sophisticated techniques that use metrics to help them answer what the "right direction" is.

After the Sprint Review, the Team has an internal retrospective to analyze its performance and process. The Team decides what changes, if any, they wish to make to their process as a result of this analysis. These changes will be "enforced" by the ScrumMaster in future Sprints. To enforce something the SM will need to shift the focus to the issue at hand and then let the Team react. Telling the Team what to do is not desirable. Shifting the Team focus and thereby enforcing change is an art of the SM.

At this point the Sprint is complete, and the Team either begins the next Sprint, the next Release, the next Project, or disbands, as appropriate.

Quick Summary

Team of 7±2 does the work
PO provides the work requests
SM provides care for the whole team (PO/Team)
Team swarms on the work
Team is cross-functional
Team owns its process
PO provides validation for each work request
Work is done in short bursts < 30 days each (Sprints)
Work starts and stops with Planning and Review
Review demo for product; Review retro for process
Daily Scrum detects any adjustments needed
PO determines priority as a flow of work requests
SM observes and helps the whole team adjust
SM tunes the whole team for maximum performance

Cargo Cult Agile

By Manoj Vadakkan

We have been saying "there are no silver bullets" over and over again. But do we really believe that? In some ways, it is like the disclaimer we add to the end our e-mails. Nobody reads it, but the legal department makes us put it there. Aren’t we (the IT industry) treating Agile like yet another silver bullet? Everyone wants to "adopt" it! Everyone wants to say that we are Agile! It is becoming more like a "Cargo Cult" (See Notes 1).

During World War II, materials such as food, clothing, and tents were airdropped to equip the soldiers and the natives in the Pacific Islands. At the end of the war, the soldiers went home and the air cargo stopped coming, but by then the natives were used to the airdropped materials. Soon, they dressed themselves as ground controllers, wearing carved wooden head sets and waving landing signals in the hopes that these activities would attract those cargo planes.

In some cases, it seems like we just have a need to say we’re using Agile practices, even if we’re really not. We don’t use those old school requirements documents anymore, instead we create user stories. We estimate in story points; Fibonacci series is fun, and so are poker cards! Sure, we do release planning. We also do a Daily Scrum; well, we cannot really do it daily because our team members already have too many projects and meetings, so we just meet twice a week. Regarding user stories, we have to write them down in the form of detail specification because our testing team is busy with other projects and not available for the first few months to really participate. Additionally, we are required to have those documents signed by all parties, scan them, and upload them to the document management system. Otherwise, how would we know what we agreed to?

So if we think adding a daily (or mostly daily) standup meeting, estimating in story points, and implementing a few other things we find in the Agile/Scrum books will save us, well, good luck! Like the Cargo Cult, we can keep wearing our wooden head sets, lighting those run ways, and hoping for the planes to land.

Like the Cargo Cult, we are getting some of those superficial elements correct. But can we really attract the cargo planes with those elements alone? Do we really know what problems we are trying to solve? Do we really understand what we are doing and why?

In order to solve problems in your organizations, you need to look inside, not outside, to adopt yet another practice, process, or tool. You need to look at what problems you need to solve and identify solutions to those problems. Certainly, Agile/Scrum practices are proven in the industry. So bring that knowledge to your organizations in the form of training, coaching, or hiring. They can seed some of the options to get to your solutions. However, the solutions need to come from within the organization. That should be what "adopting" Agile/Scrum means. These practices need to solve the problems and achieve your organization’s goals.

Here are some activities that will help you identify problems and move towards a solution.

1. Do some soul searching: One way of doing this is to have an open space meeting. (See Notes 2)
• This will help you identify some of the problems you are trying to solve. (e.g. concept to cash takes too long)
• Help identify some of the possible solutions. (e.g. remove some of the communication barriers)
• Bringing people together will help the team take ownership of these problems and solutions instead of yet another mandated process that comes from upper management
2. Create a Product Backlog of concepts that the organization wants to try to solve the problems.
• Break those into tasks and assign resources.
3. Get senior management sponsorship.
• There comes a time when you will have to rethink the organizational structure in order to solve some issues. You can remove some of the organizational barriers only if you have senior management/leadership support.
4. Consider getting a coach, advisor, or someone who has done this before.
• A good coach will be able to guide you to possible solutions for your issues. Instead of just "adopting" some of those silver bullets like daily meetings and iterations, they will be able to guide you to solutions to the problems. A good, experienced coach can reduce the costly expense of experimenting.

There are a lot of articles out there that will help you in this transition. A comprehensive analysis can be found in Succeeding with Agile, a new book by Mike Cohn.

Have you seen Cargo Cult Agile in action? Tell us about your experience with Cargo Cult Agile.

Notes

      1. About Cargo Cult: http://en.wikipedia.org/wiki/Cargo_cult
      2. More about open space: http://www.openspaceworld.org/cgi/wiki.cgi?AboutOpenSpace

Five Scrum Short Stories

By Marko Majki

When I was first introduced to Scrum, I thought "What an easy and beautiful way to be efficient!" After years of doing Scrum, I found that it’s not that easy. It was easy to learn. And, as many times before, “easy come, easy go” was true. It was very easy forget easily learned facts of Scrum. I’ll tell you about some of the traps me and my friends experienced during Scrum implementation. Solving these was more or less successful, but if you recognize at least one of them in your environment, which you weren't aware of before, my article was a success. I will tell you five real stories about people who were on the edge of Scrum and how they succeeded in avoiding Scrum traps. My Scrum heroes' names have been changed to protect their identity. Let's begin.

Proxying Product Owner

"Beware of the ScrumMaster who thinks that he can permanently assume the Product Owner role," I would say. I've heard a similar saying before, "A good ScrumMaster can handle two teams and a great one can handle only one." If you try to do the ScrumMaster and Product Owner role at the same time, you're doomed. You won't be able to perform both roles correctly – that’s certain.

One day, Scott was told at the very end of a Sprint that the Product Owner on the project had to move to another project that had stalled. He was told to act as Product Owner proxy for some time. Scott and the team were in a highly dynamic and quickly changing business, and it was a pretty tough period for the team. The first issue Scott was facing was time. The Sprint was one week long, and he did partially succeed in resolving impediments and barely succeeded in preparing acceptable user stories during the first Sprint. The second Sprint was a total disaster. Impediments started to pile up, and Scott didn't succeed in preparing acceptable user stories. The Product Backlog was filled with a few essays, without good, smaller user stories. And Scott was a pretty good problem solver. He would have certainly been a great Product Owner, if he was focused only on this role. Simply, Scott didn't have enough time to do both roles well for the team. Another issue Scott experienced was context switching, but maybe this is the wrong term. A better term is perspective switching. That was very stressful. At one moment Scott was trying to solve impediments and at another trying to figure out which story would return the investment in the best way. How did Scott deal with this? He didn't. He told the stakeholders to delegate a new Product Owner. Even a non-experienced Product Owner is a better solution than a ScrumMaster acting as Product Owner proxy. Luckily, Scott's Product Owner returned and he was able to keep Scrum on the track.

ScrumMaster as a Team lead

Claire had a pretty strong technical background on system administration, networks, and Java software architecture/development. Top management considered this to be a great asset to the team she was supposed to serve as a ScrumMaster. Because top management had a foggy understanding of Scrum, Claire was considered to be a “Team Leader.” Claire was the most experienced programmer in this team, but didn't even have the role of developer. The other team members were really great developers and quick learners, but new to Scrum. They didn't quite understand the nature of her engagement in the project, even though she had tried to be pretty clear about her role. They knew Claire before this project and had respect for her as a developer. I suppose they expected her to deal with technical issues using her remarkable experience. This asset started to become a great burden for the team and for Claire personally. She knew that if she got deep into coding she wouldn't be able to act as a good ScrumMaster. The first Sprint Planning Meeting started, but when technical debt was discussed, everybody looked at her, expecting her valuable opinion. She remembered something that she heard once from a more experienced Scrum Coach. She asked the team to excuse her for some time and to continue the technical discussion without her. They were surprised, but after she left, they did continue. After some time she returned and they barely noticed her. She was satisfied with the result. When the meeting was finished, she asked the team if everything was ok and how they decided to address technical solutions. Everything was fine and the team was satisfied because they handled everything themselves. She suggested that they would feel better if they made decisions on technical stuff, and that they were very good developers. “Of course,” she said, “I'll give suggestions if needed, but I'm not supposed to make decisions. The team has the power to decide. My job is to serve the team and to be sure that the project and work are running smoothly.” Claire made an "impediment list" sticky note on the wall and asked the team to give her tasks whenever they wanted, no matter what issues they might have. Then they really understood her role on the project.

Support Departments Don’t Use Scrum

Robert was a Scrum Coach for a software department that developed in-house projects. They had used Scrum for almost a year, and were doing a great job. When Robert came to the company, the department was pretty messed up, but in a few months everything fell into place and the teams became hyper productive. This was recognized by top management, teams were regularly awarded, and everything was fine. But Robert was a little worried. At first, he was focused on the teams, and wasn't able to see the whole picture. Using Scrum, real issues were surfacing, but he was focused on the issues he had influence over, and the team was solving them. So, when impediments inside the department were minor, other impediments became visible. The first sign of trouble was that the Product Backlog was pretty empty. He talked with Product Owners and discovered that they couldn't get enough information to create acceptable user stories. “Why?” he asked. Simply put, nobody from other departments had the time to define what they needed, and when they needed some functionality, they needed it immediately. From his perspective, communication with other departments was an impediment, but he felt responsible to initiate the solution. Now, because teams were pretty self-organized and doing well, it was time to spread Scrum to the other departments. First he talked to top management about the situation in other departments and presented the idea about introducing Scrum. They hadn’t originally considered it, but were pretty satisfied with the re-organization of the software department, so they agreed. Robert explained that he didn't want to make this transition top-down, but would try with volunteers. He invited heads of each department to a working breakfast and explained Scrum, presenting potential benefits for the department using its principles. He asked them to bring a few team members to the next three meetings about Scrum. They were pretty shocked when he introduced some of the Scrum games, expecting a PowerPoint presentation. “Hey, you didn't even bring your laptop,” they said. “I don't need it,” Robert replied. After playing two games, he conducted a practice retrospective meeting, allowing the teams to reach their own conclusions. Then he helped them to make parallels with real situations that they were dealing with. It was quite refreshing and revealing for most of them. Then, he explained that Scrum was not a silver bullet, but a tool that could help them to understand the impediments and to enable them to work better. He asked them to consider it and to let him know if they would like to try Scrum in their environment. The next day, the chief of the technical support department contacted Robert, claiming that his team was overwhelmed and eager to try Scrum. "Great!" Robert said. "Let's start preparations for our first Sprint."

Disputed Definition of Done

Ulrich was a pretty experienced Scrum Practitioner. He knew that coaching a new team was going to be tough. They were all experienced programmers, but new to Scrum. Initially, coaching was tough, with much resistance and conflicts; a bumpy road that was now almost behind him. Eventually, things were much smoother because he knew the team's velocity and the team knew their velocity, which was much more important. Velocity was regarding to “DONE DONE” user stories. He remembered the issue the team had with this, their definition of done (DoD). As he explained at the very beginning, the team and the Product Owner had to reach an agreement on this. One of the guys came up with a DoD proposition, and the team and the Product Owner were ok with it. One of the items in this list was "unit test coverage of 80%." After the first few stories were "done," he asked the Product Owner to test the items from these stories. With the tool they had, it was easy to see a unit test coverage of 23%. Ulrich asked the Product Owner what he thought about that. He answered that he wasn't satisfied with that the result. "Why?" asked Ulrich. "Because these stories are not done," replied the Product Owner. "Do you need a unit test coverage of 80%?" asked Ulrich. "No, I don't know why they chose these figures, but if the team defined these, I expect them to meet these criteria," answered the Product Owner. And he was right. The Sprint ended the next day, and during the Sprint Retrospective, Ulrich announced that the Sprint had failed, which provoked a very emotional response from the team members. He explained the reason and showed them real figures on test coverage. "But why is this important? We did all the necessary tests. We didn't want to waste time unit testing trivial methods, such as getters and setters, and we didn't want to test something covered in integration testing," screamed the guy who purposed the DoD criteria. "Yes, you are completely right, but you promised something about unit testing and this was not accomplished. Could you tell me how you determined the proposed DoD?" Ulrich asked. "Well, I didn't know what criteria to propose, so I copied some from a Scrum blog, which looked great at this time." "Ok, guys," Ulrich said, "this is my failure as Scrum Coach as well and it's my fault that you didn't understand the meaning and importance of DoD. DoD is different from team to team and project to project. This is not a general standard that should be implemented in all situations. And Scrum is not a standard that can be implemented the same way in all situations. Those are tools, which help you make better software, but you need to involve your intelligence, energy and creativity to make it happen. Ok, let's do the job. Let's create a DoD acceptable to us and our Product Owner. You are experienced developers and you know everything about good programming practices. You've seen one of many possible DoD's. Let’s make new a DoD we can commit to."

Estimations in hours

Marianne was inexperienced, but passionate about Scrum. She started her first Scrum project with the team and was thrilled, anticipating her first ScrumMaster job. The team knew about Scrum and was interested in trying it. Before the first Sprint Planning Meeting, the Scrum team agreed on some conventions and one of them was estimating user stories and tasks in hours. This was the natural choice for the team and Marianne agreed with that. Estimating in user story points was awkward to the team, since they couldn't figure out how to correlate this to some real measurement unit. So they started their Sprint meeting and started estimating. They estimated all user stories and chose ones they could commit to finish until the end of Sprint. Then, the Product Owner stood up and spoke. "Well, guys, you just committed to finish user stories worth 230 hours and you have 400 working hours in your Sprint. Even if we add 30 hours for the meetings during the Sprint, still there's 140 hours in the Sprint you should commit to. Is my math correct?" "Yes, you're right," said the senior developer, "but a working hour cannot be equal to a development hour. We have to have time to think about the story, business process, architecture etc. So, coding functionality is not the only job we're working on. Development is the intellectual process, not an exact, simple operation. We really didn't underestimate, in my opinion, and we didn't want to „steal‟ some time. I just feel that we cannot commit to more than we already did." "Ok guys," continued the Product Owner, "I believe you were honest with the estimations and I think that this is a fine velocity if you meet those commitments with your definition of done. I just can't figure out this difference and it would be difficult for me to explain this to the stakeholders." It was good timing for Marianne to do some facilitation work. "The way I see it," she said, "we have a problem with the measurement unit. The Product Owner is satisfied with the features to be developed in this Sprint, but somehow user stories measured in hours don't provide the real information, correct? Furthermore, this difference in time is causing confusion. If developer hours cannot linearly correlate with real time, why don't we say points, not hours? After a few Sprints, we will be better in our estimations in these points, correct? And there will be no confusion with working hours and time. After a few Sprints, we will know our velocity in these points and will have more experience in estimating work. Stakeholders will get their graphics in these points and will be able to monitor progress daily. What do you think?" The Product Owner was delighted with this idea, knowing that he'd be able to show diagrams to the stakeholders in real time, and the team was relieved from the pressure they felt after Product Owner's speech. Marianne scored her first small victory helping her team to overcome its first impediment and potential conflict. After a few Sprints, they got used to estimations in user story points, so it came naturally to them.

I hope that you enjoyed these real Scrum stories and that you can recognize some of the situations in your everyday Scrum practice. Please comment on them and comment on how you would deal with these situations.

ScrumBut: Construct the Sprint Backlog According to Individual Specialist Capacity.

By Raymond Shanley

I was recently discussing Scrum with some Scrum Teams, and one team was convinced that a certain ScrumBut was a better way to do things. This particular real life ScrumBut is to construct the Sprint Backlog so it has just the right amount of work for each specialist in the team based on how many story points each individual can deliver in a Sprint. Trying to argue that this approach is against the Scrum rules is not enough to convince people not to use it. At the time of the discussion I was unable to convincingly express why the approach is counter-productive. Afterwards I thought it must be that the problems caused by the approach are not immediately obvious. So I decided to run through an example on paper, which I will now present.

The product concerned is already a few years old and individual specialists have been responsible for parts of the product over those years. The team changed over to a Scrum approach in the past year. So due to the historical situation it is true that a specialist can finish an item in his or her component quicker than someone else. In order to change this situation, learning and knowledge creation would be necessary.

Before we continue let’s summarize the normal Scrum approach. The Team gives estimates for each item in the Product Backlog. The Product Owner then prioritizes the items according to value (and other factors can also be considered such as risk and dependencies between items). The Product Owner is responsible for generating highest value for the stakeholders in a sustainable way and generally wants to finish the highest value items first. The Team is responsible for figuring out how to deliver the items. There is a clear separation of responsibilities between Product Owner and Team. If there are specialists in the Team, the prioritization occurs independently of how much work these specialists are capable of handling in a Sprint.

Ken Schwaber gave ScrumButs a particular syntax: (ScrumBut)(Reason)(Workaround). So here is a formulation of the ScrumBut in this article using the standard syntax: "We use Scrum, but (we want individuals in the team to have just the right amount of work in his/her area of expertise) (so we construct the Sprint backlog according to individual specialist capacity)".

I will run through a concrete example for 4 Sprints first using the ScrumBut approach mentioned above and then using the normal Scrum approach. This is a simple example. It would be possible to construct a more complex example but the same basic problems would emerge so let’s keep it simple. In this example I assume that the Product Backlog prioritization does not change between sprints. If prioritization changes (like in the real world) the problems discussed here are at best only masked slightly.

Let's say we have 5 components in this particular product being developed by the Team. Each component is developed by 1 specialist and each specialist is capable of producing a slightly different amount of work per Sprint as in the following table. The team velocity is calculated as the sum of the individual velocities.

Now let's say our initial product backlog looks as follows. The letter represents the main component affected by a given story. I generated the order of the backlog by writing a list of the letters on a sheet of paper as randomly as possible. Then I wrote story points beside the letters also as randomly as possible (values between 1 and 3).

Summary of the stories on the Product Backlog so far:

ScrumBut Approach, Sprint 1:

If we now go through the Product Backlog and construct the 1st Sprint Backlog according to how much work each specialist can take on we get the following:

So the items that fit in the sprint are 1, 2, 3, 4, 5, 7, and 8, which gives a total 13 story points. Estimated velocity was 17. Item 6 did not fit in because developer C (the developer of component X) was already fully loaded. If specialists have spare time they can either do some other task outside the product scope or take on an item in their specialization lower down on the Product Backlog.

ScrumBut Approach, Sprint 2:

Summary of new items that entered the Product Backlog before the Sprint 2 Planning Meeting:

Below is the Product Backlog for Sprint 2, showing old items and the new items that were added before the Sprint 2 Planning Meeting. The last column shows whether the story made it into the Sprint Backlog or not (as usual, calculated based on individual developer capacity).

Note that item 6 is too big to be done by developer C in one Sprint. This could possibly be split into smaller stories. However, splitting it still does not alleviate the basic problem that developer C appears to have too much work, which creates a bottleneck in the system.

Note the pattern starting to appear, which is that higher priority items are being replaced by lower priority items in the Sprint.

The items that fit in this Sprint are 9, 10, 11, 12, 13, 15, 16, 17, and 20, which gives a total 14 story points.

ScrumBut Approach, Sprint 3:

Summary of new items that entered the Product Backlog before the Sprint 3 Planning Meeting:

Just as for the previous Sprint, here is the state of the Product Backlog. The final column shows whether the story made it into the Sprint Backlog (again, based on individual developer capacity).

The items which made it into the Sprint are 14, 19, 21, 23, 25, 28, 29, and 30, which gives a total of 13 story points. In this Sprint it is becoming clear that prioritization is hit-and-miss. Roughly every 2nd item needs to be replaced by a lower priority item.

Also, component X is clearly a bottleneck. At this point it might be possible to intervene and say developer C needs help and ask someone else to learn X. However, there are at least two disadvantages to this. First, it is a reactive rather than a proactive approach. It is at a late stage that developer C is getting help and he/she has so much work to do it will not be easy for him/her to take the time to show someone else the ropes. Secondly, this monitoring of potential bottlenecks requires additional administrative overhead. Someone needs to be constantly keeping an eye out for the problem occurring. With the normal Scrum approach you get this balancing automatically.

ScrumBut Approach, Sprint 4:

Summary of new items that entered the Product Backlog before the Sprint 4 Planning Meeting:

Same as for the previous Sprint here is the state of the Product Backlog. The final column shows whether the story made it into the Sprint Backlog (based on individual developer capacity).

The items which made it into the Sprint are 18, 24, 31, 33, 34, 35, and 36, which gives a total of 12 story points. In this Sprint more items were taken from the bottom half of the backlog than from the top half.

Scrum Approach, Sprint 1

Now let’s walk through the same example with the normal Scrum approach so we can compare the results.

The estimated velocity of the team is 17 but let’s just take on 14 story points to provide for cross learning. The top 7 highest priority items make it into the Sprint.

Scrum Approach, Sprint 2

This time we also take on only 14 points to allow for cross learning. The top 8 stories make it into the Sprint.

Scrum Approach, Sprint 3

This time let’s take on 16 out of an estimated 17 velocity as less cross learning is necessary as time goes on. In this Sprint the top 9 items are taken into the Sprint.

Scrum Approach, Sprint 4

For the final Sprint in this example let’s take on 16 out of an estimated 17 velocity. In this Sprint the top 9 items are taken into the Sprint.

Let's compare the items remaining in the Product Backlog at the beginning of Sprint 4 of each approach:

Conclusion

The example described in this article demonstrates that dangerous bottlenecks can develop if using the given ScrumBut approach. It also demonstrates that the ability to prioritize properly is diminished by the same approach. These are not the only problems caused. Other problems include:

• The so-called team is operating more as a collection of individuals. There may be no common sense of responsibility.
• One-piece flow may be affected. Parts of stories may be finished at the end of a Sprint and other parts missing.  
• The team has no redundancy built in, which means if someone goes on vacation or gets sick there is a problem.  
• Self-organization is effectively being killed. The team does not have a chance to decide itself the best way to deliver the functionality for a Sprint. This may also lead to motivation problems (intrinsic vs. extrinsic motivation).  
• There may be an issue with trust: Does the Product Owner trust the team to deliver on a Sprint?

My advice is to avoid this ScrumBut even if it leads to reduced productivity (perceived or not) in the short term. Keeping this ScrumBut will lead to more serious problems in the long term.

Are you ready for Agile? A Checklist of Questions to Consider Before Starting a Large-Scale Agile Adoption

By Ramesh R. Donnipadu, Bala Kishore, Pete Deemer

Abstract

The ability to deliver business value earlier and more often, increase productivity, and improve employee morale is compelling many organizations to embrace Agile approaches to software development. There is a wide array of training courses, consultants, and books available to help teams learn the basics of agile development, but these often focus on the team-level challenges, and overlook some of the larger organizational issues that may either help or hinder the transition to this new way of thinking and working. This article attempts to outline areas where many organizations encounter difficulties in their embrace of Agile, in hopes that others can be better prepared to meet these challenges.

Checklist

Depending on the size of the organization and current processes followed, different organizations may face different challenges in their Agile adoption. This section lists the most common difficulties that your organization may encounter in the early days of embracing agile development. Some of these items are not even related to Agile per se; they‟re just sound Engineering or Management principles, which any smart organization normally follows. But, these are not so obvious until you get into the thick of the things. Regardless, not attending to these issues at the outset could lead to frustration for the organizations getting into agile development.

This Checklist is expected to help you evaluate the preparedness of your organization to these new challenges.

Management

1. Do you have Management’s support?

Among the challenges a team may face in the early stages of adopting Agile, the most important one is winning the confidence and support of top management. If you do not have a genuine commitment to change from your top executives, you are not likely to be successful. Win their confidence support before you set out your journey. Be upfront with them on the roadblocks you may face and lay out your plans on how you intend to overcome them.

In some cases, the senior executives and junior technical staff may be enthusiastic to “go Agile,” but there may be a lot of skeptics in middle management. This could be due to the fear of losing control over their teams or inability to distinguish Agile development from “cowboy coding” or apprehension on the quality of the product or lack of documentation. You need to allay their fears by showing concrete examples.

What if your leadership fails to agree with you? You can still go ahead with Agile, but you are on your own in dealing with the challenges.

2. Is Proper Training Provided to the Organization?

The industry-standard training for Scrum teams is the Certified ScrumMaster (CSM) training course, conducted by a Scrum Alliance Certified Scrum Trainer, and we strongly recommend that this training be provided not only to ScrumMasters but also to team members, managers, and others in the organization that will be interacting with the Scrum teams. In addition, it's imperative that Product Owners complete Certified Scrum Product Owner training. If great results are to be achieved, everyone needs to understand how to “play the game” well.

This training in the fundamentals of Agile is just the foundation for success, though, and to be successful, there are other new skills that will have to be learned. First, Agile development quickly makes visible any deficiencies in teams‟ ability to work together closely and produce high quality functionality in the span of an iteration. Many teams require training to learn better coding and testing practices, whether in the basics of test automation, refactoring techniques, or in practices such as Test-Driven Development. In many organizations, team members have highly specialized skill sets, and often have difficulty working closely together as part of a cross-functional team; they may require coaching in how to do this successfully. Often, the most effective way to retrain the team in cross-functional behaviors is to “seed” the team with one or more members who are experienced in this way of working.

Another good way of accelerating learning is to start a study group that meets periodically to discuss various aspects of Agile development before the training takes place. During this period the team can read literature available on the Internet, starting with the Scrum Alliance website [www.scrumalliance.org]. We found these meetings are extremely helpful to come onboard quickly in terms of understanding the new practices and mindset, and adopt it to our environment.

In addition to new technical skills, teams may also require more education in their product domain. In Agile, developers are not “software robots,” blindly implementing software specifications; rather, we want them to be full partners in the development effort, helping the Product Owner achieve maximum business value. For this to occur, they need to have a working understanding of the business and technology context for the work they are doing.

Many organizations make a solid investment in training in Agile technical practices, but overlook training in the soft skills needed to really get the most from those practices. ScrumMasters, Product Owners, functional managers, and executives should receive training in facilitation skills, Agile retrospective techniques, dispute resolution, root cause analysis, and systems thinking. All of these are practical necessities for skillfully coping with the myriad dysfunctions that Agile development will quickly surface.

3. Did you train your Product Owners?

Strong product ownership is a key to the success of Agile development, since it is this group that bridges the gap between the end customers, management and IT. A very thorough understanding of the responsibilities of the Product Owner, how to work with customers, the team and stakeholders to achieve maximum ROI, and how to be effective with the essential practices are required.

When faced with large-scale development effort, it is often recommended that all teams work from a single, project-wide Product Backlog, as opposed to having multiple, team-specific Product Backlogs; this will help reduce the duplication, redundancies, and conflicting directions that can often result from the latter.

Unless your Product Owners are equipped with these skills, you are not going to see the big wins from Agile adoption.

4. Do you have enough space?

Agile principles emphasize face-to-face communication wherever possible. If the individual members of your Agile team sit at different locations, the overhead of communication reduces their effectiveness. It is mandatory to rearrange their seating so that it improves informal communication within the Scrum teams. Get the teams co-located into their individual team spaces even if you have to convince your facilities, HR, VP or CEO.

You also need to ensure that they have enough free space for informal gathering around a computer for a quick walk-through, their daily stand-up meetings etc. Also, ensure that the teams have adequate wall space, white boards, flip charts and writing material.

5. Are all your support teams on board?

Organizations make all efforts to train the teams that are adopting Scrum. But, often they ignore the need to familiarize other support teams. If the development team is going to be successful with Scrum, they need to have full support of any specialists who provide support but are not members of the team, for example, DBAs, Sys Admins, or the Configuration Management team. Unless they know the constraints and limitations of your Scrum teams, you are not likely to receive their deliverables and meet your Sprint commitments.

Get at least one representative from each of these departments enrolled in the Scrum training. Try to get these specialists included in your Scrum teams, ideally as full-time members of the team, or at least in the role of consultant.

6. How quickly to scale?

Often, large organizations attempt to roll out Scrum across several teams simultaneously; what some people call the “Big Bang” approach to change. Tempting though this may be, the risk of such an approach is that systemic or large-scale dysfunctions (which afflict many teams across the organization) will be surfaced by many teams simultaneously, and will have to be resolved quickly and for many teams at once. This is both very challenging and very chaotic. It may be easier to begin Scrum with a small number of teams, try different solutions to solving these baseline dysfunctions, and be able to provide best practices to later teams that follow in their adoption of Scrum. As the organization gains confidence and competence in Scrum, more teams can start practicing it.

7. Is an appropriate attrition strategy in place?

This may not be an important item in difficult economic times, but for organizations susceptible to high attrition, dealing with this problem could be very challenging. Unlike in traditional models, Scrum believes in tightly gelled teams of individuals with a core competency and multiple cross-functional skills. As Scrum teams are smaller, losing a single member could prove to be a significant setback for a team. Even if you find a quick, equivalent replacement, it will take some time for the new hire to get up to speed, bond with the team and start delivering.

Scrum provides the benefit of teams, but also makes more visible the disruption when teams are broken or changed.

Have a trained pool of engineers available, who could substitute an unexpected departure in your team.

8. Can your engineers appreciate the purpose behind a user story?

A competent technical team can convert a user story into database tables, Controllers, tags and Form elements fairly quickly. But some teams may have difficulties in comprehending the motivation or ROI behind a feature they are implementing. For Agile to be successful, it is critical that all members of the development team (developers, testers, etc.) “get into the Product Owner‟s head” and appreciate the rationale behind a user story. They should keep questioning the objective of major decisions and suggest alternative implementations where possible.

Otherwise, one risks ending up with brilliant technical implementations that fail to meet the business goals.

9. Module assignment to teams

If you are planning to assign different software modules to different Scrum teams and you expect them to have exclusive check in privileges on their modules, you need to be very cautious. While it is a good idea to let individual Scrum Teams master specific software components, if you implement a user story that requires multiple Scrum teams to work on it, all hell breaks loose. The interface design, hand off, and integration between multiple teams introduce a lot of waste.

Also, avoid restricting teams from touching other modules based on their ownership. You can better enforce the code ownership with good code reviews and refactoring policies.

Code

10. How tightly coupled is your system?

If your code base consists of tightly coupled modules, and you have a large number of Scrum teams, chances are that they will be stepping on each others‟ toes constantly. The problem will be more acute if the Sprint or release cadences of the teams don‟t align.

If possible, spend some time re-organizing your code base to minimize the inter-module dependencies. This exercise is well worth the effort as the code will be more modular and less tightly coupled, which in turn will create better „code‟ conditions for the Scrum Teams to do their job, and enable the teams to more quickly produce more business value.

11. Do you have good Unit/Automation test coverage?

At the heart of Scrum is the delivery of potentially shippable software at the end of each Sprint. For this to happen, test automation is a must. If you do not have a comprehensive set of automated unit tests that are tied to your build system, you are likely to spend more time in testing and debugging than necessary, and it will be difficult to end each Sprint with a fully tested (and fixed) system. In addition, automated tests give the team confidence in making changes; they know that if the change breaks other parts of the code, it will be immediately visible.

Strengthen the foundations of your code base by adding as many unit tests and automation tests as possible. Teach your developers the art of Refactoring, if they don't already know it. Tools like Emma, Jester and Cobertura will help you measure the coverage of unit tests.

Tools

12. Do you have good collaboration tools?

This item is critical for the geographically distributed teams. Agile requires a close interaction among team members, so you need to ensure your team has all it needs for effective communication. Use video conferencing, telephones, emails, instant messaging, and Skype as much as possible. VNC, WebEx, Sococo are other useful tools for the team collaboration. If you are planning to introduce a tool such a Rally, VersionOne, or ScrumWorks, make sure the teams themselves have an opportunity to evaluate them fully before making a decision.

13. Do you have a source code repository replication system?

This item is more relevant for multi-location teams. Nothing can be more frustrating for your remote teams than accessing the repository on a slower network. Due to shorter release cycles, your teams would be doing more frequent checkins, checkouts, branching, merging than they normally would if they were using traditional methodologies. Make sure you have a fast, reliable repository replication solution in place before you roll out Scrum.

14. Is your build and deployment system fully automated?

It is difficult to imagine a modern software development organization not wanting to automate their build and deployment activities. Design your build and deployment processes to be completed in a short time, say, 30 minutes. This should include executing the test cases and certifying the build. It is even more preferred to have a continuous integration (CI) policy before you move to Scrum. The CI will highlight the build/integration issues and help the teams identify and fix the issues quickly. When the teams are working in short time-boxed iterations, any time gained in their iterations will be valuable.

Alternately, if you require a lot of manual intervention in the build and deployment, your teams‟ velocity is going to be affected.

Others

15. Do you have adequate Dev and Test environments?

If you would like to have dedicated Dev and QA environments for individual (or groups of) Scrum Teams, you need to plan them in advance. You also need to ensure you have enough hardware, software licenses, and IT support staff to build or maintain those environments. Since budgeting, getting approvals, ordering, hiring, and training take a while, you need to plan this well in advance.

16. Do you have enough monitoring/health-check systems in place?

If you are working with a large number of environments and each of these environments has multiple servers, databases, networks and other third party components, you need to have a robust monitoring system in place. Zabbix and Hobbit are a couple of good tools you could consider for monitoring the health of your systems.

Conclusion

Due to the wide philosophical differences between traditional and Agile methodologies, a few organizations are facing challenges and getting frustrated with their results while adopting Agile. A lot of these challenges can be met effectively with decent preparation. This article presented a checklist of items to be considered along with a mind map for the benefit of teams getting into Agile.

References

1. Scaling Lean & Agile Development, Thinking and Organizational tools for Large-scale Scrum,Craig Larman, Bas Vodde, Addison Wessley 2009
2. Scrum & XP from Trenches, Henrik Kniberg
3. 10 ways to screw up despite Agile and XP, Henrick Kniberg at Agile 2008, Toronto
4. Art of Agile Development, James Shore, Shane Warden, O‟Reilly Media 2008
5. Agile Testing: A practical guide for Testers and Agile Teams, Lisa Crispin and Janet Gregory