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.

Managing Myopia with Release Burndowns

By Pat Guariglia

The burndown chart is one of the staples of Scrum. Many of us use and love it. Its simplicity and straightforwardness makes it an effective tool for project teams, management, and for the passive observer. A well-displayed burndown chart is one of the greatest information radiators you can use. From time to time, however, project sponsors, functional managers, and others on the periphery misunderstand its purpose. They can sometimes view a project burndown as a short-sighted tool that fails to provide insight into how the project’s end date is affected when features and tasks are re-prioritized and/or moved out of an iteration to meet the sprint’s burndown target. Stakeholder education certainly mitigates the risk of this misconception, but introducing “whole” project burndown charts, or release burndowns, seals the deal for upper management.

The effectiveness of my team’s burndown charts is demonstrated daily. Once I started using burndown charts regularly, I became a better ScrumMaster and communicator, plus my teams became more productive and predictable. I became almost proud of the success of using burndown charts on my projects and felt the need to talk about the charts and use them in presentations to upper management. This served me well and poorly at the same time.

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.

Why Go Agile—Why Should I Embrace Change?

By Bachan Anand

Has someone in your organization taken time to explain to you why you should embrace Agile? Ask yourself, why would "I" as a CIO/ Business Stakeholder / Developer/QA/BA implement Agile? Teamwork is very key in any organization; however, at the end of the day, we are all individuals, and it is very important for each person to understand how Agile practices add value to their work, to their goals, and to their life at large. The good news is you will discover it once you get started with Agile as the changes are organic and ingrained into the values Agile holds. This article will be beneficial for people who have yet to take the leap and are testing the waters, and also for people who have done it all and are continuing to learn, as they can add value by sharing their experiences.

So why go Agile? No matter who you are or your role within an organization, going Agile means different things and yields different value.

CEOs –less wasted work by your organization and improves value for your investors.

CIOs – sets a compelling vision for your team, makes your stakeholder meetings easier, and improves communication with business partners at every level. With Agile you will realize an organization with higher transparency and less political agenda.

Business Users – will make them well aware of work that is in progress, and gives them opportunity to give feedback and get what they want.

Business Stakeholders – promotes transparency for business stakeholders in IT matters, allows them to see results faster, gives them an understanding of why some things take the time they take, and helps them plan better for the future.

IT Senior Leadership – provides a very concise and accurate burndown chart at each release and each iteration level. It also helps senior leadership focus on the forward thinking strategic activities while the team is focused on the short term goals.

Team Leads – puts the focus on Leads to be mentors and share with the team knowledge they have assimilated in their career.

Project Managers – puts focus on the Team to come up with a plan, with a detailed task list and estimates for every iteration, which the Team commits to. Agile sets the stage for project managers to better understand the Team and the technology, and to support the Team by removing impediments.

Architects – Agile principles focus on precision and getting it done right, architects can focus more on strategies which will take the organization to the next level of success, instead of constantly worrying about whether the team will take shortcuts.

Developers – through clear acceptance criteria, test driven development and feedback from testers during the development cycle, developers can produce bug-free code and improve their morale.

Testers (QA) – sets the stage for testers to work closely with the Team and ensure the quality of what the Team has committed to, and not be just defect finders.

Business Analyst – helps to keep the BAs focused on asking powerful business questions, and encourages them to partner with the Team to identify the expected behavior of the system through user stories and acceptance criteria.

Organizations – Imagine the growth that you can expect when the whole organization has the opportunity to constantly review and take corrective action instead of waiting for the project end phase or the yearly performance review.

Families – will improve quality of life as you will see less burn out and long hours as wasted work is reduced and deadlines are met.

Everyone – Agile is something for everyone. These are principles you can incorporate in every area of your life. It encourages collaboration at home, at schools, and church, empowering the next generation, creating a vision for yourself, and setting goals for shorter duration.

The world – think about some of the challenges that we have in our world and how collaboration, empowerment, transparency and constant retrospective can bring about changes in our political system, governments, schools, and religious organizations.

I want to end this article with a quote by Martin Luther King Jr.,–"Take the first step in faith. You don't have to see the whole staircase. Just take the first step."

Take some action and you will discover the benefits Agile provides you. Let's do it, Let's go AGILE!!

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.

Challenging inertia through Scrum

By Rahul Sawhney

Inertia is defined as a state of being lazy, sluggish or indifferent. Challenging inertia is about challenging status quo in an organization. It is about how things should be done differently compared to how they are done now. Organizations sometimes become susceptible to failure as they are unable to challenge the status quo due to various reasons.

This is as relevant to software development as it is to any other aspect of an organization’s functioning. In this article, we will examine the following reasons for organization inertia, the consequences for software development, and see how Scrum can help with the following:

• Size of the organization
• Inefficient structure
• Too much or too little process
• Poor performance management

Size of the organization

How does it cause inertia

Slow decision making

As organizations grow in size, managing scale becomes an issue. Bigger organization means management decisions have a bigger impact. Wrong decisions can put the organizations at risk and therefore it becomes necessary to consult a variety of stakeholders within and outside the organization. This implies that the time taken for arriving at key decisions becomes longer.

The increased timeframe for making decisions is understandable for issues that impact core functioning of the organization. However, it is definitely not suitable when the organization needs to adapt its products in a dynamic and tough market.

Consequence

Many organizations do not understand this problem and fall into the trap of slow decision making, even for product development. When innovative ideas fail to reach the customers on time, competition gets an undue advantage. Slow pace of decision making can result in missed opportunities, lost revenue and increased customer attrition. Thus, regardless of their size, organizations need to deliver the right functionality at the right time to their customers.

How Scrum helps

Role of Product Owner

• Ownership of the product backlog and prioritization encourages faster decision making and responsiveness to customer needs even in large organizations. Controlled, yet responsive management of changing requirements helps managing scope with improved turnaround time. The product owner makes sure that the team does not lose sight of what is most important for the customer.

Customer reviews and frequent releases

• Reviews and product demos at the end of each sprint gives the customer representative more clarity on how the end product should work and look. This helps in reducing wastage of effort and money into development of low priority features, when high priority features need more functionality that has yet to be developed.
• Early feedback from these demos ensures the team makes necessary changes related to the most important functionality of the product in the early stages instead of struggling with issues later when it is too late.
• For large organizations the cumulative impact of late identification of issues can be very costly and difficult to ascertain. However, as multiple units within the organization implement Scrum, the positive effect is amplified and inertia is reduced immensely.

Inefficient structure

How does it cause inertia

Communication

Inefficient organizational structures lead to wasted time, effort and money. The wastage mostly results from poor communication channels between people regardless of their team, unit or department. They are also a reflection of an organization’s lack of sensitivity towards customer needs. Traditionally, team members are forced to work as analysts, designers, user interface developers, middle tier developers, database developers, and testers. Work is divided depending on specialization, and it moves from one person to the other in a sequential manner. Such structures create artificial boundaries between people that are difficult to cross. They create a decision vacuum, wherein the buck passes from one person to the other forever, and the issues are resolved at such a slow pace that they would lose their relevance by then.

Power Politics

Inefficient structures promote power politics. They create an environment where people are made to compete with each other endlessly. This often results in situations where they cross each other and spoil relationships in order to get ahead of each other. In such situations, collective ownership is not given its due importance. Often work assignments are driven by authority and processes rather than teamwork and collaboration.

Reduced innovation

Inefficient structures make innovation difficult. Since everyone is focused on their own activities rather than delivering complete functionality, few in the team can see the bigger picture of how what they are doing impacts the end-user. Therefore, sources of new ideas to create innovative products are few.

Lack of collective ownership

We have seen this with step-wise approaches to software development. Business analysts and business owners are responsible for requirements, Architects are responsible for high level design, Designers are responsible for low level design, Developers for coding, Testers for testing, Integrators for integration, and Project Managers for planning, tracking and coordinating their activities. In such a situation, it is the project manager who is blamed, not the team, when a project is delayed. Usually, one way or the other, team members can easily find excuses for not delivering on time by pointing in another direction. Although this works well for everyone other than the project manager, it is the customer who ends up paying for all the inefficiencies. And no one likes paying more than the real value of the product.

Consequence

The problems with inefficient structure are too many and too difficult to resolve. Due to inefficient structure, customer interests take a back seat as everyone involved views his/her interests as top priority. There is often mistrust of the “other” groups and team members as the blame game can start anytime if anything goes wrong. Due to this people play safe. They only do what they are "supposed" to do, or as per the “defined” compartment to which they belong.

The dysfunction is easier to observe at the team level. Some examples are: “Coding can only start when the design is over,” “No changes can be entertained in the requirements since design is already over.” However, the issue extends beyond the team level. When the team size is large or when multiple teams, units, departments and organizations are involved in creating a product, it becomes even more difficult to acknowledge and resolve. It is also possible that there are vested interests in ensuring that the conflicts remain and politics and emotions prevail over common sense. Ultimately, if these issues are not addressed, the customer pays an extra price or gets a delayed product.

How Scrum helps

While there is no easy answer to solving these structural issues, an advantage of Scrum is that it helps in making the dysfunction visible and allows the organizations to take corrective actions. Other than that the following points are worth mentioning.

Keeping the team cross functional

• This reduces bureaucracy and time lag from making decisions at the team level. A cross functional team does not have artificial walls and naturally communicates better internally and with external stakeholders. Teams change focus towards delivering the functionality as a whole instead of delivering one part of the work (e.g. Design, User Interface, Middle Tier, Test etc.). This not only helps team members learn multiple skills, but also aids in immensely de-risking the projects through collective ownership.

Daily Scrums and Scrum of Scrums

• Focus on resolving impediments quickly improves collaboration and avoids getting into blame games. Scrum meetings keep the entire team engaged in the discussions and provide a clear list of impediments towards progress. These meetings also help team members in supporting each other to meet their joint commitment to the product owner. They enhance teamwork and collective ownership, thereby improving communication. When Scrum meetings are conducted well, structural separations between the team members, which slow down the process, tend to fade away.

Sprint planning workshops

• Prioritization of requirements in the product backlog provides better visibility to the team about what needs to be developed and improves transparency in decision making.
• Since the overall scope can be changed at the beginning of every Sprint, business concerns for new requirements are met. Likewise, the IT team's concern about giving upfront commitment on a plan is also addressed, since with Scrum, it is understood that plan needs to be revisited in every Sprint.
• Sprint planning workshops improve collaboration between the business, development, testing, user experience and other groups. These workshops align the entire team towards customer needs and make them give a joint commitment to plan.
• Since all concerned stakeholders are involved in the exercise of scoping and planning, there is a substantial reduction in power politics and improvement in communication, collective ownership and innovation. This eventually benefits the end customers and the organization.

The role of ScrumMaster

• ScrumMaster plays an important role by serving the team and protecting it from outside interference. By helping the team in following Scrum practices, the ScrumMaster ensures that issues are resolved as fast as possible. The role of ScrumMaster helps in improving communication and collective ownership of the team.

Too much or too little process

How does it cause inertia

Artificial Lags

Lack of appropriate levels of process introduces lags that have an undesirable impact on team performance. For example, too much or heavy process leads to an excessive waiting period due to unnecessary checks at every step in delivering the system.

Chaos

While lag is introduced by heavy processes, chaos is introduced by too little process. When there is chaos, team members do not know where to go and whom to communicate about what. Without processes, it becomes a free for all. It is easy to understand why typical software projects need a process wherein communication is well managed and roles are well defined.

Consequence

Heavy processes promote bureaucracy and reduce productivity because, due to the lags they add, things move slowly. As a result, the team is unable to deliver results with low turnaround time and eventually it results in customer dissatisfaction.

How Scrum helps

Just enough documentation and continuous collaboration

• Documenting the needs of users in a concise, yet informative manner and supplementing it with planning workshops, gives the development team a good perspective on end user needs. This eliminates the need for documents to float around within the team for multiple review/rework cycles and reduces a lot of waste.
• Collaboration during planning workshops ensures that all stakeholders have a better understanding of the requirements. This helps in designing better test cases and better code. Eventually it reduces the amount of rework required during later stages due to poorly understood requirements.

Short feedback cycles

• We may encounter several situations where the functionality developed in a Sprint needs to be revisited. For example, we may find that user needs have not been implemented to satisfy the business goals due to bad design/coding, or the requirement was poorly communicated to the team. We may also find that the customer representative changes his view on how the requirement should "actually" be delivered by the time Sprint ends.
• Scrum makes dysfunction visible and encourages bottom-up feedback. Short feedback cycles of Scrum allow corrective action to be taken almost immediately and satisfy the needs of higher priority functionality in the product backlog.

Team Retrospectives

• Just as short feedback cycles help us in revisiting the contents of product backlog regularly, retrospectives allow team members to periodically inspect their ways of working and adapt their processes locally.

Poor performance management

How does it cause inertia

Ineffective goal setting

Sometimes individual goals are set with a view to encourage competition within the team. In software development, this could be counter productive if the parameters selected do not encourage team work and team performance.

Improper status tracking

Monitoring status is an important activity from the perspective of team performance. If the team does not track progress or only tracks activities that have been completed, it could be in for a surprise when the project nears completion. Moreover, if tracking progress is more of a centralized activity instead of team activity, there is a high likelihood of status not being reported regularly or correctly as team members may stop seeing the true value derived from status tracking.

Infrequent reviews

Tracking performance after large intervals makes it difficult to assess performance accurately. Due to this the feedback can be incorrect and/or ill-received.

Consequence

Ineffective goal setting could lead to unnecessary conflicts in the team. It might not perform to its fullest capability in normal situations and could even fall apart in critical situations.

Late surprises due to improper and infrequent status and performance tracking could cause the team and its members to slip from their goals. They might deliver later than committed, deliver with lesser scope or deliver by cutting quality.

How Scrum helps

Metrics focused on team needs

• Working software is the true measure of progress for an agile team. Measuring and setting goals against working software provides the largest benefit. In addition, metrics that focus on day to day activities help the team in assessing its performance against its way of working. For example, the team could track number of build failures and number of acceptance test failures in the integration environment. It could also track how well it follows Scrum and other agile practices it might be using.
• By measuring metrics that are related to team performance and setting goals with respect to those metrics, the team can continuously improve its way of working and give better output.

Burndown charts

• Burndown charts provide visual progress of team’s activities and make status tracking a de-centralized and fun activity. They not only track what is completed, but they also track what is pending on a daily basis. This improves the team’s chances to deliver on time, thereby enabling them to fulfill customer needs on time.

Frequent reviews

• Frequent delivery of working software with Scrum allows the team to review its performance frequently and make course corrections as needed. Frequent reviews of the team’s performance reduce the room for lethargy and provide an incentive to deliver better regularly.

Conclusion

Scrum focuses on results, quick turn around time, short feedback cycles, and collaboration and relevant metrics. This helps an agile team in influencing issues related to size and structure of the organization, software delivery process and performance management. When the use of Scrum spreads at the organizational level, it helps in challenging organizational inertia and making the organization more agile.

Those devilish actuals

By Henri Stegehuis

About a year ago, I had been struggling with an important "don’t" of Agile Scrum, actual hours. In the first phase of Sprint planning we take all of our actual hours based activities and transform them to ideal hours. The focus factor or productivity factor transforms the hours for these activities to the desired ideal hours. After this initial process actual hours are expelled from current Sprint.

It may take up to a couple of Sprints to get the team really used to the ideal hours way of thinking. Once they understand and have experienced that removing slack from the estimated hours is compensated by using the productivity factor and that the team has control over this productivity factor, this Agile Scrum concept is in place. During the first few weeks as a ScrumMaster you will find yourself pleased with how planning and estimating are addressed in Scrum.

Then reality is catching on

My company’s biggest assets are we, the employees. We offer software solutions; we offer knowledge and broad experience. It all comes down to selling hours and accounting for them. With fixed price projects this problem is easy to overcome by assigning invoice schemes to Sprint deliveries. However, with non-fixed price projects, the accounting is mostly hourly based.

Potentially, the accounting problem with our contractors could be solved by defining certain effort milestones. There is a third party that is really a tough nut to crack, and we need them instead of them needing us, the government. A lot of innovative projects are subject to subsidies. Every claim for a subsidy has to be accounted for based on actually spent hours. The Burndown chart gives no information, as it is intended to, about actual hours spent on a task. For Agile Scrum the past is not interesting but the future is, can we make it in time? Accountancy for contractors or subsidies though lies in the past.

How to integrate

This has kept me busy for a while. I need actual hours, but I don’t want to track them; it is just for accounting. Also, the team must never get the feeling of being micromanaged. Equally important, upper management may not see these hours; I just spent weeks getting them familiarized with ideal hours and the Burndown chart. I don’t want to give them a reason to return to using old methodologies.

The first approach we tried was having the team write down the actual hours once a week on a separate list. This was not working for two reasons. One, the relation with the real tasks became loosely coupled. If I ever had to explain myself on an audit I wouldn’t be able to do so. Two, there were two lists and the team members became irritated. They demanded a solution on the Scrum Board.

Because we would like to maintain a one-to-one relation between Scrum Tasks and actual tasks, we decided to use the Tasks cards. We used the back of the sticky notes to write down actuals information. At the end of the Sprint, I would take down the Scrum Board, and fill the role of Project Manager by administrating the actuals. The consistency was in place and the administrative actions for recording were relatively easy and outside scope of the team and upper management. The recording at the end of a Sprint, when the result was already in place, was so late that the actuals gave no up-to-date, controllable information.

Unfortunately this solution was not working for the team at all, again for two reasons. One, mixing ideal and actual hours in during the Daily Scrum was making people schizophrenic. Two, the other reason might seem over-sensitive, but turning over the sticky-notes was an annoyance, especially while we already had to tape down the sticky notes because they do not seem to really stick (we would always find a couple of them on the floor the next day).

The last approach though had given us valuable input. While we had to tape down the task cards any way, we didn’t have to use the sticky notes. We have decided to make task cards with a default layout. We still use different colors for non-default tasks. Three-fourths of the new task cards is reserved for the Sprint data and one-fourth with a background pattern is reserved for actual recording. In the morning Daily Scrum, we discuss ideal hours, and before we go home, we write down actual hours for that day.

Conclusion

In recent Agile Scrum projects the layout of the Task cards has changed mostly because of the team’s personal tastes. The concept has not changed and the team agrees with the current solution. We know actuals and ideals are conflicting, and it is not Agile Scrum. Now, we separate them by having a different background on the Task cards, and speaking ideal hours the entire day and accounting for actual hours at the end of the day.. We feel that we have found the best solution to secure our sources of income and still follow the Agile Scrum methodology.

Scrum and the Recession: Why Scrum Is the Best Choice for Projects in Times of Crisis

By Rafael Sabbagh

The world faces one of the worst financial crises in history. Several European countries, the United States, and Japan are already in a state of recession. The International Monetary Fund (IMF) recently stated that the recession will continue to deepen and the recovery will be slower than in the past. As a consequence, emerging and developing economies such as India and Brazil will suffer massive net capital outflows. IMF also said in a forecast that the world economy will shrink 1.3 percent in 2009.

Forrester and Gartner predicted technology investments will suffer a drop of 3% or 4% in 2009, respectively. Particularly, spending on IT services will fall this year. Companies like Toshiba and Nokia recently reported losses or drastic profit drops, and plan to fire thousands of workers. Intel saw their stocks plunge. Even the internet giant Google, which seemed untouchable, reported its first-ever drop in quarterly profit and cut hundreds of jobs.

The New Scenario for Projects

In this environment of uncertainty and constant changes, project market players are facing resource rationalization, limited access to credit, margin pressure, and financial problems with most clients. The decision process becomes longer and the demand for projects is notably shrinking. This new configuration demands that organizations change the way they work in order to survive. A true paradigm shift is necessary. Surviving IT organizations will exhibit the following characteristics:

• Work well in rapidly changing environments, allowing frequent replanning;
• Focus on maximizing the client's return on investment (ROI);
• Help reduce time-to-production or time-to-market;
• Avoid wasted effort and time with subproducts and features that will never be used;
• Always deliver value to the client, even if the project needs to be halted before its end;
• Increase the communication and feedback between the project's stakeholders, so people will know what needs to be done and what's being done.

Scrum is a framework for project development that focuses on all those issues. Scrum is the best choice for projects in times of crisis.

Why Scrum?

Let's look at the players in the project market within a financial crisis context:

1. An organization or group that provides service on projects. It must increase competitiveness in order not to lose clients, both internal and external;
2. A director or manager needs to cut operational costs so that his organization may survive. He chooses to use internal projects focused on getting better results;
3. A client needs to outsource specific projects but needs to cut costs in order to keep them viable.

We will provide important arguments to help these parties (as well as other decision makers and those who can influence them) defend the choice of Scrum for their organizations in turbulent times.

No Waste!

Traditional methodologies spend a meaningful part of the cost and time of the project generating and maintaining massive documents. However, once complete, these artifacts are rarely updated as much as necessary, because changes occur faster than the team is able to keep them current. In the end, a great part of that documentation becomes useless and ends up being dismissed.

In The Enterprise and Scrum, Schwaber states that about 50% of a typical project's time (and money) is spent on requirements, architecture and specifications, and all that is done before building any functionality. However, 35% of the requirements change and 65% of the functionalities described by the requirements are never or rarely used. In times of crisis, such waste of time and effort is not acceptable.

Scrum reminds us that the objective of a project is the product - not the documentation. On Scrum, desired features are captured in a prioritized list called the Product Backlog. The exact specifications and design for each feature on this dynamic list is determined only a few weeks before it will actually be worked on. Features can be added, removed, or reprioritized throughout the course of a project. They are always kept in priority order. A new set of functionality is delivered at the end of each timeboxed iteration, or sprint. Therefore, whatever is delivered has a much better chance of actually being used by the client.

Better Value First!

On a typical waterfall project, the client may wait up to a year before he ever sees a finished product and begins to receive any return for his investment. In today's economic environment, companies can't always wait that long.

Scrum, on the other hand, delivers a return on investment at the end of each sprint. One of the Product Owner’s main roles is to maximize ROI by constantly updating and prioritizing the Product Backlog. This allows the items of most value for the client to be implemented first. Prioritizing the Product Backlog based on value allows the organization to stay competitive by delivering results to its clients faster than the other players, by putting in production functionalities that add better value to their businesses more quickly, or by launching products and new versions more frequently, so that they keep up with the inevitable market changes.

May Changes Come!

Speaking of inevitable market changes, at no time are there more sweeping and frequent market transformations than in times of crisis. Legislation and regulations are created, business rules change, new opportunities appear, important players leave the market, previously available budgets become scarce, companies face big losses, mergers and acquisitions increase, governments intervene to maintain stability.
For traditional methodologies, where change is undesirable, risky and expensive, this kind of upheaval is almost impossible to manage. It creates stress on the project team as well as stress on the relationship with the client.

Scrum follows the Agile Manifesto assertion that responding to change is more important than following a plan. Scrum maintains that change is a natural part of the development process. It has mechanisms in place to make change a constant, rather than a stressor. The dynamic nature of the Product Backlog allows client’s new requests to immediately be introduced on the product by the following sprint. Such quick response to change becomes a great competitive advantage, making it possible to turn a crisis into an opportunity.

Parcels or Partners?

On a typical waterfall project, the client is encouraged to participate at two times during the project: at the beginning for requirements analysis and in the end for the acceptance tests. The client perceives the project as a big package stamped "Do Not Open Until..." , whose contents will be revealed solely at the end of the process. Their only glimpse into the future product is through documentation, most of which is out of date or out of touch with changing requirements. In today's fast-paced, ever-changing market, it's unlikely that what the client asked for in the beginning will fulfill his needs in the end.

On a project that adopts Scrum, the Product Owner is always in touch with client to identify his needs and keep the Product Backlog constantly updated and prioritized. The client frequently gets new versions and can give feedback more quickly to the team through the Product Owner. The client feels involved with the whole process, sharing the responsibility over the project with the team, increasingly trusting the team and the process itself. The relationship with the client ceases being merely commercial and instead becomes a partnership, fostering complicity, satisfaction and fidelity. A long-term relationship is then developed with the client, which can often overcome strong periods of crisis.

Communication doesn't just happen between the product owner and the client. Everyone involved with the project is given a daily glimpse into what the team is doing. Daily meetings allow members of the team to show other members what they’ve done since the previous meeting and what they will do until the following one. The sprint backlog or kanban shows everybody all the activities yet to happen, those already happening, and those which are finished. Working in a collocated environment stimulates teams to communicate. Burndown charts show everyone the project’s progress. Frequent demos show the Product Owner what’s been produced and give opportunities for feedback.  Finally, retrospective meetings allow everyone to see what has worked on the sprint and what can be improved.

Keeping communication open between the project’s stakeholders is the best way to assure that everyone knows what needs to be done and what’s being done. That increases productivity, which is essential to surviving a crisis.

What if the Project Gets Suspended?

In times of crises, it is common for the budget to dry up or the supplier to leave the market during the project. When this happens on a non-agile project, what will the customer be able to deliver to the client?
If the project gets suspended right after the initial phase of specification, the client gets a series of documents that won’t be of any use to him. In case it happens in the middle of implementation, he will get incomplete and untested functionalities. Even if it happens in the middle of the tests phase, the product hardly will be trustworthy. In fact, chances are the client won’t be getting any return whatsoever on the investments made if the project is stopped prematurely.

A project with Scrum always produces an increment on the product which is potentially deliverable at the end of every sprint. If the project gets suspended at any moment, the client may utilize what has been generated on previous sprints, minimizing his risks. On an environment of uncertainties, that becomes an important competitive advantage.

What if You Have to Cut Down the Team?

In periods of crisis, it may be necessary to dismiss or relocate members of the team. With waterfall, roles inside the projects are very well defined. On an IT project, for instance, the programmer programs, the tester tests and so on. So, if the designer leaves the project, new windows will have no graphic design; if the tester leaves the project, it will go untested; and, worse of all, if the project manager leaves it, it will go ungoverned. Therefore, the whole project’s success is threatened by the loss of a team member.
With Scrum, responsibility over delivery belongs to the whole team, no matter the roles. Although there is a natural specialization, people are stimulated to develop and utilize their secondary abilities and, in general, will do their best to compensate for the lack of team members. This way, even with less capacity, the team can keep delivering.

It’s important to point out that firing members of the team must never be the first alternative for cutting costs. Shrinking the team also diminishes its capacity to deliver value. Consequently, the client will be less pleased and will search for suppliers that can provide him better service. That makes the organization’s situation worse, creating a vicious lose-lose cycle.

Conclusions

Scrum is the best choice for projects in times of crisis. It surpasses other methodologies for working well on an environment with constant changes, for frequently delivering better value to the client, by focusing on maximizing return on investment, by avoiding waste and prioritizing communication and visibility to what is important for the good developing of the project, and by creating a cross-functional team.

Once the crisis is over, organizations that adopted Scrum will be closer to their clients, focused on results, more compact, objective and transparent. To these organizations, the crisis will have worked like a propelling spring, so that when market recovery comes, these organizations will be ahead.

The Sprint Review: Mastering the Art of Feedback

By Bob Schatz

The sprint review in Scrum is a critical part of the inspect and adapt cycle. Having worked with many teams and organizations, I have noticed an overall reluctance (and in some cases fear) to do them in the way they were intended.

First, let’s understand what the purpose of the sprint review is.  As my friend and mentor Ken Schwaber writes in his first two books, the sprint review is “a 4-hour informational meeting for the team to present to management, customers, users, and the Product Owner the product increment that is has built during the Sprint.”

Focus on the End User

Some companies are reluctant to involve their end users for fear of “scope creep,” others feel they aren’t allowed to ask the end users to be involved, and certain others don’t even know who the end user is! Whatever your reason for not involving them, find a way to do it.

That’s what we did at Primavera when we adopted Scrum back in 2003. We started off demonstrating mostly to our product managers, but we knew something was missing. So we kept thinking about how to increase the value of feedback we were getting, then the obvious solution emerged—we should involve our actual customers! Customer collaboration, remember? So, we started by inviting some of the customers we had always worked closely with and began to expand it little by little.

We had our own challenges to deal with in involving end users. For one thing, we had about 15 Scrum teams all working on the same release of our software. To help keep end users focused, we started using themes for each sprint. Each team had some piece of work that related to the Sprint theme. Having a theme helped end users tailor their feedback towards the theme for the sprint.

Our sprint reviews could best be described as being like science fairs at school. Each team set up a station where they demonstrated what they worked on. The end users, stakeholders, and a few others from our company formed small teams. Each reviewer team started at a different station. We ran 15-minute iterations moving reviewer teams from station to station.  It was an environment of high-energy, excitement, and fun.

Involve the Product Owner

You’ll notice that the product owner was not part of our reviewer teams. Instead, the Product Owner was actually responsible for presenting the project. This deviation from the original book definition of a sprint review greatly improved the dynamics of our sprint review.

Too many companies and projects set up their sprint review so that the team is presenting to the Product Owner, as if he should grade them or judge them on their work.  This is nonsense! The Sprint Review is not an inquisition or a court of law; it is a way to get feedback from the customer. Instead of presenting to “Judge Product Owner,” teams should instead work with the Product Owner during the sprint to review each story as it’s completed.

Then, when it’s time for the sprint review, the Product Owner should be the first person to stand up, welcome people, and give an overview of the state of the project. The Product Owner should discuss what the overall goals were for the Sprint, what was achieved/not achieved, the quality level of the product, and the release/product burndown.  He should then let the reviewers know what they should be looking for and how to provide the feedback.  After setting the stage, the  Product Owner turns the “show” over to the Scrum teams for the demonstration of functionality.

Understand Group Dynamics

Changing the sprint review audience from a lone product owner to a team or teams of stakeholders and end users dramatically alters the group dynamics. Let’s look at how these roles change once the product owner is part of the presenting team.

Product Owner: The Product Owner is put in a position where he now is acting as a true owner of the product. He has the responsibility and accountability, as part of the overall team, to present the results of their decision-making to the end users and stakeholders. He stands up and presents the product increment and gives insight into the state of the project. Knowing he must do this at the sprint review enforces the discipline to maintain a product/release burndown and know the quality level of the product. Another byproduct of this approach is that any discrepancies between the Product Owner’s representation of the end users’ needs and the actual needs of the end users will surface immediately.

Scrum Team: The Scrum team is now in a better position to present what they’ve done in the sprint with a sense of pride. They get time with the end user, in the best cases face-to-face time. The best way to develop good software that provides the most value to the end user is to know the end user. The team learns how to take feedback, and with every sprint they get a better appreciation for the people they are developing the system for.  Another ancillary benefit is that presenting to the end user takes away the feeling of being graded or judged by the Product Owner. Instead, the team leaves the review motivated and energized for the next sprint.

Company Executives/Stakeholders: When executives and stakeholders are invited to the review, they not only get a great view of the real status of the project, they also get to see their teams in action. Additionally, they get time with the end users to hear directly about their needs. Perhaps most importantly, they learn how to behave themselves. It’s amazing how different the dynamics are when customers are around. Instead of the criticizing and bickering that usually goes on, everyone is on their best behavior, so the review becomes much more productive and motivating.

End Users/Customers/Partners: The end users are the stars of the sprint review. They get valuable face time with the people that are developing the software. They come to feel like they are part of the development team. They are engaged. Because they have been so involved in the product’s development, once it is released and put into production, they are usually the product’s biggest supporters inside their own companies. Having knowledgeable advocates for the product at the customer site can also help reduce the usual flood of support calls that are typical immediately after release.

ScrumMaster: The ScrumMaster’s sole role in a sprint review is to facilitate. She makes sure the environment is set up for all of this great stuff to happen—that the right people, supplies, and facilities are there. And she makes sure the pizza is ordered. This may seem like a small detail, but don’t forget to feed people. Food is a great collaboration tool. We had some great conversations in the times where we shared some food.

Remember, this is not a ScrumMaster show. During the review, the ScrumMaster should support the teams, make sure the end users are welcomed and made to feel like part of the team, ensure that they get a chance to be heard, and stay behind the scenes.

Be Courageous

If you want to master the art of feedback, the first step is to create an environment that allows it to happen. It can be scary to involve the end users in the process but remember: it’s better to hear the feedback early and have time to make adjustments than to go down a long path only to find out it was the wrong one. Still afraid of scope creep? Let it go. First, the Product Owner will make the decisions on what trade-offs will be made after each sprint review; and second, you may find out more about what the end users don’t need, which will stop overproduction of features that may never be used.

Focus on the end user, create energy and excitement, and make your sprint reviews an event that your customers want to be there for. All you have to do is create a review that has direct value for them. Then just sit back and listen. You may be surprised by what you learn.

A Cure for Task Estimation Obsession

By Alan Atlas

I often see teams obsess over sprint planning, especially the task estimates. I mean really obsess. Two days of planning for a two-week sprint? Believe it or not, it happens. Even as they complain about spending too much time in scrum meetings, they will insist on arm-wrestling over each and every task estimate. For teams that want to take advantage of their scrum experience and streamline their planning, eliminating task estimates can be an option.

Don’t look so shocked. It is possible. One big caveat, though. For those teams that are new to Scrum, I do not recommend eliminating task estimates until you have established a stable velocity.

Once you have a stable velocity, however, you can use the concepts of story points and velocity to eliminate the need for task estimates in sprint planning. The time you used to spend estimating tasks can then be used more wisely to create working software. I will present a series of steps you can take to gradually eliminate task estimation from your sprint planning process.

Background

Before we get started, let’s quickly recall the reasons why we do the sprint planning things that we do. (We’ll want to make sure we can still meet those needs when we’re done streamlining the process.) We plan the sprint in order to create the following:

1. A shared understanding across the team of the goals of the sprint;
2. A shared understanding of the work that needs to be done during the sprint;
3. An environment in which team members know what to do next (or can find out in seconds);
4. An achievable team commitment to deliver a certain amount of value, expressed as product backlog items; and,
5. A burndown chart that we can use to track our progress through the sprint.

Task estimates most often contribute to goal five above, and for some teams, to goal four. If we can achieve those two items without creating task estimates, then we are free to choose not to use task estimates at all, aren’t we? If you agree, here’s a way to transition away from doing task estimates as part of your sprint planning.

Step 1. Establish Stable Velocity

Use your normal sprint planning process, whether it takes two days or two hours, for each sprint until you can demonstrate stable velocity. (There are many discussions of how to achieve stable velocity out there; it is too large a subject to treat here. For more on agile estimation, I recommend Mike Cohn’s Agile Estimating and Planning.) Make sure your team passes the Nokia test by producing potentially shippable software each sprint (in other words, you’ve proven that you can calculate your velocity correctly). When you have achieved stable velocity, your team will be able to make, and meet, sprint commitments based solely on demonstrated velocity and story point estimates of Product Backlog items. You want to do this anyway as part of having a good scrum implementation, right?

Step 2: Experiment with a Task-Based Burndown

When you think you’re ready to stop estimating tasks, start to use two burndown charts instead of one. Continue to use your normal work-based burndown, which is based on the task estimates from the sprint backlog. Add to it a new burndown chart, which will be based only on the number of tasks in the sprint backlog, regardless of their estimates. The new burndown chart can be called a task-based burndown chart.

Your familiar work-based burndown chart starts with the total of all task estimates for the sprint and, as estimates are updated daily, the burndown continues to reflect the estimated amount of work left in the sprint.  Hopefully it will usually trend down toward zero. Your new, task-based, burndown chart starts instead with the total number of tasks listed for the sprint. Estimates aren’t updated for this chart, and work is burned down when a task is completed (its value on the burndown goes from 1 to 0).  For best results, make sure your task breakdown results in the smallest tasks possible. The task-based burndown chart reflects the estimated total number of tasks left to do in the sprint and not the estimated work effort left. This works best if you have lots of small tasks, typically ones that can be done in a day or less.

Make sure that both burndowns agree and that both give you the same visibility into your progress during the sprint. If you find that the task-based burndown isn’t useful, take a look at Step 3.

Step 3: Shrink Tasks to Improve the Task-Based Burndown

A good, informative task-based burndown chart depends on there being many small tasks to burn down. Conceptually, if you only had one task per PBI on a sprint backlog, you could have a perfectly good work-based burndown chart because the daily updates of the task estimates are given with arbitrary granularity (Now, if your PBIs really have only one task each, it’s indicative that there is a problem with either your stories or your task decomposition). In contrast, the task-based burndown chart for this sprint would be very insensitive on a daily basis, because the tasks would tend to span many days, and progress would not show until a task was completed. The remedy is to make tasks small. A good rule of thumb is that a task should be something that can be completed in a day or less.

Step 4: Stop Doing Task Estimates

When your two burndown charts convey similar information and when you can deliver on velocity-based sprint commitments, you can stop doing task estimates and do away with the work-based burndown. For some teams this will be easy to achieve and for others it could take many sprints. The key to this is to use the idea of velocity correctly. Note that you will still want to be doing the task breakdowns for now. Eliminating them is a different step altogether.

What did we lose when we did away with the task estimates? Task estimates support planning needs four and five from the list above. We still have a burndown chart that we can use to track progress, so we still support goal five.  We have removed the need to support goal four because our team has demonstrated the ability to make commitments based on story point estimates of PBIs and does not need task estimates for validation.

The only thing we might have lost is tangential support for planning need number two. That is, by not asking for estimates, we may have removed some of the mental pressure and motivation to think deeply, look for issues, recall similar efforts, and in general actively bring knowledge and experience to bear on the problem of correctly planning out the tasks. How big a deal is that? The answer to that question is unique to you and your team.

Ready, Fire, Aim: A Rebuttal

By Tom Steele

One popular criticism of the early agile software development movement is often summed up by the phrase Ready, Fire, Aim. The phrase’s intent is to depict agile approaches like Scrum and XP as foolish—something so obviously inconsistent with conventional wisdom that it could not possibly work. At its core, it suggests that lengthy planning (aiming) must come before getting started (firing). Anything else could never work and should be avoided.

Those of us who have successfully adopted Scrum know that rapid and continuous planning throughout the life of a project is much better than any lengthy upfront planning effort. Scrum, through its release and iteration burndown charts, provides the necessary information to properly steer projects toward successful outcomes.

Nonetheless, you may still encounter this anti-agile sentiment from people or organizations reluctant to try Scrum. I would like to share two illustrations that show why Ready, Fire, Aim can sometimes be a good thing.

Ready, Fire, Aim Really Works

Ready, Fire, Aim is a play on Ready, Aim, Fire, a phrase commonly used in conjunction with firearms. Since firearms are used extensively by the military, the first counter story I want to share comes from the US military.

General Norman Schwarzkopf commanded US forces in the Persian Gulf during Operation Desert Shield and Operation Desert Storm. He is credited with taking advantage of technology advancements in weaponry to aide his success during the Gulf War. One such advancement involved putting soldiers on top of buildings in Iraq. These soldiers would remain hidden during daylight hours. At night missiles would be fired from several miles away. After the missiles had been fired, the soldiers on the rooftops would use lasers to guide (aim) them to their targets—truly a Ready, Fire, Aim operation.

A Scrum team is similar to the soldiers on the buildings, constantly guiding their projects to the desired targets.

Confucius Says

My second story illustration is a simple passage from a fortune cookie: You can’t aim a duck to death.

The Scrum/agile interpretation of this phrase is that you will never complete any project (kill the duck) if you never actually get started (aim endlessly). Numerous projects fail before getting started; too much time and money is expended at the onset. This can be especially true in large enterprises where there is a tendency to spend far too long defining and planning projects and never getting them started. The passage also nicely complements the Scrum mantra The art of the possible.

That doesn’t mean that we shouldn’t aim at all. After all, it is also said that a well-aimed spear is worth three. Even (and especially) in an agile setting, everything must be kept in balance. It’s entirely possible for a project to start prematurely and fail as a result. Discussing this possibility with those who are predisposed to mistrust agile demonstrates an appreciation for the motivations of plan-driven project managers. Maintaining the crucial balance between aiming and firing is why we ultimately tailor agile approaches to individual circumstances—why we strive to be as agile as possible.

Conclusion

The next time you are in a situation where you sense uneasiness towards agile or Scrum, consider using these stories as arguments for an agile approach. Introduce Ready, Fire, Aim as a common argument against agile, then share these stories to help illustrate your understanding of their concerns. Though simple and anecdotal, they may cause a skeptic to reconsider any bias against agile software development approaches like Scrum.

Scrum Games: Participatory Activities that Illustrate Scrum Principles and Practices

By Michael de la Maza

Three years ago I learned how to fly a plane. Before I got into the cockpit, I read books and magazines and watched videos on flying. I spoke to pilots about their experiences. I attended aero club meetings. But nothing prepared me for the vertigo and nausea I felt on my first flight or the terror I experienced when night flying.

Like flying, Scrum cannot be learned solely from a book or from a presentation. It must be experienced. Great Scrum trainers and coaches lead their teams through a wide mix of activities that illustrate Scrum practices and principles to give their teams the opportunity to learn by doing.

One of the key Scrum principles is teamwork: the team cannot be a collection of individuals each pursuing their own interests. This concept is, unfortunately, foreign to many work environments. In contrast, a Scrum team coordinates its activities during various meetings, including the daily scrum and the planning meeting, and through the use of many artifacts, such as the burndown chart.

The ESP (extrasensory perception) game is a very simple game that I have found to be very effective in highlighting the importance of teamwork and in sparking discussions about its value.

ESP Game

The ESP game should be played after the team has gone through a Scrum planning exercise and is familiar with sprints. I have found that at this stage there are many doubts about the necessity and benefits of the various Scrum meetings.  I often find that the team wants to skip or modify a meeting.  The ESP game illustrates the key point that if the team does not explicitly invest in teamwork and communication, it will suffer. The game can also be played during the retrospective meeting by teams that have already implemented Scrum to spur discussion about teamwork and communication.

The ESP game is played as follows:

1. The participants are divided into pairs. If the group has an odd number of people then the trainer or coach should play.
2. Each person is given a set of five to fifteen cards. All sets of cards should be the same. These cards can be standard playing cards, planning poker cards, or index cards created for this game.
3. Each person in each pair selects one card and slides it into the middle. Once both cards are in the middle they are turned over. The players can only show one card at a time.
4. If the two cards match then each player gets a point.
5. The game continues until all cards are exhausted.
6. When all cards match, the game is over. If any cards did not match, then the game is repeated.

During the game, the players are not allowed to communicate verbally or non-verbally. They can only communicate through the cards. The players are not allowed to write on the cards or mark them.

Once all pairs of players have finished (i.e. their cards match for the entire deck), then the pairs can be grouped together to form sets of four people and the ESP game can be repeated. The players receive a point only if all four cards match. Smaller groups can continue to be grouped until all of the players are in one large group.

Note that while there may be many logical ways to sort the cards (in numerical order, in alphabetical order, etc.), the greatest challenge is in agreeing on the order without any sort of meta discussion. If, in the first round, one player sorts the cards in high to low order and the other player sorts them in low to high order, neither player will know whether to repeat the original order or to switch orders in the second round. Typically, one player will eventually follow the order selected by the other player. When the pairs are then grouped together the leader/follower behavior must change because each pair has a leader and, unless the order happens to match, one of them must follow.

Discussion

When the activity is completed, invite the participants to engage in a discussion. Here are some questions that often spark conversation:

1. What did you learn?
2. How much simpler would the ESP game be if you could speak with the other player?
3. In your current work environment do you ever feel that you are playing the ESP game? If so, why?
   - What Scrum meetings and artifacts ensure that you will not fall into the trap of coordinating your work effort by playing the ESP game?
   - What might happen if you eliminate these Scrum meetings and artifacts?
4. In your current environment...
   - How do people coordinate their work?
   - Is coordination a first-class object?
   - How often do coordination problems occur?
   - Is teamwork highly valued?
   - Is the team in sync?
   - How are promises and expectations managed?
   - How does the team respond to coordination failures?
5. How can your team improve its teamwork?

Scrum games such as the ESP game serve to illustrate the value of Scrum principles and practices. I encourage you to use them when introducing a traditional team to Scrum. Even high performance Scrum teams enjoy playing these games during the sprint retrospective!

Scrum Role Playing

By Geoff Watts

Scrum is very explicit in its clarification of roles and responsibilities. Scrum has only three roles; together they cover the responsibilities needed to ensure a successful project. The Product Owner represents the customer and sets the vision, goals and priorities of the project. The PO then works collaboratively with the team to determine the details during each sprint, accepting work as it is completed. The team members are responsible for determining what can be done within a sprint, making a commitment for a sprint’s worth of work and then organizing themselves to deliver the functionality needed. The ScrumMaster guards the team and its process, keeping an eye out for Scrum smells and removing impediments to productivity.

Almost anyone who has been on a Scrum project has noticed the issues that can arise when one Scrum team member wears two hats (for instance, when one person plays both the role of ScrumMaster and the role of developer or when one person plays Product Owner and developer). Doubling up injects a certain amount of implied hierarchy into a self-organizing team and increases project risk by significantly escalating the difficulty of planning and removing some of the checks and balances inherent in a Scrum team. While neither of these dual-hatted roles is impossible to incorporate in a Scrum team, by the same token, neither is ideal.

Another less-than-ideal scenario is having one person play the roles of ScrumMaster and Product Owner. In that case, the same person is responsible for guarding the team and its process as is responsible for the direction and profitability of the product. While this has even more explicit potential for a conflict of interests, the outcome depends on which of those hats is the more dominant. For example, when a ScrumMaster assumes the role of Product Owner, the lack of someone pushing business priorities can result in technology-focused indulgences or a team pace that is too comfortable. In contrast, a Product Owner who assumes the role of ScrumMaster can go too far the other way seeing this as an opportunity to take direct control of their very own development team, foregoing the technological needs of the project and pushing for a very aggressive, and possibly unsustainable, pace. In both cases, being both product owner and ScrumMaster is likely to be a big draw on one person’s time, leading to possible sacrifices in either their stewardship of the team or up-to-date information on the product.

While none of the problems in the above scenarios is insurmountable, arguably the most anxiety-inducing and uncommon dual-role is the combination of ScrumMaster and Product Owner.  Ben Johnson of Man Investments knows about filling this inherently oppositional dual role first hand. He had some very interesting experiences from his time filling both roles on a Scrum project. In his case, the dual role was never intended to be a permanent one, but it did provide him and the team with insights into their responsibilities and processes they might not otherwise have attained.

Working within the Product Management department of Man Investments, the world’s largest hedge fund, Ben’s group’s primary function is to ensure that clients get the correct level of exposure to the underlying investments that their funds promise. In order to do this, Ben’s group undertakes weekly or monthly rebalancing of client funds. Though this rebalancing process involves several systems distributed among Man Investment’s global divisions, one key database system is used to determine the actual transactions required to gain this promised level of exposure. These transactions total billions of dollars each month.
Not only is Ben part of the team responsible for the day-to-day running of this system, he also assumes the role of Product Owner with respect to its ongoing development. As Product Owner, he spends a significant portion of this time collocated with a Scrum team that consists of four full-time developers and two part-time analysts/testers.  The team used to develop using a waterfall approach, which did not fit well with their fast-changing business requirements.  Now, Scrum allows them to wait to capture the more intricate business requirements until the point that development actually starts, making the entire development process less wasteful. A combination of sprint planning sessions and burndown charts has made their work much more visible to the business. This visibility, coupled with the increased throughput of work, has forged bonds with various business stakeholders and has changed the business perception of the development team from “can’t do” to “can do.”

To enhance awareness of the scrum process, the team’s development manager suggested that each team member should take a turn as ScrumMaster, so the team members rotated the ScrumMaster role around the Scrum team. Ben had not been in the Product Owner role for long, and thought taking a turn as ScrumMaster would be a good opportunity to get more involved with the development team, so he included himself in the rotation. If nothing else, he thought, it would force him to be involved at every daily Scrum meeting!

The developers were happy for Ben to take on the role (perhaps because none were too keen on being ScrumMaster themselves!) and Ben feels they made sure he had plenty to do throughout the sprint, as they raised plenty of impediments. At the same time, the developers did express some concerns about the idea of a Product Owner also playing the role of ScrumMaster. They spoke of their worry that the team could be left exposed without anyone neutral guarding the process and that this could lead to the ethos of Scrum dissolving. Ben talked with them about ways to mitigate that likelihood as well as possible warning signs to look out for. They also decided that they would review how it went at the end of the Sprint so that, as a group, they were comfortable with the experiment.

Initially, Ben’s main concern was how to manage the planning meeting. How could he get the best value for the business without pushing the team too much? Would he be able to allow the stakeholders to decide upon the priorities without unwittingly influencing their decisions?  In fact, the planning session went better than he expected. As Product Owner, Ben introduced the high value user stories as he normally would, while, as ScrumMaster, he facilitated the meeting itself. Ben invited a second attendee to the planning session who could represent the business in another Product-Owner-type role to ensure there was a business interest looking at the overall picture in the event that his role as ScrumMaster prevented him from seeing something. In addition, the business was well represented by all of the stakeholders, so it wasn’t necessary for Ben to represent those stakeholders himself, allowing him to function more as a ScrumMaster.
What Ben hadn’t envisioned was the amount of re-planning necessary during the sprint. As Product Owner (and with the stakeholder’s trust), Ben is typically able to make decisions on what to add/remove from the sprint but, since this time he was acting as ScrumMaster as well, Ben didn’t feel comfortable making these decisions himself. As a result, the team had more than one formal re-planning session, which increased the burden on the many business stakeholders.
Time was an area generally that Ben struggled with in his dual role. Being Product Owner is not 100 percent of his remit and, as such, there is a certain amount of juggling he must do, even in a “normal sprint.” With the additional admin work (such as updating the burndown chart and chasing up impediments) that the ScrumMaster role required, this juggling became more difficult, and had a detrimental effect on Ben’s day job. For example, he fell behind in responding to queries and, as such, became somewhat of a bottleneck in another process.

This particular sprint threw up an unusually large number of impediments, many of which revolved around the setup of new PCs, and these were not dealt with as efficiently as Ben felt they could have been. This was partly because Ben was stretched too thin and partly because he didn’t have the same level of contacts in the technology department as the development team did (as these impediments were mainly IT-related).

There were times during the sprint when the team was able to take on extra user stories. With a series of future sprints vaguely planned, Ben would have normally made the call himself as to which stories to add. However, he was conscious of the temptation to cherry-pick his personal favorites and, as such, called more than one formal re-planning session with the business stakeholders. While this ensured the correct result, it was at the expense of considerable business time.

From this experience, Ben learned that formal re-planning sessions should not be organized unless absolutely essential. If you have planned for future sprints, the Product Owner can usually identify the best user stories to bring into the current sprint. At the same time, Ben also became very aware of the importance of having a release plan covering future sprints, both to give the an indication of the future direction and also to give the Product Owner something concrete to work with when an opportunities arises for the team to bring more user stories into a Sprint.

Ben believes his experience as a ScrumMaster gave him a better feel for what is required of a ScrumMaster and how time consuming that role can be. For anyone playing both roles in a Scrum team, Ben recommends that they build out a release plan of future Sprints and time box rigorously. Having people around that can act as both technological and business consciences can be very useful, too, in order to avoid becoming one-sided.

Being successful in this dual role does require a Product Owner who is mindful of the Scrum process at all times. One of the developers, commenting on the success of the dual role, said, “I think it depends on the Product Owner. If they were hard-nosed and didn't care about process, then it would have been a very different matter.”

While it is definitely a less-than-ideal situation, playing both roles is possible and even has some advantages. It was certainly a learning experience for both Ben and the team. Although there is still a doubt as to whether the inevitable conflict of interests could continue to be avoided long term, all were glad that Ben took his turn in the rotation. In the end, both the team members and Ben felt that he gained an appreciation of their frustrations and challenges that he otherwise may have been blind to in the sole role of Product Owner.