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.

How PD works in Agile team

By Dingshan Li

PD (Product designer) is very important role in software development. They will provide detail requirements specification and business workflow, UI workflow. In traditional software development process, PD will prepare the detail requirement design document before develop team start to make software design. This kind of process will work pretty well if the requirements are clear and relatively stable. Also, there are enough PD resources to make the complex documents. But most of time, we cannot figure out the whole requirements clearly at the start stage. And the scope change is often happen. Another factor is that PD always need to work on more than one product and it is very difficult for them to spend much of time to work out a detail design document. So, what can we do to deal with this kind of issues?

Agile provides a methodology or framework for the team to develop software under the situation of changing scope. By focusing on high value requirement, separating the long lifecycle to be several short iterations and guarantee fully-test in each iteration, it can provide high-quality and expected software to the client. In this kind of framework, how PD works in the team? How they collaborate with others

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.

The Land that Scrum Forgot

By Robert C. Martin

Scrum is a starting point. In fact, it’s a great starting point. But, as a framework rather than a full-blown methodology, Scrum is deliberately incomplete. Some things—such as the best technical practices to use—are left for individual teams to determine. This allows a team to create the best fit between their project and environment and an assortment of technical practices.

While that selection of practices should belong to the team or organization rather than to a group of methodologists, the benefits of some practices are becoming so compellingly obvious that they warrant consideration by any Scrum team. But, too many Scrum teams become complacent after achieving some early productivity gains with Scrum. And they stop seeking ways to improve. Many fail to try the technical practices necessary for long-term success. In the following article, Robert Martin (perhaps better known as "Uncle Bob") tells us why so many Scrum teams fail to sustain the promise of their early successes.

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.

Agile Tools vs. Agile Books: The value of tools over the value of books in the agile world

By Paul Heidema

I have been working with Agile for a couple of years. At Berteig Consulting we are using Agile to run our small business. As such we try to use various tools to make our life easier. We have used CardMeeting for our cycles and tasks. I have tried using PlanningPoker for online estimation. It seems useful, but maybe our team is too small to make great use of it. I am also looking for other ways to manage the reflections and learning from each cycle.

I have received an email from David Wolrich of CardMeeting that states: “Anyways, I rely on the trickle of news from legitimate organizations like yours to let users know that CardMeeting is still around, that I am still adding features, and to generate interest; thanks again.” So maybe some of you could try it and give him a shout. Much like other free applications on the net such as Drupal and Neo Office this one could become more robust and useful.

Continue reading this article.

Scrum & Gaming Addiction: How Scrum is like online gaming in creating engagement (and even addiction) in your organization

By Pete Behrens

There are few people in our Scrum Community who know personally the power of video games to engage people, and even create addictions to them. There are even some who have applied Scrum to creating those addictive online video games.

This article is not about applying Scrum to gaming applications; rather, it is about the similarities Scrum has to the gaming world in what makes them so addicting. Video gaming is one of the largest growing markets in the world at $50B this year and is on target to be three times the music industry by 2014. This year alone, there was $8B spent on virtual goods in online gaming systems - a true market indeed.

We can learn a tremendous amount from the viral and exponential growth of the video gaming industry. What makes these video games so interesting, engaging and addicting; and what can we learn about them in making our organizations more interesting, engaging, and even addicting?

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.

Why Your Boss's Boss Should Also Go Agile

By Christine Crandell

Incremental software development methodologies can be traced all the way back to the 1950s, but it wasn’t until 2001 that “The Agile Manifesto” created a comprehensive and landmark account of agile development and why it’s a better, lighter approach to creating software faster.

Ever since then, developers have been using agile methodologies to improve the speed and flexibility of software development through operational improvements, but most other groups within the same company have not adopted a similar philosophy.

Conceptually we’ve bottled up agile as being for software developers, as if speed, flexibility, and complexity weren’t also issues held within every other departments of fast-paced software companies. When software developers are using agile methodologies, but nobody else is, developers become like the clique group of school kids who share a foreign language nobody else understands.

This has caused us to limit the potential for agile frameworks, because they're only implemented operationally, but not strategically. It’s like a wooden boat full of rowers. They might have seamless coordination and full visibility into the work of their colleagues, but they can’t see the captain’s orders up on deck.

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.

Negotiating Scrum Through a Waterfall: How One CSP Navigates the Difficult Waters of Implementing Scrum

By Phil Southward

Negotiating a Scrum team through the often laborious processes required in a waterfall-based organisation without getting stuck between departmental snags or ensnared in the inexorable documentation eddies along the way is an arduous and, if I may be excused the pun, agile undertaking. Sitting out the umpteenth interdepartmental project sign-off meeting, a Scrum practitioner could be forgiven for thinking that the waterfall manifesto, if there was such a thing, would value:

•    Processes and tools over individuals and interactions.
•    Comprehensive documentation over working software.
•    Contract negotiation over customer collaboration.
•    Following a plan over responding to change.

In this clash of cultures, conflicts inevitably arise, yet if my experience in a couple of large (over 4,000 employees) waterfall-based companies is anything to go by, the two can be made to fit together. Somehow.

First up. Work around the keepers of the waterfall manifesto by negotiating a change to the contents of the waterfall deliverables to make them more Scrum-like. Second. Alter the Scrum artefacts and definitions to fit with the waterfall world negotiated above. Finally, as a last resort when nothing else is possible, create all the required waterfall process documentation and deliverables, while running projects internally using Scrum. Successfully negotiating the waterfall will involve some combination of all three.

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.

The Scrum Team: A Puzzle of People: How one CSP builds teams by inspecting and adapting

By Knut Kvarme

By definition a team comprises a group of people linked in a common purpose.

It is my experience when I get involved in discussions regarding a new project, it soon becomes a conversation about the team and who you want to group together in order to deliver within the scope defined in the project assignment.

After several years with the cross-functional team mantra at mind, I no longer think about my new team in terms of who (people). I rather think of a range of skills that I need in my team. After staffing my team I usally find that not all the skills on my list have been covered. And that’s perfectly fine!
Getting the team started and having an inspect and adapt approach in regards to the team coalition is my preferred approach. Sometimes the team steps up and gains the required skills. In those cases no further staffing is necessary.

Other times my initial list of required skills might have been wrong, and we complete the team with adding people with other skills that I thought was needed. The big advantage of this inspect and adapt staffing approach is that the gained knowledge about the tasks in hand and the observation and understanding of the team, provides the answers on how to complete the staffing of the scrum team.
So, we have a complete team with the required skills. What now?

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.

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

By Edward Wehr

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

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

Priorities Are Priority One.

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

Continue reading this article.

The Quest for High Performance: How one CSP gets his teams off to the right start

By Tom Reynolds

Over recent months I have been working with Lyssa Adkins to improve my coaching skills. One of our areas of focus has been team start-up and our expectation that we have for our teams to become high performing. In our work together, Lyssa shared some team start-up exercises to use with new teams. I had an opportunity to put some of these ideas into practice recently and want to share that experience with the Scrum community.

Team start ups cover three areas:

• The process
• The team and individuals
• The project

This article will focus on the work I did with the process.

Starting a team off on the right foot is an essential part of building solid foundations for the team.  Don’t skip this step. It’s true that start-up exercises take some effort and thought to prepare; however, the work that is put in at the start will pay dividends further down the line.

Continue reading this article.

My Journey as a Coach: How I came to be a coach and why you should be one, too

By Skip Angel

Helping others. That’s been my purpose in life at even an early age. When I saw somebody in need, I was there to help. When a fellow student didn’t understand an assignment or how to apply something new that they learned, I was usually there helping them figure it out. As a developer starting out my career, I often paired with other developers and worked through solutions, well before agile came into being. As a manager, the chance to mentor others and improve processes to make life easier for others was the parts of the job I enjoyed the most. I guess you could say I was destined to become a coach, it seemed to be part of my DNA. 

After learning and applying Scrum to an organization where I was the Chief Technology Officer, I realized that I needed to help other organizations as an external coach. Some thought I was crazy, giving up a key position in a stable company in very unstable times. Though there have been risks, the rewards that have come with coaching far outweigh them. I have been involved in both small and large organizations, with various size teams across many locations throughout the world. There is no better thrill than when a person comes up to me and says, “I now know what you have been talking to us about and I get it.” My goal for every company is to reduce the pain of delivering software and bring the fun back so people enjoy their jobs. My greatest joy is when my coaching makes a difference to the operations and bottom line of the business. It is these situations that drive me towards continual growth and improvement in my role.

Continue reading this article

Going from Candidate to Certified Scrum Trainer: A CST shares his advice on surviving the CST application review process

By Michael Vizdos

So you want to be a Certified Scrum Trainer. And to do that, you are entering into the candidate review process. Or maybe you’re just curious as to what it takes to earn the Certified Scrum Trainer designation. Wherever you are on your agile journey, I wanted to take a moment to give you my two cents on the new candidate review process from the CST perspective. We’ll talk about what the process is, what I’ve learned so far, and what it means (and doesn’t mean) for the Scrum community as a whole.

The Process Itself

First, please remember that certifications from the Scrum Alliance, whatever they are (CSM, CSPO, CSP, CSC, or CST), are really just the beginning of a journey for people who receive them.  I received my initial CSM in 2004 with Ken Schwaber, and at the end of 2006 was designated as a CST (also granted by Ken Schwaber). The process has gone through many iterations over the years. While I have watched this happening, I have learned one thing -- the process will continue to evolve.

It must. Over the past six months, the Scrum Alliance has been trying some new techniques for a person to become Certified Scrum Trainer (CST).  The current process, called "V8", is located at http://bit.ly/simple-CST-process-v8. Today, as long as you are a Certified Scrum Professional (CSP) you can follow the five-step process and apply to become a CST. The first part of this process requires the CST candidate to register a statement of intent and have two people from the current CST community vouch for their integrity and act as their champions through this process.

Continue reading this article.

Adopt with Care: One CSM's 8-step approach to successfully transitioning to Scrum

By Prashant Pund

Do any of these statements sound familiar?

“Sure, we're using agile methods. I mean, we aren't entirely sure, but we think we're agile.”
“Well, the team conducts daily scrums, so they must be agile.”
“I have been tense since this guy introduced Scrum. Every morning I have to give a status report. It’s really taxing.”
“This fellow read something on the Internet about Scrum and said, let’s start Scrum tomorrow. I'm not worried. It's just another fad to ride out.”
“I heard there is a change in our process. The Process Group person is here to explain the new process, something called Scrum.”

If so, your organization likely is suffering from Scrum Mis-adoption Syndrome (SMS). SMS causes disinterest, failures to deliver, and profound distrust. The best way to treat it? Prevent it from happening in the first place.

A successful Scrum adoption requires a profound transformation of the organization. This change will be felt at the team level, yes, but will ultimately affect all layers of the organization. This then begs the question, How can I, being at the level of PM/Lead, bring in such a transformation? Shouldn’t it come from the top? The answer is both Yes and No. Yes, because indeed the transformation needs to have buy-in and support from the top. No, because a top-down approach is not sufficient. As Mike Cohn puts it, “Change is not top-bottom or (emphasis added) bottom-up; it’s both." In view of this, here is the approach I suggest to those who are trying to transition to an agile methodology such as Scrum.

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.

Are We Headed to Abilene? How the Abilene Paradox Hinders Team Collaboration

By Badri N Srinivasan

Collaboration is an important aspect of any complex activity. On complex projects, a single individual cannot guarantee successful customer delivery—one that meets schedule, quality, cost, and other parameters. It takes a cohesive team.

Scrum promotes these cohesive, self-organizing teams. Scrum teams are tasked with finding the most optimal way to accomplish the work. To do this, they make decisions ranging from how best to meet goals to who should work on which tasks. Reaching group consensus can be difficult. Some opinions are more dominant than others; some voices more hesitant to speak out. Even in agreement, true consensus might not exist. One manifestation of this is the Abilene Paradox.

Abilene Paradox Explained

The Abilene Paradox happens when a group of people collectively decide on a course of action that is counter to the preferences of any of the individuals in the group. This occurs because each member mistakenly believes that his own preferences are a contradiction to the group and, therefore, does not raise objections. When this happens, team members, in an effort not to "rock the boat," don’t voice their thoughts, desires, or intentions.

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.

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.

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.

Agile Coaching Qualities, from A to Z

By Sunil Upadhye

Successful ScrumMasters and agile coaches share many positive qualities—listed here from A&A to Z&Z.

Attitude & Affirmations

Dress up your attitude and you can achieve 100 percent success. Affirmation is a self talk – whatever you say to yourself will be reflected in your behavior. Be kind to yourself and nice things will happen.

Balance & Benchmark

Create a balance in your mind. Be unshakable in the war against Naya – No Sayers. Create a benchmark of your work today. track the progress of your team through constant feedback mechanism.

Courage & Collaboration

Only courage can create highly collaborative team.

Determination & Desire

Have a strong determination to make others successful. Desire success. Look for the good in everyone. You will find excellent things in every human being.

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

Scrum Success in a Distributed Team Environment

By Feyza O’Connell

In today’s work environments, research proves that distributed Scrum teams can achieve the same quality results as collocated teams, but relationships, communication and culture play important roles in the latter.

About Scrum

Since its inception in 1993, Scrum has become a more and more popular software development framework among organizations.  In fact, a Forrester research study, conducted in the fourth quarter of 2008 discovered that more than half of the 2,227 surveyed software organizations take advantage of some form of agile methodology. Additionally, of all the agile methods that are being utilized, Scrum is by far the most popular model.

Scrum is based on effective, small teams working in an interdependent manner to achieve specific yet flexible agendas. As decisions are based on real-time information, the teams must be self sufficient, have carefully defined responsibilities, and exhibit excellent communication skills.

Why Are More Organizations Embracing Scrum?

More companies are embracing Scrum as this framework can, quite simply, create excellent quality products in less time than other more traditional methodologies.  In other words, Scrum can save companies both time and money.

Continue reading this article

How I Stole an Office and Fixed Our Daily Scrum

By Aaron Conoly

As I mentioned in my last article, I'm new to Scrum, and the journey to implement Scrum has had its challenges and rewards. After using Scrum for a month or so, I started to see a deficiency; we weren't having productive Daily Scrums. So, I decided to go to my "office" and start a list of action items for improving our Daily Scrum.

Much like how I got my "office," I decided the best route was to incrementally introduce improvements to our Daily Scrums. You see, for the past year, there's been an empty office next to my cube. After surveying surrounding departments and rigorously analyzing the local power structure, I determined that the office was fair game, and likely to be empty for some time. So, I decided to incrementally claim the territory. First, there was the "Hang In There, Kitty" poster that I hung on the wall facing the desk that was soon to be mine. A week later, I added several stacks of papers to the desk. It was a gamble, but when a manager commented "Jeez, that guy must be busy, but at least he's staying positive," after surveying the stacks of "work" and kitty poster, I knew I was on the right track. Over the next few weeks, I added more items, a chair, a few photos, a wall calendar; only one last step remained, moving in. So, after weeks of preparation, I made my move. It was a particularly hectic day, with a lot of bustle, and I needed a place to think in peace. So, I grabbed my laptop, walked into my office, and closed the door. At first, I just sat there, staring at the laptop, terrified that someone might walk in and blow the whistle on the whole operation. My palms were sweaty, and I thought I smelled cheddar. After an hour, it was clear that my strategy had worked. By incrementally instituting the changes, I was able to convince everyone that the office was indeed mine. I decided to use the same approach with improving our Daily Scrum.

The problems with our Daily Scrums started almost immediately. While our Team was thrilled with the concept of the Sprint (especially the being left alone to work for 2 weeks part), the Daily Scrum never gained much traction. Every morning, the Team would amble in to their cubes, each with a "not before I've had my coffee" look on their faces.  Ten minutes later, we would have our Daily Scrum. After an audible sigh, each member would face the manager and talk about what they did yesterday and their plans for that day. Each meeting wouldn't last more than a few minutes (we're not a big department), and afterwards, I'd hear the Team complaining about how the Daily Scrum was pointless and a waste of time.

So, my list included some incremental changes that would hopefully create a successful Daily Scrum. First, we moved it to 9 am. That way, everyone was able to get settled in, grab some coffee, but not so settled in that the meeting would disrupt work in progress. This helped remove the "bother me this early and I'll fight you" mentality.

Second, we got rid of the manager. Nothing says "progress report" more than facing your manager every day and telling them what you've been up to (a whole bunch, I swear!). Instead, I played the ScrumMaster card to insist that our manager merely observe... from her office. Suddenly, the Team was talking amongst themselves. Better yet, they were solving problems. Not only did everyone know what everyone was working on, but more importantly, they were working as a team, removing obstacles, sharing information, and getting things done.

Eventually my office plan fell through. We had a new manager start with the company and my items were returned. However, the "Hang in there Kitty" poster remains to this day, in my cube, reminding me that incremental changes can make a positive difference, with enough time and patience, of course.

Have you had difficulty making your Daily Scrum effective? If so, how did you solve the problem?

This article was reproduced from www.scrumalliance.org

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.

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.

Power of the Post-it

By Aaron Conoly

When it comes to Scrum, I'm a newb. I got my CSM certification last year and have been slowly learning how best to introduce Scrum to my organization. Recently, I started using Post-its to enhance how we use Scrum.

Just to be clear, I am not the official spokesperson for 3M products (although that doesn't sound like a bad gig; in fact, 3M, if you're reading this, call me!), and I haven't received any kickbacks for endorsing the Post-it (again, 3M, call me!).

Anyway, I'm something of a hero around the office, because I solved two problems with a simple, yet extraordinary item, the Post-it. A year ago, we were up to our necks in missed deadlines, broken promises (and, at times, dreams), and shoddy workmanship. So, we decided to seek out a new way of getting things done. It so happens that we came across Scrum, which, incidentally, focuses heavily on getting things DONE. And, even though we aren't a software company, we were drawn to Scrum because it provided a fresh, effective way of producing acceptable product. After doing more research, we decided to send one of us to a CSM course. The next month, I spent two days learning about Scrum, and at times, nodding my head and pretending to understand conversations about "Java software architecture," and "version control systems." Later, I took the exam and got certified. I returned to the office triumphant, a veritable Jedi Master of all things Scrum.

Then my boss asked me a terrifying question. "Well," she said, "what now?" After stumbling and bumbling over how exactly to say let me get back to you on that one, I retreated to my desk, defeated. Suddenly I wasn't a Jedi Master, heck, I could barely pass as a Scrum Ewok. I had to find a way to confidently describe Scrum and how our company could use it to get better results.

I stressed until I remembered a great part of my CSM class. The instructor asked us to write down any questions, preconceived notions, or concerns on a Post-it and attach them to the wall. Later, if any of the questions or concerns hadn't been addressed, the instructor would read the Post-it and provide clarity. So I decided to use this approach. I called a meeting with my boss, the VP of my department and my colleagues to discuss Scrum.

"Ok," I said, "before we start, write down any questions or concerns you have about Scrum on a Post-it and stick them on this whiteboard." The room grew eerily quiet. After what seemed like an eternity, my boss finally stood up and put a single Post-it on the whiteboard. It said, "What is Scrum?"

This was my first experience with Post-its, and I was already willing to scrap them and Scrum all together. But, I don't give up easily, and I realized that they couldn't have had any concerns or questions, because none of them knew anything about Scrum. It was my job to lead them.

After explaining Scrum, and answering a few questions, the meeting ended. My boss approached me and said, "This sounds great. How do we make sure everyone's following the process?" We determined that I would be my department's ScrumMaster, and that part of my job would involve providing a visual that would help keep everyone on track.

So, I decided to give the Post-it another try. I wanted to provide a compelling, easy way for our team to keep up with our product backlog and track progress. So, after researching various approaches, I decided to get a large dry erase board. I listed all of our projects on the board, and created two columns, Current Sprint and Backlog. That way, every Sprint, our Team could add Post-its for things they were working on, and the PO could add Post-its to the backlog as new items were added.

The Post-it board immediately became a hit. You could say it was our second water cooler. I always find team members discussing new backlog items, or proudly announcing they've completed an item. Better yet, the team has a greater sense of accomplishment, as completed items get sent to a special place, the Wall of Fame, where a mountain of Post-its are proudly displayed (this was initially a molehill).

The Post-it has expanded its influence. Soon after starting our Daily Scrum, we decided to clearly identify the chickens and pigs, by providing "Cluck, I'm a Chicken," and "Oink, I'm a Pig" name tags. All visitors are required to wear a chicken name tag, which usually leads to a discussion about Scrum. Thanks to the name tags, more departments are learning about Scrum and asking more questions about the process.

We also use Post-its to encourage proper lines of communication. Unfortunately, and don't think I haven't tried at least twice, I don't have my own clone to run around and ensure our team is focused like a guided missile on their Sprints. So, everyone's cubes/office door has the "Have a request? Go talk to our ScrumMaster!" Post-it. This again has led to further discussions about Scrum, and we've ensured that all requests are getting properly funneled to the product owner.

So you could say that Scrum has changed the way we do business for the better, but it couldn't have happened without the Post-it (3M, I just sent an e-mail to your PR department. Call me!). These days, the Post-it continues to not only facilitate current processes; it is helping build a foundation for future projects. We just created a Strategy Board, a whiteboard that is separated into two sections, "Where We Want to Be," and "How Do We Get There?" Post-its already cover it.

For those of you thinking If you love Post-its so much, why don't you..., well, I just might do that.

And for those of you who have used the power of the Post-it in your Scrum processes, tell me about it. We're always looking for fun, new ways to better use Scrum.

Transitioning to Scrum: Selecting the Product Owner

By John Clifford

Many teams moving to Scrum have questions about the Product Owner position. Is the Product Owner a member of the Scrum team? What role does the Product Owner play in the day-to-day life of a Scrum project? How do we map current functional roles to Scrum roles, specifically with regard to the Product Owner? Who should we select as our Product Owner?

Let me start by saying the Product Owner is perhaps the most important role in Scrum, something you don't often hear from Scrum folks. The Scrum process defines the Product Owner as being the person responsible for the team's return on investment, i.e., the Product Owner will be judged by whether the project's outcome justifies its cost. Another, more direct way of saying this is to identify the Product Owner as "The Single Wring-able Neck," or the person whose head is on the figurative chopping block if the project fails. Interestingly, the Project Management Institute has a similar definition for project managers: the person assigned by the performing organization to achieve the project objectives (PMBOK Guide, 4th Edition, p13). Therefore, based upon both the Scrum and PMI definition, the Product Owner responsibilities are equivalent to those of a project manager. This is one reason why I have found knowledge and competence in project management to be a key ability of a successful Product Owner. Selecting a Product Owner therefore naturally starts with identifying candidates who have that knowledge.

There are other skills and abilities required, including sufficient technical knowledge to understand the problem domain and the technical aspects of proposed solutions. A successful Product Owner doesn't need to be the best software developer on the team, but he does need to be able to understand the technical decisions well enough to know whether they make sense. Eliminate candidates who lack sufficient technical ability.

Be especially careful not to view the Product Owner as the project's 'driver.' Scrum is about empowered, self-managing teams that are led (pulled) rather than driven (pushed). Scrum means never having to be driven. Candidates who can't or won't embrace the servant-manager philosophy, or who insist on directing the team should be disqualified. Nothing will cripple your Scrum implementation more than ade jure Product Owner who sees himself as a de facto team manager.

By now, you should have narrowed the candidate list to those who have demonstrable technical, project management, and interpersonal skills. Who among the remaining candidates has the ability to understand the customer, the market, and the business? Are there candidates with entrepreneurial experience? Owning a business, starting a business, or working in a leadership position at a startup where everyone wears a multitude of hats and understands making money is the true test of whether or not the customer is satisfied is invaluable. People with this experience understand what really matters because they've lived it. People who have had experience in customer support, QA/test, or sales and marketing at larger companies may also have an understanding of the customer.

Now you should be down to the final few candidates. I like the Toyota Production System concept of a 'Chief Engineer' with extensive technical, project management, and business knowledge who leads the team to successful project completion. We're talking about candidates with a software development background and successful project management experience, who have dealt effectively with the customer and understand business realities, and have the skills and experience to successfully act as a proxy for the customer and other stakeholders. Which of the remaining candidates most closely matches this description? If there is no one, have any of the candidates shown promise that they can develop to this level? If the answer is still "no," then you may want to hire someone with the necessary talents and skills to fill the position.

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.