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.