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

By Edward Scotcher

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

Scrum Master's Responsibilities

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

Continue reading this article.

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

By Roman Pichler

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

Continue reading this article.

Heartbeats: The pace of a Scrum Team

By Rafael Nascimento

One of the challenges in the use of Scrum is to predict how much of functionality a team is able to deliver each sprint. Many try, in a vague attempt to create a metric, to assign a story point a certain amount of work to be delivered, rather than looking how a team play their roles and perform their deliveries. For example, a story point is equivalent to a CRUD with 8 fields that accesses a table in the database. This approach does not work, because a team is made up of people with different experiences, perceptions and problems (personal or professional). Individually and collectively, a team always has different emotional and technical characteristics  from other teams. Team members never take the same time that members of Team B took to adapt to each other. Teams will never manage exactly the same conflict situations or have the same productivity. Finally, in sets filled by human beings, there may even be a statistical  standard for productivity, but never an industry standard, accurate and predictable. There will always be a margin of error. Then comes a question for reflection: is it better to draft a plan and make your team follow this plan at any cost, in favor of a contract or corporate goal? Or would it be better to identify a target and track the performance and growth of your team, guiding it toward its mission, enjoying a harmonious, happy and highly productive environment, and make necessary adjustments to the project plan for the sake of your customers’ satisfaction, offering them transparency, with no surprises?

Continue reading this article.

Ouija Board Estimation

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

Continue reading this article.

An Example ScrumMaster's Checklist

By Michael James

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

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

A great ScrumMaster can handle one team at a time.

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

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

Continue reading this article.

Ouija Board Estimation: A fun technique for agile estimating

By Paul Goddard

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

Continue reading this article.

Getting Dirty with Scrum

By Pat Guariglia

I have been the Scrum Master for this one team for several years. The other day I arrived a few minutes early to the room we use for our daily Scrum and sat down to gather my thoughts before the meeting. I was in the room by myself when I noticed all of the scuffing and marks on the walls.  When we started using this room for our daily Scrum meetings, it was freshly painted and hardly used. Two years later, I am looking at the walls of a well-used room, a room that hosts our daily stand-up meetings… a room that gets dirty.

Seeing the dirt on the walls reminded me of how tactile the whole Scrum process really is. In Scrum, you cannot be afraid to get dirty. You work with your hands, body and mind. When Scrum is done well, the team becomes a well-oiled machine that takes on a personality of its own. The seasoned Scrum team reacts organically to change and knows how to process it.

Good Scrum involves taking yourself out of the virtual world and into the real world. Unlike other software methodologies (waterfall), Scrum is the framework that thrives on continuous hands-on experiences, plus tactile and verbal feedback. It works best when people are engaged and physically involved. Collocation, physical task boards, daily Scrum meetings, and customer collaboration all require the team to be there physically.

Continue reading this article.

Have an Initial Conversation to Start an Agile Project: A CSP and CSM share how teams at Baker Hughes choose the solution delivery methodology that best suits the project.

By Rahul Sawhney and Prashant Patel

The Baker Hughes Product Development Lifecycle starts with discovery and inception phases. The delivery teams start engaging with the customers during the inception stage. By the end of inception, business requirements are understood at a high level and stakeholders from different teams who will be involved in the project are identified. This is when discussions are held for selecting the appropriate solution delivery methodology.

The choice of methodology impacts how the different stakeholders engage with the project. We have seen that in order to improve the chances of success for any project, the solution delivery methodology and the level of commitment needed should be understood upfront by all stakeholders. To that end, it is important that there is representation from multiple stakeholders, including but not limited to business, development, testing, agile coach, project management and resource management.

The stakeholders should be aware of the agile methodology and scrum framework for having this conversation. It is beneficial if they understand the rigor agile brings with respect to solution delivery and how it is different from waterfall.

Continue reading this article.

Beware of the Meltdown: A CSP Shares Her Meltdown Stories and Tips for Avoiding Your Own

By Carrie Schonhoff

It happens when you least expect it. At some point when a Scrum team is just forming (despite training, agreeing on team rules, and doing some team building), most teams experience a meltdown. The good news is that once the meltdown has passed, these same teams really start to understand the Scrum framework. 

From Fear to Trust

This phenomenon is not unique to Scrum. I think it happens to all of us when faced with a change that we are not prepared for. I remember when my company changed its health insurance coverage and doubled the premium. I had a meltdown!  I started thinking, “How could this happen?” “I had no idea!” “Why do we have to pay that much?” Once I talked to a couple of people and commiserated with them, I began to accept the fact that I had no choice and this was the way it was going to be from now on. I moved on. After I got over the initial shock, the changes from Human Resources didn’t seem as harsh – I understood that changes to benefits were a given.

This is how it is with Scrum. We often react defensively as a kneejerk reaction to the changes Scrum brings. It challenges the way we’ve thought about not only projects, but how we have worked in the past as well. We're forced to confront the big picture we’ve been sheltered from, yet we find it hard to see it clearly. We aren't sure how to problem-solve. And now that no one is feeding us our tasks, we are supposed to think of what to do on our own. It can be overwhelming. 

Continue reading this article.

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

By Maria Matarelli

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

Demanding Circumstances

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

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

Continue reading this article.

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

By Henri Stegehuis

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

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

Continue reading this article.

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

By Marco Mulder

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

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

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

Set a Dynamic Standard

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

Continue reading this article.

Common Product Owner Traps

By Roman Pichler

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

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

The Product Owner in Scrum

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

Continue reading this article.

Ask the Coach

By Manoj Vadakkan

Recently I had an opportunity to speak with Alan Atlas, a Certified Scrum Trainer and Certified Scrum Coach who works for Rally Software. In this conversation Alan shares his insight on the state of Agile and Scrum. He also takes a stab at predicting what is to come in the future. This interview also includes some advice both for budding agile consultants and also for organizations that are trying to transform to an agile way of working.

Manoj: Agile has been here for a while; it is everywhere now – small and large organizations, distributed organizations, etc. What’s new in agile? Where is it going?
Alan: One thing I am glad of is that, in a certain sense, there is not a lot that is new. I think we understand it [agile]; I think it works and I really don’t want people messing with it a lot. Ken Schwaber is fond of saying that the whole thing that got us into trouble in the first place was our search for the perfect process. One reason that Scrum is so strong is that it is a process framework, not a process. It gives you all the important stuff and plenty of room to adapt.

It is true that agile does seem to be spreading everywhere. I saw a question in a trainer’s discussion group where someone was asking, "When is it going to be when the only option to do your project is agile? Then you don’t have to say you are doing agile or waterfall, you will just say we are doing a project." I think we will get to a state where that’s [agile] just the way to do things. Students will come out of school knowing agile, and they will know iterative and incremental makes sense; it will be just as logical to them as waterfall  was to us when we came out of school. When I came out of school, I thought, what possible other way there could be to do a project? It [waterfall] was so logical. You start by collecting things [requirements]; you go thru this orderly process; what could possibly go wrong? We discovered what it was – what could go wrong.

Continue reading this article

How to Sustain Adaptive Planning

By Rahul Sawhney

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

We will examine the following factors:

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

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

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

Possible response #1:

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

Possible response #2:

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

Possible response #3:

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

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

Making Adaptive planning work

- Just-enough planning

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

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

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

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

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

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

- Grooming the scope

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

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

- Trust, involvement and collaboration

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

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

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

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

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

- Management support

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

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

Conclusion

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

Can Scrum Support Six Sigma?

By Heitor Roriz Filho

INTRODUCTION

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

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

SIX SIGMA ASPECTS OVERVIEW

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

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

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

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

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

SIX SIGMA ROLES AND METHOD

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

THE SCRUM ROLES

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

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

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

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

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

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

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

BLENDING SCRUM INTO DMAIC

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

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

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

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

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

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

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

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

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

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

CRITICAL ASPECTS TO CONSIDER

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

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

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

REFERENCES

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

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

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

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

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

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

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

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

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

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

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

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

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

[14] COHN, M. User Stories Applied.

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

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

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

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

What does a ScrumMaster do?

By Dr. German Sakaryan

As a ScrumMaster, I was asked this question many times. Sometimes I had enough time to explain, sometimes not. But every time it was challenging to provide a clear picture of what a ScrumMaster really does.

To help myself and other ScrumMasters, I have started to write down general activities, which characterize the role of the ScrumMaster (see below).

The priority of activities varies by company.

1. Keeps Scrum process running
2. Ensures a proper power balance between PO, Team, Management
3. Protects the Team
4. Moderates in the Team
5. Helps to organize (e.g., Meetings)
6. Helps to keep the Team focused on the current Sprint
7. Helps to achieve Sprint goals
8. Works with PO
9. Educates PO, Team, Management and Organization
10. Solves impediments
11. Encourages and helps to achieve transparency
12. Strives to develop a Team into a High Performance Team
13. Encourages and protects self-organization
14. Educates and focuses a Team toward business-driven development
15. Supports Team building and Team development by utilizing the abilities and skills of individuals, and fostering a Feedback culture
16. Helps to self-help
17. Ensures and supports Empowerment of the Team
18. Addresses needs efficiently and effectively
19. Detects hidden problems and strives to solve them
20. Helps Team to learn from its experiences

Hints for management:

ScrumMaster is a very challenging job. If you are hiring someone for the position, consider which skills the ideal candidate would have.

In my opinion, the job profile is strongly oriented towards leadership and soft skills including moderation, facilitation, presentation, communication and conflict management, and less technically-oriented.

Scrummertime and the livin' is easy

By Marko Majki

I have prejudices.

Usually, people have prejudices about everything, including Scrum. This is normal and ok as long as we are aware of these prejudices and we're ready to deal with them.

Scrum is usually compared to those project processes, methodologies, and frameworks we already know and Scrum is compared to them, colored with our expectations. People got to know about Scrum in different ways, googling, from a friend, heard about it in a conference, or as a buzzword somewhere. Anyway, we come to the Scrum in hordes, and there isn't a person that I've met who didn't think "Hey, this is really simple!" and who wasn't delighted with Scrum's simplicity. Because of this, Scrum is a honey pot for the IT community.

Scrum is very EASY to attract people to.
Scrum basics are very EASY to learn and understand.
Scrum is EASY to start with.

That's all about EASY Scrum. All that comes after that is HARD. And, in my opinion, this transition from an EASY to HARD state of mind is the biggest issue in failed Scrum implementations. We are not prepared, we are lazy, we don't want to work hard, and we are always looking for an easier way to succeed. That's human nature. But humans are intelligent beings. We should inspect and adapt. We should inspect issues that occur, and we should adapt to these new circumstances.

Yes, I understand the disappointment of knowing that not everything about Scrum is sweet. A bitter taste forms after the first issues start coming, pushing us away from Scrum. When impediments start coming up, all the "dirt" will start coming to the surface, showing the ugly face of our project, habits, organization, and ultimately, us. We then face a pretty tough choice. We're essentially Neo, and we can take either the red or blue pill.

Those who choose an easier way tend to give up, blaming Scrum for their troubles and failures. These people tend to think, "Hey, we are perfect, but forced to live in this imperfect world." This way of thinking certainly improves our morale, self-esteem, and self-confidence, at least for some time. But our morale, self-esteem and self-confidence are pretty hungry beasts that should be fed often. And their hunger makes us their slaves.

To break free, we have to be brave; we have to say "ENOUGH." We have to take another bitter bite, and then another and so on, until all that is left is crumbs.

Those who stand against these issues, dealing with them despite this bitter taste, have good chance to become great change agents, great ScrumMasters and good Scrum coaches. Deal with all those challenges and you'll earn real self-esteem, self-confidence, and the respect of people you work with. Fighting the impediments with Scrum principles, you are fighting a good fight.

Those who retreat shouldn't be criticized, but supported, encouraged and coached. To fail is to be human, and there's the "gravity" of an easier way that brings us down, but standing up and keeping to the Scrum principles is quite rewarding at the end. After winning those battles, and beating all obstacles, you will be able to say proudly, "I'm a ScrumMaster."

Doing Scrum usually means that you will get into conflict with people at some point. Conflict is quite stressful and tough. Conflicts are impediments in your Scrum implementation, and you are the one who is expected to solve them. Yes, it's a tough job. You are the one who is expected to tell the people the truth about the ugly reality, which, sometimes, can be painful. Again, it's a tough job. And remember, there's no EASY way to do the job. Don't try to find a workaround, just do the right thing. Sometimes you won't know what the right thing is, but you'll feel it, as long as you're following Scrum principles.

There are people who didn't give up on Scrum (at least not completely), they don't use Scrum, but use this buzzword claiming that they are Agile and efficient. After all, it's nice to be in such good Scrum and Agile company! It's similar to claiming you drive a Ferrari, but don't. This means that you are successful, being in such good, high class company. But what's the real value of it? Nothing! Finally, when you take an honest look at yourself in a "Scrum mirror," you'll see a guy driving 30-year old car, worth nothing. Reflecting, you'll still see non-functional teams and organizations, and bad software habits. It's essentially nothing of real value. This illusion will disappear very soon and your software will still suck. Yes, this is another EASY way, but wrong as well.

Wake up; there's no EASY way.

Scrum is EASY to understand and embrace, but be careful, or you'll be misled. Don't blame Scrum for it. Living with Scrum is not easy, but I feel great, because I believe Scrum gives me an opportunity to do my job honestly. And after doing Scrum for a few years and coaching Scrum for a year and a half in my company, I can tell you this: It is rewarding. I remember the mess I found there at the beginning. And I look at it now. I feel like a parent whose child has become a decent person. "Just look at him!" I can proudly say. And no, it is not only Scrum. Scrum helped me, but I did it with a little help from my friends, or my Team. I'm really grateful to Scrum and to all the people I learned Scrum from and taught Scrum to. Scrum gave me the tool that I used to help create beautiful teams, relationships, processes, and organization. Finally, I feel that I improved myself while on this path.

And once more, Scrum is easy to learn, but doing it is difficult. Be careful. Don't expect easy tasks on this path. Don't expect an easy shortcut to victory. Be courageous. Scrum will reward you, helping you on this path. Getting results, your work will be recognized and you will improve your professional career. You will bring good changes to your teams, processes, and the organization. You will help change people in a good way. You will improve yourself on this path.

Scrum, thanks for NOT being EASY! Thanks for improving me on this bumpy road.

Ba and Knowledge Creation in Scrum

By Heitor Roriz Filh

This article briefly discusses the creation of knowledge in Scrum and the importance of the environment that enables knowledge creation and cross-pollination, the ba. The term ba is originated from the Japanese and can be translated as place. The SECI model, as described by Takeuchi and Nonaka defines a dynamic process in which explicit and tacit knowledge are exchanged and transformed [1]. During this process, Nonaka and Konno point out four types of ba that support and enable the creation of knowledge [2].

As Sutherland and Schwaber describe, the Scrum Team interacts in an iterative manner [3]. According to Sutherland et al., in order to obtain the most out of Scrum, the team must attain to certain constraints [4] [5]. These constraints lead to hyperproductive teams and the stabilization of the environment where the team works. This environment is the Scrum Team’s ba. Nonaka and Konno assert that the creation of the ba is the company’s responsibility [2]. The company must create the baand ensure their continuous transformation.

During the Scrum process we can identify (e.g. during a Sprint) the SECI knowledge creation process. For each of the steps in the SECI Model, we have a specific ba that is specifically suited to each of the four knowledge conversion steps [2]. The ScrumMaster plays a key role to obtain the four ba to facilitate the Scrum process for the team and foster the creation of project knowledge and knowledge cross-pollination.

SECI Model and Knowledge Creation

Takeuchi and Nonaka suggest a model for knowledge creation called the SECI Model [1]. In this model, the spiral path to construct new knowledge presents four steps in the knowledge conversion process:

1. Socialization: where tacit knowledge between individuals is exchanged.
2. Externalization: tacit knowledge is converted to explicit knowledge.
3. Combination: explicit knowledge is converted into more complex explicit knowledge.
4. Internalization: when internalized by some individuals, explicit knowledge becomes tacit again.

The Four Types of Ba

Nonaka and Konno describe four types of ba that suit each of the steps in the SECI Model. The four types of ba are [2]:

1. Originating ba is the place where individuals share feelings, emotions, and experiences. It is the primary ba from which the process of knowledge creation begins and represents the Socialization step of the SECI Model.
2. Interacting ba is the place where tacit knowledge is made explicit, so it represents the Externalization step. In this ba through dialogue, individual’s mental models and skills are converted into common terms and concepts.
3. Cyber ba consists of a place of interaction between individuals in a virtual world through the use of IT tools. This ba represents the Combination step.
4. Exercising ba supports the Internalization step. This place facilitates the conversion of explicit knowledge to tacit knowledge.

Scrum and the SECI Model

In Scrum we can easily identify that all steps of the model are present. Socialization and Combination happen constantly, especially during the Daily Scrum. The dynamics created by Scrum and the aim of cross-functionality that teams are always looking forward to achieve is crucial to these two model steps. The technical part of the Scrum Review is also a source for both steps. Dr. Jeff Sutherland suggests the adoption of Pair Programming to achieve excellence levels while adopting Scrum [4]. This technique is a fertile ground for Socialization and Combination.

Now let’s consider Externalization. It is up to the team to decide what is going to be documented and what is not. It may also happen that the ScrumMaster has the task to prepare documents in accordance to some process in the company where the project is undertaken.

Internalization and Combination are crucial to cross-functional teams. After acquiring knowledge during a Sprint and Scrum ceremonies, an individual creates and/or appends new knowledge to his or her pre-existent set of knowledge. Ultimately the result of the team’s internalization process is the development of the product.

Summary

It is up to the organization to create and transform the Scrum Team’s ba. As the servant leader for the team [3], the ScrumMaster must facilitate the knowledge creation process and maintain these ba in order to maintain the flow of knowledge. The team nurtures the ba while it acquires experience and develops its interrelationship. The Originating and Cyber ba are strongly related to the Scrum Team’s location, i.e., their workplace. The Cyber ba can be extended to geographically separated teams as Scrum benefits can be obtained in such environments [6] [7].

References

[1] I. Nonaka, H. Takeuchi, The Knowledge Creating Company, Oxford University Press, New York, NY, 1995.

[2] I. Nonaka, N. Konno, The Concept of “Ba”: Building a Foundation for Knowledge Creation. California Management Review, Vol. 40 No.3, pp.40-54.

[3] K. Schwaber, Agile Project Management with Scrum. Microsoft Professional Series. Paperback. 192 pages. Microsoft Press, 1st edition February, 2004.

[4] J. Sutherland, Practical Roadmap to Great Scrum. Systematically Achieving Hyperproductivity. Keyonte speech in Munich Scrum Gathering. 19-21 October 2009, Munich , Germany.

[5] J. Sutherland, S. Downey, and B. Granvik, Shock Therapy: A Bootstrap for a Hyper-Productive Scrum in Agile 2009, Chicago, 2009.

[6] J. Sutherland, G. Schoonheim, and M. Rijk, Distributed Scrum: Agile Project Management with Outsourced Development Teams, in 40nd Hawaii International Conference on Software Systems, Big Island, Hawaii, 2007.

[7] J. Sutherland, G. Schoonheim, N. Kumar, V. Pandey, and S. Vishal, Fully Distributed Scrum: Linear Scalability of Production Between San Francisco and India, in Agile 2009, Chicago, 2009.

Three Things I Wish I Knew Before Jumping

By Pat Guariglia

Like many people trying to implement a Scrum/Agile project for the first time in an organization, I encountered a number of obstacles that were almost project killers. As I write this article today, I keep thinking, “if I only knew that when I started.”

When I started managing my first Scrum pilot project in 2007, I was new to the concepts of Scrum and Agile development. For years, I led projects using traditional project management methodologies common to PMI, i.e. Waterfall. During this time, I was a consultant to a New York State Agency. It was a typical Waterfall shop, with no history of using Agile or Scrum.

Sometimes you can choose the project you want to pilot, but oftentimes the project chooses you. In my situation, the Agency had its back up against the wall and needed to expedite the delivery of a critical project. Agency funding was in jeopardy and critical business dates needed to be met. In my opinion, certain types of projects are good candidates for Scrum pilots, and others are not. The project I led had none of the characteristics ideal for a pilot project; it was not the perfect candidate for a first-time Scrum implementation.

After being assigned to manage this project, I quickly realized that the project would never meet the deadlines within the constricted structure of the organization. It was necessary to break away from the Agency’s normal project management and development methodologies. The project sponsors permitted us to use the methodology of our choosing as long as we met the deadlines. I explored Scrum and various Agile methodologies and made the decision to abandon the normal Waterfall project path.

After one year, the pilot project turned into a program of three projects. Two of the projects used Scrum and the third followed a Scrum hybrid approach for managing a vendor’s customization of a commercial software product. The program was mostly successful, and the projects were delivered on time for all critical dates. The organization was satisfied with the use of Scrum and looked for other project opportunities to leverage some of our Agile best practices.

The first few months were difficult and outright painful as the team learned the practices of Scrum, the variations of Agile development, and the nuances of the customer’s business. Our team had little guidance and no one coaching us on Agile or Scrum methodologies. For months, we worked in the dark to avoid scrutiny and work out the details of our methodology, with only a few people aware of our voodoo methodologies. We had only one clear goal, to achieve the deadlines without failure.

Even though I had moderate success with the three projects, I discovered literally hundreds of things I wish I knew before setting off on my pilot journey. I want to focus on three critical topics for this article, which I believe anyone starting a Scrum pilot project should know. The three things I wish I knew most before jumping into my first Scrum project are: 1) select a project with medium criticality; 2) continuously communicate your chosen methodology; and 3) demystify the voodoo (this one needs some explaining).

These three topics are basic and straightforward, and should be universal to anyone attempting an Agile/Scrum pilot project for the first time. I chose three things that focus on the early stages of a project, but could also be valuable throughout the project’s lifespan.

Select a Project with Medium Criticality

In order to have a successful Agile or Scrum pilot project, it is important that the project chosen has enough importance or criticality to the organization. Projects with low levels of urgency will get brushed off and not given the resources, attention, and critical thinking needed to properly develop a Scrum project. Pilots with high criticality are not good for several reasons. The main reason is that there is little room for failure. If the pilot is not successful, it can be a huge black eye on the face of future Scrum efforts. Also consider that on a project with high criticality there will likely be many attitudes and influences on the project, which could steer it off the Scrum course.

Typically, good candidate projects have medium importance to the organization. It is important to understand this when choosing a pilot, if you are selecting one from your portfolio. An excellent resource on this topic is a book by a friend of mine, Greg Smith, titled Becoming Agile in an Imperfect World. He covers various aspects of a good pilot project in his chapter “Characteristics of a Good Pilot.”

Continuously Communicate Your Chosen Methodology

I cannot express the importance of this topic enough. In the years that I have been a project manager, I have never been able to communicate enough. Just when you think you have covered all bases, there is someone lurking in the shadows not paying attention. According to PMI¹, the amount of time a project manager spends communicating is 90%. This holds true for Agile project managers and ScrumMasters as well.

Since I have been using Scrum, I have been both a ScrumMaster and project manager on each project I manage. As a ScrumMaster, I have spent countless hours coaching and deflecting potential issues/problems away from my team. As a project manager, I have spent an inordinate but necessary amount of time reporting status, building relationships with stakeholders, and keeping the projects aligned with the organization’s standards, rules, and strategic goals.

When starting a Scrum pilot project of any type, it is of vital importance to communicate your chosen path (Scrum) to everyone you interface with. You should not communicate this path just once or twice. It will be necessary to continuously express, elaborate, and explain Scrum to every stakeholder and team member until they no longer look at you with confusion in their eyes.

After more than a year and a half into my pilot Scrum project, I was talking to a functional manager about our Scrum methodology and how we were using Scrum and Agile development. The manager appeared confused and disoriented by the conversation. This was not the first time discussing this methodology, but the manager reacted as if it were. This reaction is common in an organization heavily framed within a Waterfall methodology.

Typically, few people in traditional Waterfall organizations have been exposed to Scrum. I made the false assumption in the beginning and middle of my pilot project that stakeholders and the accidental support person were familiar with Scrum or Agile development, because I gave several overview presentations to them. This assumption was way off on my part. In order to understand Scrum, one needs to be involved in Scrum. Observing Scrum from the outside can be odd for some, and for others it can be confusing.

After many months of trial and error, our Scrum team finally reached a cadence and became better at estimating and delivering. The people who interfaced with us on a regular basis, who were outside the immediate Scrum team, including support units, infrastructure, and the PMO, began to better understand the Scrum process. If your pilot project is progressing successfully, it will become easier to communicate your process because everyone will want to know how you are doing it. On the contrary, if your project is lagging or plagued with issues, it will be hard for you to find an audience that you can convince that Scrum is the way to go.

Communication on any project is the most important part of a project manager or ScrumMaster’s job. The sooner and more frequently you communicate what you are doing the better off you and your project will be at surviving the first Scrum attempt.

Demystify the Voodoo

In my attempts to “demystify the voodoo” of Scrum to the outside observer, I have realized that this is not always an easy task, and is one that requires frequent attempts at demystification. When I first started using Scrum and Agile it was painfully obvious that others in the organization, including some stakeholders, were uncertain about my methodology and had a preconceived notion about Agile and Scrum. This misconception was something I continuously confronted throughout my project, as it was an impediment to my progress.

The reason voodoo becomes an impediment is mainly due to the reasons mentioned above in the communication section. It is important to communicate the methodology, which means define, describe, demonstrate and illustrate, thereby demystifying whenever possible. Most of the voodoo comes from not understanding the methodology or having the wrong information. Agile and Scrum are demystified every time one communicates or explains their pros and cons to the outside observer or reluctant stakeholder.

Unfortunately, as a project manager and ScrumMaster, it is possible to contribute to the voodoo perception. Performing Agile “in the dark” or “under the radar” can sometimes make the methodology even more taboo or misunderstood. Performing this style of clandestine Agile can be beneficial for a short period while the project team is getting up to speed and processes are being defined, but continuing too long in this mode will eventually be counterproductive. Stakeholders want to understand how the project is being managed. At some point, it is necessary to communicate the methodology before others begin forming their own opinions of what you are doing.

Using examples of public success stories also helps to demystify Scrum. After articulating various definitions of Scrum and Agile development processes to my stakeholders, I looked for examples of successful implementations of Scrum in both the private and public sectors. Illustrating how a CMMI²level 5 company can successfully put a Scrum project into place certainly got the attention of some of the stakeholders. I showed quantifiable results from Systematic, a CMMI 5 company who measured productivity and quality before and after they implemented Scrum. Their overwhelmingly positive results put many of my stakeholders finally at ease.

Wrapping Up

Though there are many things I learned along the way, the few that I have described here are the ones that would have been the most helpful at the start of my Scrum/Agile experience. If you have any choice in the matter, remember that when starting your first Scrum pilot project, it is important to pick the right project. Also, communicate your methodology, risks, and plans continuously. And finally, provide accurate and substantive information to support the use of Scrum and Agile in your organization, which in the long run will demystify the aura of Scrum.

Scrum is not a cookie-cutter mold that you can throw your project into. Scrum is adaptive and can be customized to some extent to fit the unique situations and conditions of your environment.