Common Product Owner Traps

By Roman Pichler

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

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

The Product Owner in Scrum

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

Continue reading this article.

Ask the Coach

By Manoj Vadakkan

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

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

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

Continue reading this article

Scrum Success in a Distributed Team Environment

By Feyza O’Connell

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

About Scrum

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

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

Why Are More Organizations Embracing Scrum?

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

Continue reading this article

How I Stole an Office and Fixed Our Daily Scrum

By Aaron Conoly

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

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

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

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

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

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

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

This article was reproduced from www.scrumalliance.org

How to Sustain Adaptive Planning

By Rahul Sawhney

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

We will examine the following factors:

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

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

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

Possible response #1:

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

Possible response #2:

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

Possible response #3:

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

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

Making Adaptive planning work

- Just-enough planning

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

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

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

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

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

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

- Grooming the scope

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

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

- Trust, involvement and collaboration

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

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

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

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

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

- Management support

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

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

Conclusion

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

Why Go Agile—Why Should I Embrace Change?

By Bachan Anand

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Can Scrum Support Six Sigma?

By Heitor Roriz Filho

INTRODUCTION

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

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

SIX SIGMA ASPECTS OVERVIEW

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

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

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

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

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

SIX SIGMA ROLES AND METHOD

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

THE SCRUM ROLES

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

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

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

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

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

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

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

BLENDING SCRUM INTO DMAIC

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

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

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

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

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

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

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

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

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

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

CRITICAL ASPECTS TO CONSIDER

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

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

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

REFERENCES

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

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

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

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

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

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

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

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

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

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

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

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

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

[14] COHN, M. User Stories Applied.

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

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

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

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

What does a ScrumMaster do?

By Dr. German Sakaryan

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

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

The priority of activities varies by company.

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

Hints for management:

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

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

Power of the Post-it

By Aaron Conoly

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Transitioning to Scrum: Selecting the Product Owner

By John Clifford

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

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

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

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

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

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

Scrummertime and the livin' is easy

By Marko Majki

I have prejudices.

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

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

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

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

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

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

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

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

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

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

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

Wake up; there's no EASY way.

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

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

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

Ba and Knowledge Creation in Scrum

By Heitor Roriz Filh

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

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

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

SECI Model and Knowledge Creation

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

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

The Four Types of Ba

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

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

Scrum and the SECI Model

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

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

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

Summary

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

References

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

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

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

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

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

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

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

Three Things I Wish I Knew Before Jumping

By Pat Guariglia

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

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

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

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

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

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

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

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

Select a Project with Medium Criticality

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

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

Continuously Communicate Your Chosen Methodology

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

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

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

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

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

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

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

Demystify the Voodoo

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

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

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

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

Wrapping Up

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

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

Attraction and Repulsion: Scrum’s Immune System, Up Close

By Dan Mezick

The popular book The Secret tells a story about the so-called "law of attraction." An equal and opposite force, the flip side of attraction, is the law of repulsion. Scrum is attractive to some and repulsive to others. Am I saying Scrum is repulsive? Yes...

Dr. Jeff Sutherland often refers to Scrum’s "immune system" in which people that are unproductive or wasteful are strongly encouraged to reform their behavior, or exit the team. You can examine such a post from Dr. Sutherland here:

Link 1: Dr. Sutherland on Scrum's "immune" system
http://jeffsutherland.com/scrum/2004/05/scrum-pigs-and-chickens.html

One thing I notice and pay attention to a lot lately is attraction and repulsion. This is a common, universal theme throughout the physical world. At the micro level, single cell organisms are repelled by toxins and attracted to nutrients. At the macro level, planets and solar systems are held together through the opposing forces of attraction and repulsion. You can learn more about that here:

Link 2: Attraction and Repulsion as a valid model of how the world works
http://committeeofpublicsafety.wordpress.com/2009/03/28/attraction-and-repulsion/

Scrum sets up a space that is mostly psychological in nature. One of the authors that strongly influenced the formation of Scrum is Ikujiro Nonaka, who co-authored the influential paper, "The New Product Development Game." He later co-authored another paper about creating and influencing the psychological space for work, which he calls the "ba." It’s an interesting concept described here:

Link 3: The Concept of Ba
http://home.business.utah.edu/actme/7410/Nonaka%201998.pdf

One aspect of this "space" is: what it is actually attracting, and what it is actually repulsing.

In Scrum we value clearly defined goals, learning by inspection, and attention to the goals. In Scrum we do not value ill-defined objectives, predictions, or distractions. Scrum is attractive to people who value what Scrum encourages. Scrum is repulsive to people who value what Scrum discourages.

So here we see the dynamic of how what is attracted defines what is repulsed, and vice versa.

This applies to everything, not just Scrum. Scrum places value on focus and attention, so it repels "lack of focus" and distractions.

If we attract clear thinking, we repulse fuzzy, unclear thinking. If we value learning by observation, we repel the propensity to predict.

Summary

Here we see how Scrum is at once simple and polarizing. Scrum’s simple set of rules creates an environment or space or "ba" with properties of attraction and repulsion. The repulsion aspect forms the basis of a kind of immune system for Scrum. In Scrum, via the held values, the cultural aspects of specific attraction and repulsion emerge. Attractive behaviors (focusing attention, sincere effort, and learning) are honored, while repulsive behaviors (lack of attention, laziness, not learning) are dishonored. This is attraction and repulsion.

The end result is a self-governing, self-correcting system, based on a simple, short set of rules. That "system" or "space" created by authentic Scrum is constantly integrating what is valued and attractive, and expelling and purging what is not valued and therefore repulsive.

Is Scrum repulsive? Yes. Is Scrum attractive? Yes.

This is one aspect of the essential beauty of Scrum.

Requirement analysis and Design flow in Scrum

By Yi Lv

When do requirement analysis and design activities happen in the Scrum framework? How is our understanding of requirement and design analysis valuable in the Scrum framework? This article describes how these elements flow through Sprints within the Scrum framework.

Requirement analysis is one of the major activities in backlog grooming (the others are estimating and splitting). Once the Product Owner gets an idea by working with customers and adds one vague item into Product Backlog, the item will be groomed for the first time. Considering priority, this item and other smaller items are groomed through several rounds while the Team gets ready for Sprint Planning. The clarity of the items advances in each round of grooming. Acceptance criteria may be drafted in the grooming rounds before Sprint Planning. In the first part of the Sprint Planning Meeting, the requirement analysis continues. If you are able to continuously groom properly, the requirements will be well understood by that time. However, since items are selected in the Sprint Planning Meeting, only then is the Team sure that they are working on them. The Team normally identifies further points (e.g. exact scope, sad path scenario) to be clarified. This may be conducted by working out more details in the acceptance tests. The requirement analysis activity does not stop in the first part of the Sprint Planning Meeting, but continues in the second part and during the actual Sprint. In the second part of the Sprint Planning Meeting, while you are decomposing tasks, the ambiguity in requirement may surface again and be clarified. During the Sprint, test case design, modeling workshop, requirement discussion while designing and coding, and discovery from exploratory testing all contain some element of requirement analysis. Even in the Sprint Review, you will see requirement analysis activity through feedback and suggestion for improvement (new items).

When do we start design? Traditionally, we start design to move from problem domain to solution domain immediately once we get big Product Backlog items. This early move reduces the flexibility in terms of prioritization, which is not recommended in Agile development. We continue to work in the problem domain by keeping the customer orientation as much as possible while splitting the items. The splitting in the problem domain happens in backlog grooming. We also estimate the size of items in backlog grooming. Sometimes, you will have difficulty in estimating the item size, which may be caused by either vague requirements or a lack of experience. If the requirements are vague, requirement analysis in further rounds of grooming helps. If the solution is unknown, architecture or a design spike item can be added in the Product Backlog. This item is normally time-boxed, and its done criteria differ from those of normal backlog items. The output is the sufficient understanding to enable your estimating and planning. In the context of multiple teams working on the same code base, a joint design workshop may be conducted to synchronize the design across teams. In the second part of the Sprint Planning Meeting, the Team commits how much to do in the coming Sprint. In order to make the commitment, the Team normally makes the detailed plan by decomposing items into tasks and estimating those tasks. The commitment may be made based on velocity, but the Team may still think of tasks necessary for them to get the committed items done. How do you determine the tasks? You design. In the second part of Spring Planning, some teams jump into the task decomposition, and get a similar list of tasks such as design, coding, unit testing, review, and functional testing. This indicates a lack of design. How much design do we do in the Sprint Planning Meeting? It needs to be sufficient to support planning. The purpose of Sprint Planning is not design, even though there is a design element in the planning meeting. Besides, the planning meeting is constrained by a time-box, so the Team must find a way to make the best of the time. Design continues in the Sprint. The Team may organize a design workshop, or have an ad-hoc modeling discussion while coding, and coding itself is design. Our design is considered done when the item is done.

In conclusion, you can see the value of requirement understanding and design in the following Scrum activities (major ones in bold).

Requirement: backlog grooming (several rounds) -> Sprint Planning part 1 -> Sprint Planning part 2 -> Sprint -> done -> sprint review

Design: backlog grooming -> spike item (when necessary) -> Sprint Planning part 2 -> Sprint -> done

This flow allows for requirement analysis and design within the Scrum framework.