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

By Edward Scotcher

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

Scrum Master's Responsibilities

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

Continue reading this article.

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

By Roman Pichler

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

Continue reading this article.

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.

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.

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.

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

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.

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.

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.

Scrum In A Nutshel

By Dan Rawsthorne and Douglas E. Shimp

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

The Team

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

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

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

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

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

The Backlog

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

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

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

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

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

The Release

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

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

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

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

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

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

The Sprint

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

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

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

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

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

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

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

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

Quick Summary

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

Manager 2.0: The Role of the Manager in Scrum

By Pete Deemer

When an organization starts to explore Scrum, there’s often an uncomfortable moment early on when someone points out that the role of "manager" seems to be missing entirely. "Well I guess we’ll have to just get rid of ‘em all!" wisecracks one of the developers, and all the managers in the room shift uncomfortably in their seats.

Scrum defines just three roles – Product Owner, Team, and ScrumMaster – and the basic direction given to others in the organization is to "support them, or get out of their way." This is not very detailed advice, especially if you’re a manager expected by senior management to ensure everything goes well.

The traditional role of the manager in the corporate world is based on a model known as "command and control." Here, the job of the manager is to identify what needs to be done, to issue detailed instructions to the employee, and then to ensure the employee completes the work according to the instructions. The role of the employee in this model is simply to follow the directions as given, trusting the judgment and wisdom of the manager to ensure that the right work is being done in the right way.

In complex, dynamic environments such as software development, this approach tends to break down. First, it is difficult and time-consuming for a manager to understand every requirement in full detail and issue precise instructions to guide the work of every employee. Within a software development Team, the work is highly interconnected, with intricate dependencies, and frequent change and surprise. To expect a single manager to do all the basic thinking for his or her team is unrealistic, and it often constrains the Team’s productivity to the manager’s ability to give instructions. In addition, this approach tends to be demoralizing for employees; their role is simply that of "order follower," and they often feel little sense of ownership of their work. Accountability is limited to answering the simple question, "did I complete the orders I was given?" If the answer is "yes," the job has been done – regardless of whether the right thing was built, built well, or built to satisfy the business goals of the customer.

Scrum is based on a different approach: The Self-Organizing Team. The difference is apparent from the first steps the Team takes. In Scrum, the Team decides how much work to commit to in a Sprint. Experience has shown that when Teams themselves decide how much to commit to – and when this commitment is realistic and achievable – the Team’s focus, motivation, and drive is significantly higher, and they produce better results. When managers first learn of this practice, they often voice the concern, "What if the Team under-commits?" This is typically not a problem, since the process of deciding the commitment is very transparent and open. Indeed, it’s much more common in the early Sprints for Teams to significantly over-commit; most Teams have very little experience doing their own estimation, and it takes a number of Sprints before their optimism is tempered by experience. Moreover, in the event the Team does wind up under-committing, they will either finish the Sprint early, or they will start work on the next item on the Product Backlog. No harm, no foul.

Team Tango had just completed their first Sprint Planning Meeting, for a two-week Sprint. They brought in their manager, Jason, and walked him through the work they'd decided to commit to in the Sprint.
Finally, they asked Jason, "Is this a good amount to commit to?"
Jason turned the question around to the Team:

"Do you truly believe you can finish this work, at a high level of quality, by the end of the Sprint? Do you really feel committed?"

The Team members all nodded to him, looking quite convinced.

"Then it's a good amount to commit to," Jason replied. "And if it turns out to be too much or too little, you'll know two weeks from now, and you'll have learned something about how much you should commit to in the following Sprint".

The next aspect of self-organization happens during the Sprint, when the Team works together closely to decide who will perform which tasks and to make sure all the work is completed. When the Team is responsible for this decision-making, they remain focused on the fact that they own the commitment – and if the commitment is to be completed, they are the ones who must do it. When someone outside the Team is responsible for deciding what needs to be done and by whom – for example, a manager – the Team receives a subtle but real signal that they are not responsible: it’s the manager’s job to worry about how to meet the commitment, not the Team’s. This does not mean that managers are not providing support during the Sprint – on the contrary – but managers are careful not to send any signal to the Team that would reduce their sense of ownership of the goal, or responsibility for managing themselves during the Sprint.

On the first day of their first Sprint, the Team called their manager Sanjay over to join them for their Daily Scrum Meeting. Sanjay, wanting to be helpful, agreed to the request. He stood just outside the circle as the Team gave their reports to each other. Sanjay noticed that people seemed to be emphasizing how much they got done the day before, and weren't spending very much time reporting the blocks they were hitting. And after each person gave their short report, they looked over to Sanjay expectantly, hoping to catch a glance of approval. By the end of the Daily Scrum, Sanjay noticed that the entire circle of people had shifted, so they were now facing him.

After the last report was given, a Team member raised his hand, and asked "Sanjay, do you have any feedback or guidance for us?"

Sanjay knew that he had to take action.

"Guys, I'm really concerned. I feel like this meeting was for my benefit. I feel like you‟re still looking to me to make sure everyone's doing the right thing. Here's the deal: I'll give you any help you need, at any point in the Sprint. If you hit a block and you're not able to resolve it, I'm here to provide any assistance I can. But at the end of the day, you are responsible for doing what's necessary to meet the commitment you've made. So from now on, I'm not going to join this meeting. This is your meeting, to manage yourselves, to meet your commitment. If I'm here, I'm afraid I'm just going to undermine that."

The Team was silent. Then Victor, a Team-member, spoke up.

"So let me get this straight. We are the ones responsible here? We really do own this…?"

A subtle jolt of realization passed through the Team, and at that moment, they took their first step towards truly becoming a self-organizing Team.

One of the biggest challenges in successfully making the transition to self-organization is that the Team will not begin to self-organize until everyone outside the Team stops micromanaging them. Teams are so conditioned to follow orders that they will often not begin to self-organize until there are no orders available to follow. This requires a leap of faith for the manager, and it can be scary. This is not to say that the manager abandons their Team – rather, the manager needs to change their style of interaction, and constantly signal to the Team that they are now the ones responsible.

Eileen was an Engineering Manager at RedAlpha Systems, working with a Team of seven relatively junior developers. During the first Sprint Planning Meeting, she sat at the back of the room working on e-mail, as the Team completed the task breakdown for a big feature at the top of the Product Backlog.

When they finished, they turned to Eileen and said "How does this look to you?"

Eileen could see immediately that the Team had overlooked several important database tasks. It would be very simple for her to simply point out the tasks they’d overlooked, and the problem would be solved. Or would it?

Eileen decided to try a different approach. She stood up and announced, "Guys, you've done a pretty good job, but you're not quite done. There are a couple important tasks that you've overlooked. I'm not going to tell you what they are. But I will give you a hint: think more carefully about the user session data. Now I'm going to go and grab a cup of coffee, and I'll be back in about 5 minutes. See if you can figure it out before I get back."

And at that, Eileen strode out of the room.

The Team looked at each other, slightly bewildered. Eileen had always been quick to point out what they'd missed; they depended on her for that. But this time, she was making them figure it out. They stood in silence for a moment at the whiteboard, then slowly discussion began. They went through task by task, looking at each from different angles. Then, after a few minutes of discussion, Tony spoke up.

"Wait a minute… where are we going to store the user session data? We‟re going to have to set up a new table in the database for that, right?" There was a round of forehead slaps from the other Team-members.

"Of course! How did we miss that!" several people murmured. There was a chuckle of embarrassment, and Sam started writing yellow Post-It Notes for each of these new tasks and putting them on the white-board. A few minutes later, Eileen returned with her cup of coffee. She looked at the white board, and nodded in agreement.

"Good job, guys. Now why don't you all continue with your meeting, I've got a bunch more e-mails I need to get through."

Eileen sat back at the end of the table, satisfied that she'd done her job well.

In this example, it would have been faster and easier for Eileen simply to tell the Team what to do. But had she done that, she would have encouraged them to wait for solutions from her, and not think for themselves. Instead, Eileen did something harder, but ultimately much more valuable: she placed the responsibility on the shoulders of the Team to figure out what they had forgotten, and provided just enough help to enable them to get it done. Had Eileen returned to find the Team still struggling, she could have provided another hint or asked another probing question, and continued to do so until the Team finally figured out the missing tasks. Eileen could even have let the Team proceed, and discover their oversight during the Sprint; mistakes often produce the most powerful learning experiences.

In simplest terms, the manager in Scrum is less of a "nanny" for the Team and more of a mentor or "guru," helping them learn, grow and perform. This is the shift from "Manager 1.0" to "Manager 2.0."

In order for managers to be effective in this new mode, the organization must redefine the role and expectations of the manager. For example, in Scrum, the Team is responsible for completing their commitment in the Sprint, and for this to work, it must be clear to all that the manager is not responsible for this. Similarly, in Scrum, it is the Product Owner’s responsibility to deliver the release on schedule, not the responsibility of engineering management, and the organization needs to make clear to everyone that this is the case. Problems occur when the organization “talks the talk” on the new role of the manager, but does not “walk the walk” when things get difficult.

The Galaxy Team had been doing Scrum for several months, and the Team was well on its way to being truly self-organizing. Their motivation was high, they were focused, and after a few Sprints of under-delivery, they were now showing a pattern of making reasonable commitments and delivering those 100% each Sprint. Morale was high, and there was a real sense of “flow” in the work they were doing. The engineering manager Francis had come a long way – once a habitual micromanager, he was now acting like much more of a mentor and coach for the Team. Unfortunately, though, in the eighth Sprint, the Team encountered some unexpected difficulties, and about halfway through the Sprint, they were significantly behind in their progress. The VP of the group, Simon, had ventured into the Team’s work area to see their Sprint Burndown Chart, and called Francis to his office.

"Francis, it looks like this Sprint is a disaster. What’s going on?" he asked.

Francis responded, "Well, the Team hit some bumps along the way, and they're trying hard to get everything done that they committed to, but it's a bit touch-and-go right now."

Simon grimaced.

"Francis, this project is critical, and we can't let it fall behind. I'm counting on you to make sure the Team finishes what they commit to, this Sprint and every Sprint. As a manager, your job is to make sure the Team gets it done; if things are going well, then you can back off a bit, but the minute the going gets tough, I want you in there making sure that no time is being wasted, and everyone is doing exactly what needs to be done."

Francis was exasperated. Simon had been too busy to attend the in-house Scrum trainings, but Francis had emailed him a PowerPoint presentation about self-organizing Teams and the new role of the manager, and Simon hadn't voiced any disagreement. Francis spoke up:

"But what about the self-organizing Team, Simon? What about our shift away from micromanagement?"

There was a glimmer of recognition, as Simon recalled a PowerPoint he'd seen a few months before.
"Yes, the Team is responsible, but when they start to fail, I hold you responsible. We want maximum accountability, so I'm holding them accountable and I'm holding you accountable. In our department, everyone is accountable! Now make it happen."

At that, Simon spun his chair around and started typing. Francis took the hint and left the office.

The next day, Francis showed up at the Daily Scrum Meeting.

"Guys, we're going to do a different format for the meeting today. Due to the criticality of this project, Simon has instructed me to more actively… uhhh…, facilitate' your self-organization during the Sprint. So what I'd like to do this morning is get a status update on each of the features you've committed to – whose done what so far, and what's left to be done – and I'm going to be giving some more detailed feedback so hopefully we can get everything 100% finished by the end of next week."

The Team looked at each other. Philip, the ScrumMaster of the Team, spoke up. "Francis… uhhh… does this mean that the Team is no longer responsible for managing itself?"

Several Team members nodded in agreement.

Francis replied, "Guys, we're all responsible. You're responsible for managing yourselves, and I'm responsible for making sure you get everything done. We're all responsible together!" Francis didn't see the eyeballs subtly roll.
As the Sprint proceeded, Francis was more and more involved. The Daily Scrum became an update meeting for the Team to tell Francis what they'd been able to complete, and for him to assign them the next day's tasks. The mood of the Team shifted; motivation seemed to go down, and Team members seemed to be reverting to their previous role, what they used to sarcastically call "servants-of-Francis-the-Great." By the end of the Sprint, the Team was fully back into "order-following" mode, and Francis was directing their efforts task-by-task.

At the Sprint Review, the Team was surprised when Simon joined the meeting just as it was starting.
"So…" Simon announced, "Did we get our commitment done?"

The Team looked at each other. Francis answered.
"Simon, unfortunately there are a couple backlog items that weren‟t finished." There was a flash of anger in Simon's eyes.

"How did this happen? Who is responsible for this?" The Team was silent, but their heads all turned slowly to Francis.
Simon continued. "Francis, I told you to get it done. Next Sprint, I don't want to see this happen again. If it does, there will be hell to pay…"

Upon hearing this, everyone on the Team made a mental note to think very carefully about just how much to commit to in the next Sprint. The last thing they wanted was to get shouted at again two weeks from now.
As the Sprints passed, Francis became more and more involved in directing the Team at every stage of their work. Gone was any semblance of self-organization, and with it disappeared the improved motivation, drive, and focus that the Team had started to display. Morale had plummeted, and so too had productivity. Lunch breaks were getting longer, coffee-breaks more frequent, and Francis felt like he was spending more and more of his time just making sure people were at their desks working. Those amazing few Sprints, when the Team was truly self-organizing, and performing at the level they were really capable of, were becoming more and more of a distant memory. The return to micromanagement was made all the worse because they'd had a taste of the self-organization "good life."

here were errors of judgment at every step of this situation. The ScrumMaster didn’t protect the Team from Francis’s micromanagement, or call Francis on the "double-talk." Francis didn’t make any effort to reason with Simon, or help him see the consequences of his actions. But perhaps the biggest mistake was an early mistake: Simon was never properly educated about the shift in the management model that Scrum requires to be successful, and how this applies not only in good times but also when the going gets tough; and this shift was never made "official" in the form of a change to Francis’s job description. And as a result, a successful, high-performance Scrum Team rapidly deteriorated back to its previous under-performing state.

The above scenario is extremely common and is a frequent point of failure for Scrum transitions. Furthermore, in an organization where this scenario plays out, word spreads very quickly, often causing other managers to proactively return to micro-management as a self-protective measure.

So how does one prevent this kind of failure from occurring?

First, one has to make a clear-eyed assessment of management’s willingness and ability to change, at every level. If there exists a fundamental belief in the effectiveness of the "command and control" approach within the management and executive ranks, and a heavy dependence on intimidation, threats, or punishment (such as shaming or humiliation) as a management tool, it is going to be particularly difficult to make the transition to a new way of thinking. As a result, an adoption of Scrum risks being incomplete and dysfunctional, producing little if any improvement for the organization.

However, if there is an openness to change, and a recognition that the existing command and control habits may possibly not be the most effective approach, then there needs to be education and coaching at every level of management; in practice, this means high-quality Scrum training for all managers, from the lowest functional manager all the way up to the senior (VP-level and above) members of the organization.

The final necessary step for completing this redefinition of the role of the manager is to “make it official” within the organization. One option is to use the pre-written job description included below as guide. The other option is to complete the interactive exercise that follows with managers in the organization, to break down their existing job descriptions and rebuild them to be compatible with Scrum values and practices. With either of these approaches, it is critical to get formal approval of the manager’s new job description from his or her manager (for example, the Engineering Director, or department head). Without a clear, "official" approval from senior management, the manager’s new role will be more difficult to protect when difficulties arise.

THE MANAGER AS SCRUMMASTER

Another approach to redefining the role of the manager is to convert them into the ScrumMaster for their Team. This has a poor track record of success. When the manager plays the role of ScrumMaster, it’s highly unlikely the Team will ever begin to self-organize. The previous habits of "order-giver" and "order-follower" are very difficult to break, and what will likely happen instead is that pre-existing command-and-control values and patterns will be transplanted into the heart of the Scrum practices. As a result, the benefits that flow from a self-organizing Team – ownership, focus, drive, pride in quality, improved morale, and better productivity –will likely not be realized. It would be better in most cases to have a Team-member play the role of ScrumMaster, even if they must do this in parallel with development responsibilities.

HANDS-ON: REDEFINING THE MANAGER’S ROLE

People needed: Manager, Exercise Facilitator

Step 1. Ask the manager to write down all of their current job responsibilities on Post-It Notes. The manager should try to be as comprehensive and complete as possible, including both official and unofficial responsibilities and things they should be doing but haven’t had time to do. Most managers should be able to come up with at least 20-25 items. Here’s a sample list:

Step 2. Draw two columns on the whiteboard: "Fine in Scrum" and "Conflicts with Scrum / Not Needed in Scrum." Ask the manager to go through the Post-It notes one by one, and place them in one column or the other.

Step 3. Take all the items in the “Fine in Scrum” column, and turn them into a new job description for the manager. (Getting help from HR may be useful at this stage.)

Step 4. Ask the manager, "Will you be more useful or less useful to the organization in this new role?" and “Will this role be more interesting or less interesting for you to do?" In most cases, the immediate response will be "more useful" and "more interesting."

Step 5. Get formal approval of the manager’s new job description from his or her manager (for example, the Engineering Director, or department head). This is a critically important final step. Without formal agreement, the manager’s new role will not be considered "official," and there will be an even greater risk of falling back into prior patterns of micromanagement and command and control.

EXPLANATION

Fine in Scrum

1. Help remove blocks that the Team is not able to resolve by themselves While the ScrumMaster does this hour-to-hour / day-to-day, managers will need to focus on removing more systemic or companywide blocks. These are often the most vexing problems in the organization, and will require the management’s influence, authority, or spending power to overcome. In The Enterprise and Scrum, Ken Schwaber recommends creating an enterprise transition team of managers and executives who are responsible for evolving the organization based on a backlog of impediments.

2. Provide advice and input to the Team on technical difficulties that come up Managers should be available to give advice or assistance whenever the Team asks for it.

3. Do regular 1:1 meetings with Team-members, to provide coaching and mentoring. Managers should spend 1:1 time with Team-members, at a frequency that feels right. This is not a task update meeting – this is time for coaching and mentorship. Some managers like to do this sitting side-by-side, writing code!

4. Give input on how to make features better.
This input goes directly to the Product Owner, typically during the Sprint Review.

5. Stay abreast of developments in tools, technologies, and techniques the Team is using.
A very important and often neglected activity. Managers are can sometimes be "frozen in time" at the technology and development practices that were current when they were last doing actual development themselves.

6. Plan training and other skills development for Team-members.
Managers should think carefully about areas where the Team’s skills could use development, or capabilities the Team will need to have to handle upcoming Product Backlog items.

7. Stay up to date on industry news and developments.
Again, an important and often neglected activity.

8. Anticipate tools, skills and other future needs.
Another important and often neglected activity. Be sure to get input from the Team.

9. Plan and manage budgets and financials.
Another important and often neglected activity. Be sure to get input from the Team.

10. Give input on what features / functionality the Team should build.
This input goes directly to the Product Owner.

11. Do performance evaluations and provide feedback to Team-members.
This is a necessity within most organizations (despite well-documented flaws in the methodologies typically used). Managers should base their evaluations on their own observations and well as on feedback from the employees’ fellow Team-members.

12. Do career-development and career planning with Team-members Career.
opportunities are one of the most significant valuable forms of compensation people receive from their employer.

13. Recruit, interview and hire new Team-members.
Some of the best – and in other cases, worst – management actions are hiring decisions. Great hires pay dividends every single day they are employed – and poor hires are an invisible daily “tax” on the Team’s ability to deliver business value.

14. Remove Team-members who are not able to perform well within the Team.
If even after extensive coaching a Team-member is not able to contribute, work harmoniously with other Team-members, or perform at the level required, they may need to be moved off the Team, or out of the organization. Typically managers will need to guide this process, in coordination with HR.

Conflicts with Scrum or Not Needed in Scrum

15. Decide what work needs to be done.
The Product Owner decides the features and functionality that needs to be built, and the Team determines what tasks are necessary to deliver this.

16. Assign the work to Team members.
The Team does this itself, during the Sprint.

17. Keep track of what everyone on the Team is doing
The Team does this, using the Daily Scrum Meeting and the Sprint Backlog.

18. Make sure the Team gets their work done.
The Team is responsible for this.

19. Make commitments to management about how much Team can do by a certain date.
The Product Owner measures or estimates the Team’s velocity, and makes forecasts of how much of the Product Backlog the Team can complete by a specified date. If the Product Owner makes a hard-date release commitment, the Product Owner is responsible for including the necessary scope and schedule buffer to achieve it.

20. Be responsible for the Team meeting the commitments I’ve made to management.
The Product Owner is responsible for making decisions about what to do if velocity is lower than anticipated – either moving the release date, removing Product Backlog items, or simplifying Product Backlog items.

21. Do weekly status update report for management.
Not needed in Scrum. If management wants to know how the project is going, they ask the Product Owner for the Release Burndown chart.

22. Do weekly Team staff meeting.
Not needed in Scrum. The Team updates each other daily, and managers can get an update on the Sprint in the Sprint Review Meeting.

HANDS-ON: SAMPLE JOB DESCRIPTION FOR MANAGER

• Lead the recruitment and hiring of new Team-members (with the active involvement and input of the existing Team-members)
• Provide input to the Product Owner on the product strategy and vision, and give feedback to the Product Owner on the content and prioritization of the Product Backlog.
• Provide support and assistance to Teams and their ScrumMasters. Be prompt and proactive in helping remove impediments that are harming Teams’ ability to be effective.
• Actively support ScrumMasters’ efforts to protect Teams from disturbance, disruption, or outside interference.
• Be available to provide advice and assistance to Teams on technical difficulties that arise in the course of doing their work.
• Identify issues to Teams that they might overlook, such as scalability, performance, security, etc.
• Provide mentorship and career development advice and guidance to Team-members. This mentorship should include technical mentorship, as well as soft-skills and other aspects of being effective and successful in a development organization.
• Plan and manage skills development and training for Team-members. Think carefully about areas where their skills need greatest development, or where the most opportunity for improvement exists; work with the person to identify appropriate training; and obtain budget and time allowance to complete it.
• Stay abreast of developments in the tools and technologies that Teams are using. Solicit input from Teams and other stakeholders on tools and technologies that could be useful. Spend time getting hands-on familiarity with these tools and technologies.
• Stay up to date on industry news. Be knowledgeable about developments from our company, our competitors, and our largest customers, including financial performance, marketshare, product roadmap, and overall business strategy.
• Remove Team-members that are not able to perform well within a given Team, work effectively with their fellow Team-members, or perform work at the level of expertise or quality required. This should come only after coaching and training has failed to correct the under-performance.
• Do financial planning and budgeting for Teams, including anticipating future people requirements, skills development and training needs, tools and technologies required, hardware, travel, and any other resources that people will require.
• Provide performance feedback and complete performance evaluations for Team-members. Informal performance feedback should be provided on a frequent basis, and should include feedback from fellow Team-members. Feedback should be focused on recognition for achievement, and opportunities for growth.

Cargo Cult Agile

By Manoj Vadakkan

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

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

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

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

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

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

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

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

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

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

Notes

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

Daily Scrum: Merely a status report?

By Vinay Krishna

Introduction

One of the important, key Scrum practices is the Daily Scrum. It happens daily during each Sprint and the entire team participates.

During this Daily Scrum everyone answers the following three questions:

1. What’s been accomplished since the last meeting?
2. What’s going to be done before the next meeting?
3. What obstacles are in the way?

Often people treat it as a typical status meeting and behave very casually, which eventually could lead to bad results.

This is not a mere status update meeting where one person (Project Manager or team lead) collects information about who is behind schedule. Rather, it is a meeting in which every team member makes commitments to each other. This has the wonderful effect of helping all team members realize the significance of these commitments and that their commitments are to each other. The meeting is not used for problem-solving or issue resolution. Issues that are raised are discussed offline and usually dealt with by the relevant sub-group immediately after the meeting. The Daily Scrum should not take more than 15 minutes.

It requires that team members are disciplined and do not discuss impediments in detail during this meeting, only ensure others are informed. If needed, they can discuss it with concerned team members separately.

Significance

One question may arise here, why are only these three questions important and not discussion about what’s new?

High visibility of progress

It’s a place where each day, team members can see the progress of a project and easily see their contributions.

Improve estimation

By focusing on what a team member accomplished yesterday, the team member gains an excellent understanding of flaws in his estimates. Gradually, it improves his estimation skill.

Self-organization

Team members select their daily tasks and they are responsible for deciding the requirements for the Sprint. This helps them to understand their daily responsibilities. Thus, it aids team self-organization, and slowly team members gain the maturity necessary to commit to something appropriately or to handle impediments efficiently.

Increase the quality

Daily communication helps to refactor the work as well as improve the turnaround time required to remove impediments. It builds knowledge and helps to quickly apply and reuse the knowledge.

Common Problems

Below are common problems that negatively affect the Daily Scrum:

Lack of a clear understanding of Scrum practices

If the team doesn’t have a clear understanding of Scrum practices, then the Daily Scrum takes the wrong shape and also takes much more time to complete. Very soon the team loses the positive effect of a Daily Scrum, it eventually becomes a status update meeting, and people change its frequency from daily to weekly.

Old mindset/habit

It’s very common hurdle. A lot of people answer these questions like they were providing their status to the PM or Team Lead and not the ScrumMaster. Sometimes team members only address the ScrumMaster while providing answers during the Daily Scrum, as if they are providing a typical status report. It has also been observed that team members often provide very generic and high-level answers that cover more than one person’s task.

Faced critical problem

This happens when a team member has faced some critical problem that has a direct impact on his current or upcoming tasks. Most of the time people start explaining the problem in great detail, which consumes lots of time.

Communication problem

Sometimes people aren’t able to concisely explain technical stuff. This is another type of communication problem.

Information about barriers shapes the discussion

It’s a common practice to engage in a discussion about barriers if someone is talking about it. That causes the Daily Scrum to change into a discussion, and others slowly become a part of it.

Start requirement/design clarification/discussion

People start clarifying the requirement or start discussing design during the Daily Scrum, because they find it very valid place to start and want to spend more time discussing.

Team is too big

If the team is big then it takes more time to complete the Daily Scrum. In this case people complain that the discussion doesn’t pertain to their tasks and want their turn to speak to come quickly so that they can leave early.

How to handle problems

Below are some ways to handle such scenarios:

Proper team training on Scrum

Plan proper training for team members or provide occasional, small Scrum awareness sessions with the team.

Reiterate the three questions

Reiterate the three questions as many times as possible to remind the team until the team reaches that maturity level.

Avoid a lengthy technical discussion

If someone tries to explain the technical problem or if it's taking the shape of a technical discussion, the ScrumMaster must stop them politely and ask to have this discussion offline. Always focus on the current Sprint Backlog while discussing tasks.

Scrum of Scrums

In the case of a big team, consider a Scrum of Scrums. It is more effective for large or distributed teams.

Conclusion

The Daily Scrum helps to improve the individual’s commitment within the team, and the team’s maturity level and self organization. Eventually it creates a self organized team with positive team vibes.

Remember: The Daily Scrum (daily stand up meeting) must finish in 15 minutes, and everyone must answer the three questions to the team.

Scrum and SVO-P

By Dan Mezick

Scrum is unique in that the management method is consistently direct. All communication in authentic Scrum is concise, direct and clear. Scrum encourages responsibility. The daily stand-up meeting actively encourages personal responsibility to execute on specific work, and to be accountable to the Team. The three questions of Scrum are questions related to accountability for specific commitments.

Each of Scrum's three roles clearly defines responsibility for a set of specific tasks. For example, the Product Owner is required to gather requirements, place them on the Backlog, and prioritize them. The Team is required to pull the topmost N items from the Backlog to load a Sprint, to attend the daily Scrum, and so on. Each role in Scrum takes responsibility for a specific set of tasks. Scrum roles and ceremonies actively encourage responsibility.

Language directly influences thinking and perception. Syntax that is consistently direct encourages responsibility and clear thinking. Indirect forms of syntax can often obscure the subject and encourage the dodging of direct responsibility. Avoiding responsibility is in direct conflict with the Scrum values of Commitment and Focus. Indirect forms of verbal communication are therefore not in alignment with Scrum values. Indirect verbal forms do not support Scrum.

I believe that SVO-p can be very profitably incorporated into the Scrum framework. SVO-p stands for Subject-Verb-Object, Present Tense.

SVO-p is a syntax. It is a style of communication in which you always know who is responsible for an action. SVO-p is an active form that encourages clear thinking and candid, direct communication. SVO-p can help clarify your thinking.

Communicating in SVO-p requires definition of who is acting, what they are doing and to whom. It requires placing the thought in the present; that is, "in the now." Speakers and writers who actively dodge responsibility often choose the past tense and the future tense for expressing thoughts. Politicians, for example, often assign blame to past events, while making promises about the future.

SVO-p brings clarity to communication, and directly affects thinking through the constraint of language syntax.

Examples:

Non SVO-p

"The people who write articles for free are to be congratulated."
This sentence puts the congratulations out in the non-existing future and also hides the identity of the congratulator.

SVO-p

"I congratulate the writers who write articles for free."
This sentence in SVO-p identifies the user and places the action in the now.

Non SVO-p

"I've yet to meet anyone who has given me a straight answer."
This sentence places the action in the future and obscures the object of the sentence. It also places the giving of 'straight answers' in the past.

SVO-p

"People don't give me straight answers."In this SVO-p sentence, 'People' are acting on 'me' in the now, by not giving straight answers.

You may find that speaking in SVO-p is difficult at first. You may also find that the use of the SVO-p syntax can be contagious. When you use it, others often tend to naturally speak back to you in SVO-p.

SVO-p is particularly well suited for use during Scrum communications, because SVO-p is consistent and supports the Scrum values: Commitment, Focus, Openness, Respect, and Courage.

SVO-p discourages "passive voice." Passive forms tend to conceal the subject and avoid responsibility. This is a problem because of a much higher likelihood that the receiver of the message may misunderstand the statement. The use of active voice in the present tense supports immediate action in the present moment. The subject-verb-object form tends to support direct and clearly articulated responsibility.

Responsible action in the present moment is consistent with Scrum values. For example, in daily Scrums it is the responsibility of the ScrumMaster to make immediate decisions in the present rather than deferring decision-making into the non-existent future. Likewise, in Scrum there is an emphasis on learning empirically, in the present, while avoiding making any specific predictions about the future. In this sense, Scrum and SVO-p are a perfect match.

The use of SVO-p by Scrum practitioners actively supports the success of Scrum in the present.

I notice that Ken Schwaber and Mike Beedle, co-authors of the book Agile Software Development with Scrum, write in nearly 100% SVO-p. The entire book except for a small part is written in SVO-p. This makes total sense, because the SVO-p form is consistent with the beliefs, values and behaviors of authentic Scrum. It is therefore no surprise that the original and most experienced practitioners of the art of Scrum use SVO-p as the preferred syntax for communicating the essentials of it. SVO-p is a very natural, nearly automatic fit with Scrum.

When you start experimenting with SVO-p in verbal communications, you find that it is necessary to speak in simple and direct (SVO) terms. You find that speaking in the present tense keeps you in the now, and tends to clarify your thinking. SVO-p strongly supports an empirical approach to work and problem-solving by focusing attention in the present moment, and making perfectly clear who is acting, and upon what.

The use of SVO-p strongly supports the reception of interactive loops of Scrum feedback in the present. This property of SVO-p tends to support the reception of feedback over the development and acceptance of "predictions" regarding the non-existent future. The use of present tense focuses attention "in the now." The simple Subject-Verb-Object syntax is clear and direct. If you are speaking in a future tense, you find it easy to make predictions about the future. If you are speaking in the present tense, you find it easier to pay attention to what is happening now. This supports the essence of Scrum: empiricism, or "learning by observation."

SVO-p maximizes focus on the present, at the expense of the past and future. Scrum methods identify, acknowledge, and directly confront the reality of complex software development. The use of SVO-p in Scrum, therefore, might not be optional. SVO-p is the best syntax available for communicating very directly in English. I wonder if one of the foul "Scrum Smells" is the avoidance of SVO-p syntax when communicating about current Scrum projects.

It is my belief that if you are really a candidate for a role in an authentic Scrum project, then you are ready for implementing your communications in SVO-p. Give it a try. If it feels uncomfortable, the discomfort may be about the difficulty of making fuzzy, indirect statements in SVO-p. You cannot easily make such statements in the SVO-p syntax. SVO-p identifies the subject, makes the action clear, and assigns responsibility for the action in the present moment. The directness of SVO-p is the greatest strength of the form. SVO-p supports the Scrum value of Openness by strongly encouraging clarity in each and every sentence.

Scrum and SVO-p confront reality, identify the subject, and assign responsibility. Scrum depends on interactive feedback in the present, and SVO-p supports that interactive feedback by focusing attention on the present moment.

I welcome your feedback about the use of SVO-p in actual Scrum practice. I am eager to learn about your experiences implementing SVO-p in Scrum. Please give it a try, and be sure to email me your feedback on SVO-p.