Are We There Yet?

By Aaron Ruhnow

I am the technical lead (and now also ScrumMaster) on a development team that spent most of 2006 implementing various agile practices into our daily routine. We had traditionally followed a waterfall process, so it was a little difficult at first to get the team members (and management) to digest some of the new agile methods (Two- week iterations? Developers writing tests? No Gantt charts?)—we truly were stepping through the looking glass.

With all these new practices came a lot of uncertainty. We had new tools—new to us, at least—such as FitNesse and nUnit. We had new practices, including pattern-based design, TDD, and automated builds. We had new processes and even had a strange, new rhythm. Many of us were used to being assigned a set of tasks and then spending weeks writing requirements. Some time later we would code them. (We may or may not have been involved in estimating how long these tasks would take to complete.) Making the shift to short iterations was quite a change. Having the developers themselves write up and estimate the tasks in one half- to two-day increments was also a shift, but was a bit easier to digest because the developers quickly found they could make more accurate estimates this way. It often was difficult to focus on the essentials in the midst of all of this newness.

To gain this focus, the team started to use a task board and task cards to track progress within each iteration. However, we often struggled to understand when a task, and then a story, was really done. We had learned of the “done, done, done” mantra (coded, tested, approved by the product owner), but that wasn’t specific enough for us. We needed more guidance to know when we were actually there. For instance, in our daily standups, a typical discussion would go something like this:

Dev 1: “I finished coding the ‘Copy’ function for the story.”

Dev 2: “Did you unit test it?”

Dev 1: “Uh…I think I wrote a few.”

Dev 3: “Are the Fit tests done?”

Dev 1: “Oh yeah, I forgot about Fit.”

We needed a better definition—one we could all agree on and understand.

About that time, I attended a Certified ScrumMaster class. During the class, another student mentioned that her team had a list of criteria defining done. Intrigued, I asked if she could email it to me. She told me they didn’t have it written down; it was just understood within the team. (Guess they were already in “Done Nirvana.”) After some more prodding, she did agree to write them down just for me. From her list we created the first draft of our form of done:

A story is complete when:

1. Coded/implemented
2. Peer reviewed (pair programming counts as peer review)
3. Code is run against current version in source control
4. Code is commented in source control and checked in
5. Code is commented with VB Commenter on Public/Friend methods
6. Story/use case manual test plan updated
7. Fit test written (with help of SQA person)
8. UML diagram updated
9. Unit tests written and passing
10. 90 percent code coverage achieved
11. Build and package changes are communicated to build master (i.e. introducing a new file or something)
12. Task list hours are updated and task is closed out
13. All to-do items in code are completed

We changed her list somewhat to emphasize several coding qualities that needed reinforcement within our team. During iteration planning and task generation, we now make separate task cards for steps like writing unit tests (before coding, of course), making Fit tests, and so on.

The list is still posted in our project room, but I guess we, too, have now reached “Done Nirvana” because the definition of done is now in our heads and for the most part put into individual task cards. The list now makes good wallpaper—and serves the role of looking good for managers that happen to enter our project room. I suppose it may also be helpful for newbies.

Maybe our list, as my fellow student’s did, can start your team down the path to “Done Nirvana.” But for now, this story is done.

Prepped for Success

By Roman Pichler

When was the last time you came across a project that was not urgent? I can’t remember my last time. This probably explains why many Scrum projects I have worked with were tempted to kick off the first sprint without having fully thought about the necessary prerequisites. This article discusses the minimum set of preparation activities required to ensure that your Scrum project is set up for success.

Ready …

While you want to minimize your preparation activities to start delivering shippable product increments as quickly as possible, some setup is required. If you skip the steps below to save time, you are likely to experience a lower project velocity overall.

First and foremost, the right people have to be on board and the Scrum roles have to be properly filled. That means that the product owner, the team and the ScrumMaster are available to start working on the project; the team has the right performers on the team to create shippable increments reliably; and everyone involved understands how Scrum works.

Second, the product backlog has to be initially stocked and prioritized. The product backlog should contain at least two to three sprints worth of work. For innovative, critical, or complex projects, the backlog should be as completely stocked as possible. Notice that requirements are described at different levels of granularity in Scrum, which allows the upfront requirements effort to be reduced to a minimum. Holding requirements workshops is a great way to collect requirements and to allow the product owner, team, and end customers to interact.

Third, the development and test environment must be ready. If the environments are not in place, the team cannot create shippable product increments. Remember: Every increment in Scrum must implement a subset of the requirements into software, and must be adequately documented and tested.

Fourth, the team has to know how the requirements stated in the product backlog can be transformed into shippable product increments. For a new product development project, this may entail some organized experimentation, including the creation of prototypes (spikes) and models. If more experimentation is required, the related activities should be carried out within sprints of their own right. (I will say more about applying Scrum on new product development projects in a future column.) A team working on a maintenance project typically has to read the existing documentation and explore the code base.

Steady …

Once the steps above have been completed, four more preparation activities are necessary to have a successful, short and focused sprint planning meeting. Notice that these activities tend to occur before every sprint planning throughout the entire project:

The team estimates the product backlog items. The very first effort estimation workshop is likely to last longer, as participants try to cover as many items as possible. Try to avoid workshops that last longer than four hours, though, since the concentration of the team tends to rapidly deteriorate in my experience. As part of the preparation activities for every sprint planning meeting, the team estimates any new requirements. This allows the product owner to determine whether the requirements are fine-grained enough to be transformed into a product increment within a sprint and understandable for the team or if they need be broken down and worked on further. Additionally, the team gets a preview of what’s ahead.

The product owner identifies a sprint goal and discusses the related product backlog items with the team. Remember that in Scrum, the team members have five percent of their time available to help the product owner refine requirements, discuss acceptance criteria, and estimate new requirements prior to the sprint planning meeting. If you use two-week sprints, this amounts to half a day. Having this discussion prior to the planning meeting avoids unpleasant surprises that can lead to a stressful or even unsuccessful planning meeting. Don’t forget: All meetings are time-boxed in Scrum.

The team determines its availability. This includes identifying the net hours team members have available to work on the project for the upcoming sprint.

The ScrumMaster prepares the meeting. This includes booking a suitable venue to hold the sprint planning meeting and the preparation of facilitation material required. I very much prefer planning meetings away from phones and email in properly set-up meeting rooms and the use of low-tech tools such as index cards for task identification to ensure full participation of everyone involved. Notice that the first sprint planning meeting is likely to take longer, particularly if the team is new to Scrum. Make sure that you guide the team properly and explain the sprint planning steps so everyone is on the same page. And don’t forget to keep the time!

GO!

You have set-up your project for success and you are ready to start the first sprint planning meeting now. Well done. Good luck and enjoy!

Should a ScrumMaster Give Performance Appraisals?

By Esther Derby

A ScrumMaster recently asked me if he should take over responsibility for year-end performance evaluations since he was closer to the work than the functional manager for the team. It’s not the first time I’ve heard this question, and as more companies begin to use Scrum, I’m sure I’ll hear it again.

It does make sense for a ScrumMaster to give feedback. But when it comes to taking over (or participating in) the annual appraisal, ratings, or rankings, my answer is “No. No. No!” There’s a fundamental conflict between coaching to improve effectiveness and evaluating for ratings, rankings, raises, or promotion.

Yearly appraisals, performance reviews, and evaluations emphasize hierarchy and differences in status. ScrumMasters are in service to the team; they don’t manage the team. Creating a higher status position (evaluator) is an impediment to the team self-organizing—and to the team learning how to give each other feedback and manage their own performance.

People who receive high ratings may bask in the glow of affirmation. However, psychologists know that 80 percent of people believe their performance is above average. Statistically that can’t be true; yet, on an emotional level, that is what most people believe. When people receive a lower rating (or an unexpected rating), they focus on the reasons they deserve a better rating. That impedes honest discussion about skills and behavior.

A number or letter rating doesn’t provide sufficient information for a person to know what or how to change. Even when the rating or ranking is followed by a description of specific behaviors, the person on the receiving end is focused on “the number,” (and the reasons they deserve a different number). That’s a barrier to improvement.

When people only have serious conversations about performance once a year (or even once a quarter) it leaves too much time for problems to fester. Why let a problem continue? Why suppress team productivity? When a team member is doing something that’s detrimental to the team, the time to tell him is now. When a team member’s work isn’t what it needs to be, the time to tell him is now. When people receive that information long after the fact they wonder, “Why didn’t he tell me sooner? Doesn’t he want me to succeed?” That erodes trust, and trust is a prerequisite for effective coaching.

Participating in individual rating telegraphs the message: “I say we’re a team, but I don’t really mean it. I’m still looking at individual performance, not team accomplishment.” That undermines the ScrumMaster’s role in improving productivity, helping the team self-organize, and improving the life of the team.

“But,” you may say, “the ScrumMaster is closest to the day-to-day performance of people on the team.”

That’s true. So, by all means give feedback on day-to-day performance and patterns of behavior. Provide clear, specific information about what you observe. Help people understand the impact their behavior and work results have on the team. That’s information that will help team members make choices to continually improve their skills, professionalism, and contribution to the team. By all means, coach people as they learn new skills. Help the team learn to self-organize by holding up a mirror on their processes and challenge them to think and decide on their own.

The ScrumMaster and team members know how each other are performing. When the ScrumMaster and the team are committed to giving each other congruent feedback, there’s no need for a performance evaluation: people know how they are doing and are working to improve every day.

What can you do if, as a ScrumMaster, you are pressured to provide input for a performance review? Explain that you have been giving feedback throughout the year (or quarter). Give examples of how you have provided feedback and seen changes day-to-day (without naming names).

Don’t provide feedback for the manager to pass along, even if it’s feedback you’ve already given to the other person. The manager won’t have the context to provide clarification or answer questions. “Pass along” feedback—especially when it’s new information—creates a tattletale dynamic. The recipient of pass along feedback wonders why the ScrumMaster didn’t give the feedback directly, and that damages relationships. Explain to the manager that everything that needs to be said has already been said directly.

Explain that the work is interdependent, so it’s impossible to pull apart individual contribution. You are focusing on improving the performance of the team and that individual performance evaluation will detract from that focus.

Create a team performance review where the team members discuss how the team is doing and where the team needs to improve. Do this as a face-to-face discussion, not through anonymous comments or ratings (I’ll say more about how to do this in a future column). Provide the team’s own assessment of their performance to the manager. The manager can then choose how to apply that assessment in the mandated performance appraisal process.

Managers believe they must engage in the ritual of annual evaluation—because they’ve always done it. HR may have targets for percentage of reviews completed. Neither has a thing to do with actually improving performance. Individual performance evaluations and annual reviews are an impediment. Steer clear of them—they are a vestige of command and control that Scrum can do without.

Change Agent Dreamin'

By Bob Schatz

When you are driving change in an organization, you often start with a strong vision of where you want to be. The picture that is etched in your mind is very real. It has to be. This is the picture that you will have to paint for everyone impacted by the change that you see. Your ability to describe this picture from the perspective of the people you are dealing with is a special skill. Successfully doing this helps the vision stick. Momentum builds as others join the march. You learn how to communicate this vision in many different mediums so it can be consumed by others. When you’re in an intense period of change this vision consumes your thinking. It is very powerful and energizing.

As you begin to execute changes based on this vision, you experience positive and negative feedback. Some changes turn out exactly as you had imagined, others fail miserably. This feedback loop is critical in helping to mold and shape the changes and the vision for the benefit of the people involved in the change. Much like the iterations we plan and execute for our projects, we assess and reprioritize based on the results we see in execution. At the end of a very long day, we hold a mini-review in our heads, in the quiet of our homes (or the comfort of a few drinks!) where we focus on the mental comparison of the planned change and the daily observed results.

Often this review is not even a conscious activity. Everyone has a typical time or environment when some of their best ideas are born. For me, it’s between the time I fall asleep and finish shaving in the morning. I keep a stack of index cards on my nightstand and, strangely enough, in the medicine cabinet in the bathroom. It seems like when I’m in this zone, my brain is processing all of the input data I’ve received and the readings I’ve completed and comparing it to the vision I’m carrying. What emerge are ideas for changes and adjustments that are in tune with the organization I’m working with.

It’s a very strange feeling, having these ideas appear unbidden in my mind. I write each one down on an index card immediately. Sometimes the writing is difficult to decipher (still learning how to write in complete darkness), but the thought is nonetheless captured. I take my ideas (once I’ve figured out what they were) back to work with me. The next night, I repeat the process again.

I’m not the only one who does this. At Primavera, when we were going through the early periods of intense change, the mornings would be full of more than a few of us running around in the morning trying to communicate what ideas we’d had overnight that we needed to implement to get to the next level. It was extremely entertaining and energizing, but exhausting.

The switch to agile methodologies is a big change for many individuals and organizations, and it carries with it a vision and the inevitable collision of that vision and reality. When applying agile values and principles for the first time, we often have a vision that has been cleansed of all the issues and obstacles. When the obstacles start coming fast and furious, agile methodologies force us to deal with them quickly. There is no way to prepare anyone for the stress that this brings. The experience will be different for everyone. As a visionary leader in an organization, it is my responsibility to help people through that transition. I try to harness their intense energy and commitment and focus it. I guess it’s like being the product owner for the vision.

In a recent consulting engagement I had the opportunity to work with a new ScrumMaster, Casey Hott at NASA in Huntsville, Alabama. Casey was selected to be the ScrumMaster for a Scrum pilot project. Casey was a good candidate because she was new to a project management role and hadn’t had the waterfall illusion of success ingrained in her mind yet. Additionally, the organization had been given Ken Schwaber’s book, Agile Project Management with Scrum, and Casey had a good grasp of the information and the intent; basically, she got it.

After I gave her some coaching on what this experience was going to be from the ScrumMaster perspective, she was eager to begin (maybe she wasn’t listening to the warnings!). As we started the pilot project’s first sprint, Casey began to experience the conflict between her vision and the actual experience. After the first week, as she faced challenges and worked hard to make adjustments, she told us about a dream she had. I thought it exhibited well what new leaders go through in their drive to get things right. Here is Casey’s dream about the apprehension of leading the first sprint review as she describes it:

The first thing I remember is standing in a sea of people at the Von Braun Center in town. I had seats on the floor but it wasn't the front row...which I think is strange because I am the ScrumMaster (I had closer seats at the Paul McCartney concert I attended last year in Atlanta)... Anyway, everybody is in their designated seat and is standing up, I guess because the meeting is about to start. I’m looking around and I’m seeing all these people I graduated with from high school. I didn’t like most of them so that was a bummer. I’m pretty sure my parents were somewhere up in the balcony.

Everyone is talking among themselves, waiting for the meeting to start when all of a sudden, the band starts up. Yes, there was a band at this sprint review. It is no surprise, since I am a HUGE Beatles fan, that the band begins playing Beatles’ songs. The first song (and the only song I remember them playing) was none other than “Help!” The last thing I remember in my dream is joining in with another former high school classmate singing the chorus “Help! I need somebody. Help! Not just anybody. Help! I need someone... HELP!!” I then woke up and realized it was time to get ready for work...another bummer.

Anyone who has been in this role can probably say they’ve had a similar dream. Alone in a sea of people, looking for acceptance, calling out for help.

Shake It Up!

By John Hill

Over the last few years, a number of practices from other agile disciplines have successfully found their way into Scrum. Examples include incorporating Test Driven Development as part of the sprint process, or utilizing User Stories from XP as part of defining requirements under Scrum. This article, however, deals with a variation on vanilla Scrum itself.

Vanilla scrum prescribes a two-part sprint planning session. During the first part of the session, the Product Owner is supposed to meet with the team to explain sprint backlog priorities, as well as to clarify any functional issues. The team is then supposed to retreat (without the Product Owner) to estimate tasks, as well as to “sign-up” for work. By the end of the second step of the planning session, all work is supposed to be estimated and assigned.

When I first began to practice Scrum, we followed this model. During the second part of the planning session, the team determined which team member was best suited for a task and reviewed each person’s capacity based on vacations and holidays. At that point, each individual estimated and signed-up for those tasks most suited to his skill set.

The result was a sprint plan with individuals fully booked on tasks through the sprint end date. We found that this, in effect, significantly diluted the notion of a team being in it together. If one person became a bottleneck and impeded another team member, we began to experience conflicts between specific individuals.

Share

Vanilla Scrum’s two-part planning session was not working for us—something needed to change. So, after several sprints failing in the manner described above, we tried a different approach to sprint planning. Instead of having individuals estimate their own tasks, we encouraged the team to estimate all sprint tasks upfront as a group. Then, team members were encouraged to sign-up for only one or two tasks at a time. This strategy enabled individuals to pull the highest-priority tasks from the backlog first. It also alleviated the pressure of having a bunch of specific tasks assigned to one individual for the entire sprint. If the team’s initial task estimate was not accurate, the individual performing the task could provide a new estimate at the time they selected the task.

This shift in task assignment not only alleviated bottlenecks and friction, it also enabled individuals to work in areas where they had little or no experience. For although vanilla Scrum encourages cross-functionality in that individuals play multiple roles (discussed below), it does not address the problem of individuals acquiring expertise outside their primary role. For example, we used to have individuals who felt as if they owned certain components, and would assign all of these components to themselves in order to ensure that only they worked those components. These individuals invariably became bottlenecks because they could not properly sequence the completion of various components, thus impeding the rest of the team.

By preventing team members from taking on too many tasks upfront, other individuals were able to work on those components formerly owned by a single source. This model was initially painful, in that team members would need to discuss system areas with the former owners of those areas (in order to learn those areas), causing initial friction and (falsely perceived) lack of job security.

Over time, however, the former owners of the components realized that they would be able to have days off, take vacations, and not need to become overloaded during every sprint. Simultaneously, more and more individuals were learning those modules and becoming cross-trained. The former component owners soon became comfortable with this model.

Sample

Although this was a move in a great direction, it didn’t do anything to help with the compartmentalized roles on the team. For example, although developers were learning how to code and unit test in a wider variety of modules, they still felt as though they were developers and therefore only should write code. By the same token, business analysts were there only to write specifications, QA analysts to write and execute test cases, etc. This mentality fostered the “mini-waterfall” most of us see when initially implementing Scrum. That is, business analysts would write specs for a developer, who would code from the specs, after which QA analysts wrote and executed test case, rejected code for re-work, and so on. This cycle repeated for so long that the sprint goal was not often realized. This model also resulted in much idle time for team members, as developers and testers had to wait while business analysts wrote specs, everyone else had to wait while developers wrote code, and so on.

Over time, we improved the model, based on vanilla Scrum’s encouragement for teams to become truly cross-functional. For example, at the beginning of a sprint I would suggest that business analysts work together with developers and QA analysts on specifications. It was amazing how much more effective this is compared to a business analyst working on her own, needing to ask the individuals questions as she plods through the specifications. I would then encourage the business analysts to write test cases while the developers wrote code and QA analysts unit tested that code, sometimes sitting side by side with the developers. Having QA analysts working directly with developers helped both parties to understand what the code should do. This was a much better situation than having the code rejected later when tested by a detached QA analyst.

This relationship also eliminated the natural barrier between developers and testers who had formerly sat in different areas, with little interaction. The biggest challenge is asking developers to write specifications, or convincing developers to write or execute test cases.

Blend

Given the proper opportunity, most developers can write great specifications (which are both lean and sufficient) and write effective test cases. I also have found that developers can also execute test cases very well (as long as it’s not their code being tested). Similarly, business analysts, QA analysts, technical writers, and the like can broaden their skills to include writing specifications, unit-testing newly developed code, writing test cases, executing test cases, and producing user documentation. The only exception to full cross-functionality, in my experience, is that only developers will write code. Following this model will enable the evolution of a truly cross-functional team to o]ccur.

ScrumMasters stirring-up the pot in this way will cause some initial discomfort among the team. However, once it’s “soup”, the team will feel great (as will the ScrumMaster, who is now perceived by the organization to be Saint Anthony)

Iterative Means Baby Steps

By Martin Jul

I am working on an agile development project in tandem with a database team using a traditional somewhat iterative waterfall approach.

The application has some metadata that are basically a bunch of enumerations in the database.

In order to support multiple languages in the GUI we had added a table with translations of the language specific text for one type of metadata to the development database. This way we have a language-neutral domain model and can ask for translations of various bits of the metadata (say, for populating dropdown lists with something humanly readable).

This step taken, we asked the database team to incorporate the translation table in the database in the future.

Then we continued working on the steps for fulfilling the requirements involving that particular dropdown list.

Some days later the DBAs asked us about a general approach for translating all metadata. We discussed it briefly and they set off to work.

When they delivered the database the week after we discovered that generalizing from that single example had been a very poor idea. Meanwhile we had uncovered some more requirements with the customer and that particular solution was very poor for a lot of the other data.

In other words they had implemented the wrong thing for every piece of metadata except that first table. Waterfall at its best.

This of course now forced the database group to undo a lot of work and come up with another solution spending valuable resources on the way. We had tried to think to far ahead, make uninformed decisions up-front instead of informed, on-demand decision-making. And predictably, the waterfall approach once again proved itself a loser.

Now, on the application side no rework was needed: by focusing on solving only the specific, known problem we had produced no code to solve the unknown requirements. No code needed to be changed.

Agile development done right is a big timesaver and it underlines the fact that iterative development is not about week- or daylong iterations, but "baby step" iterations of minutes and seconds.

Going Agile - Introducing Inspect-&-Adapt Cycles

By Martin Jul

Many large IT organizations are so inefficient that helping them go agile may seem like an incredible amount of work.

The key to not being discouraged is taking the long view and following the advice for how to eat an elephant: it is “one bite at a time”. If we try to solve all the problems at once we will simply be overwhelmed by complexity. Therefore we take an incremental approach.

The key is to introduce a reflective inspect-and-adapt cycle into the process.

Scrum addresses this problem in a very simple manner. We keep track the impediments experienced by the team in an impediment list. Hand in hand with this list is the “1-day rule” that any impediment must be addressed within one day. Even if the root problem cannot be fixed immediately the continuous application of these principles will keep focus on process improvement. Day by day things will become better.

Addressing impediments is quite painful to large organizations since the process is extremely good at making the organizational dysfunctions very visible. Therefore, Scrum also comes with the warning that “a dead ScrumMaster is a useless ScrumMaster”. We have to adapt to the pace that the organization is capable of absorbing. In the case of bottom-up implementation this may be a very long process - especially if the organization is financially sound. Ironically, in going agile, it is often much simpler to treat a dying patient where “busine

Myths about SCRUM - "it's a daily stand-up meeting"

By Martin Jul

Recently I have visited three different project teams that all claimed to be doing Scrum.

When I quizzed them it turned out that what they did was just short a daily status meeting.

Now, if that was all there is to Scrum we could have saved the money we spent on ScrumMaster certifications for everybody in Ative. It's is a good start but there is much more to Scrum.  

The daily status meeting - colloquially called "The Daily Scrum" - is a key activity, however.

Every project - Scrum or not - can benefit from it since it focuses the team on the situation and raises the awareness of the problems that need to be addressed. For truly dysfunctional teams just the simple fact that it provides a few minutes where everybody takes off their headphones to talk to each other about how to achieve their goal is a big boost to the project.

Three simple rules apply to the Scrum meeting that distinguish it from old-fashioned status meetings. It's short agenda is simply that every team member must present the answers to the following three questions:

1. What did I do yesterday?
2. What will I do today?
3. What is blocking me from working efficiently towards our sprint goal?

That's all. Timebox it to around 2 minutes per person. Use an hour glass ("minute glass") if necessary so you don't fall into the trap where some old-school project manager type does all the talking and concludes by asking if anybody has anything to add.

At Maersk Data Defense we also used two additional extra questions from Craig Larman's "Agile & Iterative Development":

1. Do you have any new items to add to the Sprint backlog?
2. Have you learned or decided anything new of relevance to the team members (technical, tools, requirements, smarter ways of working...)

The essence of Scrum is that of a self-directing, self-organizing team. This means that the meeting is not about reporting status to a manager, the goal is for the team to self-organize around achieving its goal and removing any obstacles in the way.

Bye, bye, "Done, but" - The Flat Organization & Enterprise Scrum

By Martin Jul

Lean organizations tend to be very flat with few layers of management. They rely on self-organization and leadership. In this context, then, what is the role of the middle layers in the organization? This is one of the points Ken Schwaber addresses in "The Enterprise and Scrum". The answer is amazingly simple.

The middle layers are Scrum teams that prioritize the work for the subteams and integrate the results.

In other words they prepare the product backlog for the subordinate teams and provide leadership, coordination, infrastructure and support for the teams below. This means that the integration teams are complete, cross-functional Scrum teams with full delivery capability. Compared to many traditional organizations this means that release engineering activities, QA, etc. move up in the organizational hierarchy, making the downstream steps in the value stream the integrators and bosses of the earlier steps. We are, in effect, a creating kanban system for the whole development process. Through this we create flow and remedy the common failure of deferring integration work to the end only to learn too late that the parts do not fit well together.

This organization of Scrum teams builds on lean principles such as frequent integration and "jidoka" - stop-the-line bug fixing. Every team is responsible for integrating its own work and that of its subordinates. If a subteam delivers something that is not good enough, the work is pushed back down and not accepted. This way, we make sure the details are always correct and shippable. As a result, the whole product remains integrated and shippable.

The ScrumMaster on the integration team is facilitates the removal of impediments that cannot be removed by the front-line teams themselves. This creates a system for multi-layered kaizen where the change is always initiated by the people who experience the problems and escalated to the proper level of authority. Through this the integration teams switch from command-and-control to serving the teams below.

One of the benefits from this structure is that the Product Owner on the integration team defines the product backlog for the subteams based on the coarser-grained backlog and priorities from the next level up. In this way the integration team and its subteams is treated as a virtual, cross-functional team. Since we are not allowed to produce loose ends, it forces us to actually start only activities that can be completed in a sprint with the necessary coordination between subteams. We have to begin with the end in mind.

For example, if a backlog item for adding a new report for to a reporting application is selected, we have to make sure to request the whole feature - both the new GUI (a pretty diagram, maybe), and the necessary updates to the back-end server application to provide the data. If there are separate teams working on this the feature is split across different team backlogs. In many cases this requires coordination between multiple teams when planning. The key point is to never commit anything to the integration sprint backlog unless all aspects of it are committed to the sprint backlogs of the subordinate teams.

If this is not possible we have to break it down into smaller pieces or leave it in the product backlog. We never accept work that cannot be completed and demonstrated at the end of the iteration.

When we implement Scrum in organizations this is something that it usually perceived as quite frustrating in the beginning. Many people have a strong habit of doing for partial work. However by only committing completable work we reduce one the great time-consuming activities in project management, namely managing dependencies between projects, trying to get features done in isolated, non-integrated layers and the coordination and "expediting" work to lobby different teams to change their plans to get it all correct and integrated on time.

The end result is a system where business goals and priorities flow from the top down and demonstrable business results flow from the bottom up. Every iterations ends with completely integrated realizations of the top level backlog items. It means goodbye to, "we're done with the new report, but we have to wait three months for the database team to expose the data for us", and hello to, "here's your new report, ready for use". That's a pretty good return on eliminating bureaucracy.

How Scrum Reduces Rework

By Martin Jul

I was talking to a group of project managers today in one of our inspiration meetings. One of the inspiring questions that came up was related to why we should use Scrum or agile methods.

One short answer is this: if we routinely plan to spend 1/3 of our project on testing and fixing defects there is a big benefit even if Scrum only helps reduce the amount of rework.

The next obvious question, then, is what are the most common causes of rework and how Scrum deals with these. Luckily we have some data on that, thanks to Otto Vinter (http://www.ottovinter.dk) and Søren Lauesen who wrote an article on the causes for rework (cited below).

In the project they analyzed they found four main causes of rework:
    ⁃    38% was caused by misunderstandings.
    ⁃    29% by missing requirements.
    ⁃    24% by changed requirements
    ⁃    9% by other causes.

Let's have a look at how Scrum addresses these.

Scrum Reduces Misunderstandings

The main problem is misunderstandings. This is why the "let's discuss the acceptance criteria" discussion between the Product Owner and Team before the development on a given feature starts is valuable. If we can avoid misunderstandings altogether the potential upside is a reduction in defects of 38%.

Scrum Reduces Superfluous Requirements

Then, the missing requirements. The just-in-time planning of Scrum and the demonstration of running tested software at the end of every iteration makes the identification of missing requirements trivial, so we will learn about these quickly. As such this does not reduce the amount of work due to missing requirements.

However, as we only commit to one sprint at a time it helps us to focus on building only the relevant, valuable features, which means that we also get a lot of feedback on which requirements are superfluous.

This means that we can more easily kill the half-baked ideas that we came up with in the beginning of the project when we had very little experience in the domain. Rather than building everything we thought of and then adding the missing stuff we look at the actual project and add the highest valued missing features week by week.

Thus, it gives the potential benefit of making us able to make the project smaller than if we had to commit early. That means less work, less rework and less complexity to maintain afterwards which is a great win over the lifetime of the project.

Scrum Makes Changing Requirements Inexpensive

One of the cornerstones of agile development is to make change cheap and easy. The reason we have Change Control Boards and other bureaucratic measures to prevent change from happening is that it is often very expensive and therefore we want to control it.

Agile development is all about making it inexpensive to adapt. If change was simple and did not introduce any huge risks of defects, downtime, deployment costs etc. we could happily embrace it. If we learned something new we could change the system accordingly, thus improving it and  increasing its value. That is why we cherish changes.

Scrum tackles this head-on. Going through a full development cycle from idea to production ready code every iteration it highlights all the expensive steps in our development process. It spotlights error-prone development practices, expensive manual testing, the bureaucratic inter-departmental coordination and the costly deployment procedures. By forcing our way through the entire pipeline every cycle we force ourselves to optimize the delivery pipeline. Not doing so is simply too expensive.

The key is to embrace the pain and use it as an impulse to fix the root causes of the problem rather than yielding to the lure of the palliative solution of resigning to doing it less frequently or managing the complexity rather than removing it.

It may take years to improve the organization to be able to do this efficiently, but the way there is rewarding. It gets better step by step, iteration by iteration. If you want to get to somewhere else you need only clear thinking and perseverance. It is as simple as that. Just get started - and keep going.

Eight Components of Enjoyment

By David Höhn

"All human actions have one or more of these seven causes: chance, nature, compulsions, habit, reason, passion, desire." —Aristotle

This is not a scientific article and while it may be based on facts, it is meant to be a thought blender—some agile juice, straight from the source, to get us thinking.

I indulged, with a friend, in a very interesting conversation recently. He told me that one does not need passion to do a job well. A bold statement to make. Yet, after some thinking on it my conclusion is as simple as his is bold. To do a job well you indeed need no passion; to excel, however, you do.

Passion has to do with enjoyment, with fun, with liking what you are doing. Passion is based on emotions, a strong source of intrinsic motivation, and while the intensity of our emotions may need to be moderated, our emotions should never be ignored. My passion for my job helps me to adhere to certain moral guidelines and forces me to look at the cube as if it were a ball—even when things start to frustrate me or circumstances force me to bend my own rules. To truly excel, we need to develop our passion and believe in the things we do. That is where Mihaly Csikszentmihalyi enters our little thought blending experiment. As esoteric as it might sound, "flow" refers to a simple set of recommendations Csikszentmihalyi defined in his book, Flow:The Psychology Of Optimal Experience. A proper flow, as described by Csikszentmihalyi, seems to be a good way of achieving happier employees and thus more efficiency.

Let's dive into his list of recommendations and dissect it from an agile bartender's point of view.

Point 1: Confront tasks that we have a chance of completing.

We can actually achieve this goal through timeboxing and sensible planning. By allowing self-organization to bloom, we allow little seedlings to grow into strong plants. Those tasks are then freshly picked from the strong flowers and consumed. We only take as much as we can handle and thus are one step closer to the flow.

Point 2: Concentrate.

Silence is bliss. Being left alone is a key part of self organization. Trust your employees. You hired experts; they will do what is in the best interest of the company. Allowing them to concentrate without interruption is crucial to sustained success. As such, proper agile implementation should help concentration. Find a way to ensure that your environment allows uninterrupted cadences of work.

Point 3: Concentration is possible because the task has clear goals.

Well-written user stories, clear and concise acceptance tests, a customer that is involved, and some business domain knowledge. Every iteration on an agile project should exhibit the above constraint.

Point 4: Tasks provide immediate feedback.

Immediate feedback might not be possible at all times. A mixture of test driven development, a deeply involved customer, automated acceptance testing, and proper sprint reviews should result in relatively instantaneous feedback, especially when compared to the feedback loop one has in a classically managed project.

Point 5: A deep, effortless involvement removes from awareness the worries and frustrations of everyday life.

Supporting one's employees is not confined to agile methodologies. Any environment that fosters trust and an understanding of mutual respect would help to remove the everyday fears we are confronted with.

Creating a safe, sane, and fun work environment is something that would help any company, and many are starting to invest a lot of time and money into making this happening. Another key factor one should not forget is the working culture, labor laws, and work history in the country in which this recommendation is being applied. More flow to come.

Point 6: Enjoyable experiences allow one to exercise a sense of control over one's actions.

Creating something that works and being responsible for that success will naturally result in a positive reinforcement. You need to ensure that even when self organized teams are asked to implement complicated tasks, they are given every opportunity to succeed. In short, trust your employees, leave the team alone, and let common sense prevail as you march towards flow.

Point 7: Concern for self disappears, yet paradoxically the sense of self emerges stronger after the flow experience is over.

When you're in the flow, "getting it done" becomes the focus. Empowered to do everything that I need to do, doing it becomes my only concern. I am less worried with sticking to company policies or rules enforced from above. I get things done for the customer so that this iteration is a success.

Reinforcing these positive deliveries by practicing sprint retrospectives will allow us to do what rule seven suggests. If we can implement sprint retrospectives that focus on the positive aspects even when delivery failed, we should be able to continually improve a team. On towards flow.

Point 8: Sense of time is altered; hours pass by in minutes.

Once this happens, we have arrived. Welcome to the zone. While we are flowing along, enjoying our agile juice, let's consider why this is happening. Given that no empirical studies have ever been executed on this particular problem, we might simply be experiencing what we refer to as being “content.”

Final Thoughts

I strongly believe that agile methodologies are not only about improving software development processes. These approaches need to take in account that we need to adjust the prevailing picture of how the workforce should be managed. People shouldn't just be going through the motions and doing the job well. They must have passion to achieve the excellence necessary to execute these methodologies properly.

Part of fostering this passion is learning to actively focus on fun, just as relentlessly as we learned to implement cost control. How much does an unhappy employee cost? How much time do employees who are only going through the motions waste when compared to someone that goes to work only to enjoy his personal “zone?”

I believe in passion and fun. I like to be in the zone. Come and join me?

The Power of Closure

By Tobias Fors

Have you ever watched an episode of, say, Prison Break, and noticed how they stop for commercials just when the action is most intense? Of course you have. Those moments are called cliffhangers. You are literally left hanging for awhile, and that's a situation you want to get out of.

Psychologists have a name for this phenomenon, this need to bring stability back into an unstable situation. They say that what we're so desperately longing for in cliffhanging situations is closure. We need to close the book to be able to move on. Until we've done so, we can literally feel like we've been left hanging.

Here's my take on why iterative, incremental, agile software development is so powerful: it teaches us the power of closure.

Everything that starts needs to have an end. That which is opened needs to be closed. Sooner or later. When we do sprint planning in Scrum, we set up a situation where all parties are left longing for closure. And closure will come soon. Those things we select to work on in the upcoming sprint will, to begin with, result in divergence: the team will discuss, debate and even procrastinate, but soon enough, the need for convergence sets in. The need for closure is making itself known again. Before the sprint has ended, the team will have realized the need to test, package, and document that which was requested during the first day of the sprint. They may even have done all these things.

When a sprint does not end with closure, the feeling of having been left hanging is most obvious to the product owner—the person in Scrum who is responsible for controlling the direction the product takes. He has heard the team commit to a set of goals, and has been hanging around to see them be realized. When this does not happen, closure is missing.

For the team, this lack of closure is equally obvious. As the team gathers and performs the end-of-sprint retrospective, the reasons for why not all goals were fulfilled are discussed. This is done without the assignment of blame, but it needs to be done for closure to begin. In order to fully close the book on the goals that were not reached, the team soon works with the product owner to determine when to attempt to reach those goals again, or decide not to do so.

In Scrum, that which is selected for development must be demonstrated. That which is begun must be finished. When we finish, we are taken back to a stable state, both in a technical and a mental sense. From this stable state we can the start anew.

In its essence, what Scrum does is this: it helps us to constantly look around us and ask, “What have we begun that needs to be finished for us to be able to move on?”

Psychologists might scoff at this use of closure, but it works quite well in this context, because in software development, starting is not the hard part. All it takes is a bright idea and a few spoken words. That’s why it’s not a bad thing to embrace our human need for closure: it helps us finish things at the same rate we start them.

Scrum Smells: Talking Chickens

By Mark W. Randolph

Importance

Important

Symptoms

These are symptoms that a Scrum team is not being protected from outside influences:

• External stakeholders talk in the daily Scrums
• Features are selected or priorities switched outside of sprint planning meetings
• The team cannot make purely technical decisions without an outsider’s blessing
• Status reports are required outside sprint planning meetings
• Team managers or executives who sponsor the team receive requests to influence the team
• Product backlog languishes or is ignored

There are many different types of outside influences. Only one example of outside influence is examined here: talking chickens.

Discussion

To explain the difference between a Scrum member living the pain of a bad technical decision and outsiders who feel compelled to make decisions for a team, Ken Schwaber [1] talks about a pig and a chicken opening a restaurant. The chicken suggests the restaurant be named Ham and Eggs. The pig suddenly realizes the difference between being an interested stakeholder and full commitment. After all, it is easier to contribute eggs than to be the entrée.

Scrum teams work best as self-organizing teams protected from incompletely informed decisions imposed by external stakeholders. An external stakeholder is someone who does not directly participate in development and is not a member of the Scrum. Typically, external stakeholders:

• Use or benefit from the use of the product, or are affected by product use;
• Contribute resources or pay for a product’s development; and/or
• Set priorities, budgets or schedules; and/or
• Do not suffer the full pain of bad technical choices (late nights, lost weekends, etc.).

In the context of Scrum, external stakeholders are chickens. Scrum team members are pigs.

While inappropriate outside influence can be exerted at any point in a sprint cycle, it is most visible when external stakeholders overparticipate in daily project activities, especially the daily Scrum, which explains the rule, “Chickens don’t talk at the daily Scrum.”

Note that external stakeholders have a legitimate interest in the success of the team and that the team cannot succeed without their contributions. That is the irony. Even if developers know best how to define and deliver valuable features, deeply useful products cannot emerge without the cooperation of the executives, customers, managers, and the others that the team serves. Chickens and pigs must collaborate to deliver a meal because, in the end, it is everyone’s bacon.

Why are the chickens clucking? Is it:

Ignorance? Maybe the chicken is an ignorant chicken. Have the rules been explained?

Weak enforcement? Is the no-talking-chicken rule consistently followed? If it is not, what is preventing the ScrumMaster from enforcing the rules?

Failure of support? Are the attempts of the ScrumMaster to enforce the no-talking-chicken rule undermined by team members or team sponsors?

Habit? Are chickens fighting old habits of immediate unimpeded access to developers? Do they lack experience with the rhythms of sprint and release planning?

Lack of faith? Do the chickens lack faith that Scrum can deliver what they need? Has the team done something, for example ignored priorities or been late, that has undermined their credibility so that chickens feel compelled to intervene?

Contention for control? If two or more groups are contending for development resources or priorities, that competition may manifest itself in efforts to direct the work of the Scrum.

Legitimate input? Did the team invite the chicken and ask for their contribution? Maybe the chicken ought to be brought into the Scrum.

Remedies

While it is tempting to offer a talking chicken a rubber band for their beak, or a chopping block for their neck, tact and discretion might compel you to consider other alternatives:

• Consistently enforce the no talking rule
• Conduct training as part of project start
• Negotiate rules at project start
• Use retrospectives to reinforce expectations
• Move chickens away from the pig pen
• Change the meeting time and place and don’t tell the offender (just kidding)
• Maybe the chicken can lay an egg
• Become a barnyard dog

Additional explanation follows.

Be consistent

Habit is your ally. Consistent enforcement develops habit. Mike Cohn tells this story [2]:

A few months ago I took my young daughters to a local fair. On one ride, the line led up to a short flight of stairs at the base of the ride. No one was allowed on those stairs, but many of the young kids wanted to sit on the stairs while waiting. The ride operator, though, held firm to her rule of no one on the stairs. She told them, “If I let you sit on the first step soon you’ll be on the second step and then the third step.” Clearly sitting on the first step would not have endangered any riders but the stairs were an obvious delineation and the ride operator used this as her simple rule. Not allowing chickens to talk during the daily meeting is one of Scrum’s simple rules. Of course one comment from a chicken may not hurt—but it will lead to others and then there will be no easy place to draw the line.

Never allow a violation that can be avoided. When a violation occurs, take action. If everyone is already familiar with the rule, a reminder during the meeting is appropriate. If the chicken might not be aware of the rule, speak to them privately immediately following the Scrum. If there is a single consistent violator, find out what the root issue is (“My priorities are being ignored”), and deal with that directly (“You have to start attending sprint planning meetings”). Bump the violation to the individual’s supervisor or the team sponsors and ask them to intervene.

Conduct training

Prevention is easier than correction. Make training a routine part of every project start and include potential chickens. Explain the rationale of the “no-talking-chickens” rule, and solicit a public commitment from everyone to cooperate.

Have a contract

As part of project start, help the group—Scrum members and stakeholders together—negotiate a set of rules of how to work together. One rule should always be, “Chickens can observe daily Scrums but may not participate.” As part of the discussion, talk through alternatives to attending and speaking at a daily Scrum. For example, “On this project, if a chicken has an urgent request that cannot wait for sprint planning, they can take it to the ScrumMaster and the ScrumMaster is obligated to act on the appeal.”

Use the retrospective pro-actively

Every sprint includes a period of retrospection during which the sins of the past are remembered, and pledges are made not to pass that way again. Relive incidents where the no talking rule was violated, explore the reasons for the violation, and discuss the consequences or potential consequences of the violation. At the very least, if it has been a problem, remind everyone of the no talking rule. This will help forestall reoccurrences.

Move chickens away from the pig pen

Shamelessly exploit unconscious human behavior! In group settings, the next person to speak is frequently the last person to make eye contact with the group leader or the last speaker. Arrange the room so that chickens are outside the circle of the Scrum and behind the ScrumMaster. They can’t make eye contact and are less likely to participate.

Bring the chicken into the Scrum

If the chicken is attending because they must be consulted or have valuable input related to development (clarification of requirements qualifies as development), maybe the chicken ought to be brought into the Scrum. Maybe the chicken can lay an egg.

Become a barnyard dog

It is the ScrumMaster’s job to protect the team from interference. A properly empowered ScrumMaster has the authority to exclude chickens from the Scrum entirely.

Case history

We had an executive notorious for micro-management. True to form, the executive attended the first daily of the first sprint of the first Scrum project and peppered the team with questions. Afterwards, the ScrumMaster—with great trepidation—explained that while observers were welcome, the meetings were for coordinating work, not problem solving. The executive’s response was, “Oh. Right. OK.” Seizing the opportunity, the ScrumMaster then urged the executive to come to sprint planning instead, offering these arguments specifically tailored for this particular executive:

• We’ll have a working demo ready
• The daily meetings are low level and technical, whereas the Sprint meeting is at the business level, and you can see what your customer is going see
• All your stakeholders will be in one place, the developers will be prepared for questions, and you can get really good information
• The team will be done with one batch of work, and ready for you pick what to work on next
• We have these every Monday (we use one week sprints), so you can arrange your schedule for months in advance

The executive was agreeable, and the idea of a demo was exciting. The executive did attend several more dailies, but within a week, declared them “boring” and stopped coming. After attending only a few sprint planning meetings, the executive was quite enthusiastic about the sprint model. “I like it!”

The lesson? The ScrumMaster took action immediately, and anticipating the needs of the particular stakeholder, offered opportunities other than the daily Scrum to get those needs met.

References

Schwaber, K. 2004. Agile Project Management with Scrum. Microsoft Press.
Cohn, M. 2003. Toward a Catalog of Scrum Smells. www.mountaingoatsoftware.com

The Why of Scrum

By Chris Fry

Scrum is built on a few simple principles:

Communicate. Sharing information creates visibility, better decision making, and a common understanding of shared goals.
Empower the team. Nothing is more powerful than a team that is in control of its own destiny--a team that thinks the only thing limiting what they can accomplish is how creative they are and how hard they work.
Learn and improve. Learning is about trying something, looking at the results, and then improving.
Deliver value early. Build trust with people by prioritizing work, committing to deliverables, and delivering them reliably. This builds trust with coworkers, other teams, and customers.

Scrum turns these principles into practice using the following mechanics and roles:

Communicate

• Communicate daily about your progress (daily meeting).
• Track your work as a team so you can make informed decisions about achieving your goals (sprint backlog).
• Work as a unit and don't let one functional area swamp another. (Stay in sync.)

Empower the team

• Give teams the power to control their own destiny and deliver on goals (sprint goals).
• Get impediments out of their way (ScrumMaster).

Deliver value early

• A prioritized list of work, organized and prioritized from a customer perspective (product backlog, Product Owner).
• Plan your work as a group, work on it in priority order, and set goals for an iteration (sprint planning meeting).
• Commit to your team members about progress (sprint tasks).
• Work in sync with the group and maximize for the team's efficiency (get to done, work as a team, don't impact other teams).
• Don’t degrade the system, always be within days of shipping the product (not weeks or months). (Don't create debt.)
• Work on relatively equally-sized tasks that can move efficiently through the system (grooming the backlog).

Learn and improve

• Work in short sprints and measure progress (sprints).
• Demonstrate your work at the end of the iteration and collect feedback from a broad set of people (sprint review).
• Reflect after every iteration on how you can get better at meeting your commitments and produce more code (sprint retrospective).

Scrum works best when its mechanics (sprints, daily meetings, grooming the backlog, etc.) are clearly tied to their driving principles (communicate, empower the team, deliver value early, learn and improve).

New Feature: The Project Velocity Chart

Velocity is a measurement of how much the team gets done in a given sprint. Velocity is what actually got done in the last iteration not what is planned. Typically, it is measured in story points. Each feature in scrum is a story. A story has points. Points can be anything you come up with.

ScrumEdge, like most scrum teams, doesn’t use story points for stories. Product Owner’s create stories and assign priority and the scrum team selects stories, breaks them down into tasks and assigns estimates to each task, mostly in terms of hours.

We added a new feature called “Project Velocity” which gives team members, Stakeholders and ScrumMasters the ability to view the actual budget burnt by individual team member as well as the whole team for a project. While this information was available for each sprint on the Projects Dashboard, we felt there was a genuine need for a chart showing budget burn for all sprints in a project. This data is mapped on a linear graph so as to see budget burn trends over the course of a project and be accessed by clicking the “Project Velocity” link on the dashboard.

The Velocity Chart below is based on sample data. It shows each sprint in the project on the x-axis and budget used by the sprint team on the y-axis.

 

This particular chart shows that the budget burn over the course of the project is fairly inconsistent (see the sudden dips in Sprint 3 and Sprint 8). As a ScrumMaster I would should take immediate notice of these inconsistencies and investigate why my team’s budget burn varies so much from sprint to sprint.

Did you see any particular trends on your Project Velocity chart? If so, did you figure out the reasons behind the trends?

Tell us what you think about this feature using our feedback page.

Scum versus Scrum

By Matt Truxaw

Single-celled organisms and software developers may not seem to have much in common. However, both of these organisms benefit from following a few simple rules that allow them to work in groups. Following these simple rules allows new behaviors and capabilities to emerge from the group - capabilities that individual members cannot demonstrate alone.

Slime Molds

Let's start by discussing slime molds, as explained in Steven Johnson's Emergence. Slime molds in their normal state are individual, single-celled organisms. When there is enough food and water in the environment, their normal life is a cycle of “absorb, excrete, repeat.” But slime molds have two built-in rules that they follow when conditions in their environment begin to deteriorate:

1. When a problem is recognized in the environment, emit an enzyme.
2. When you recognize this enzyme in the environment:
   a.  emit the same enzyme;
   b.  head towards the source of the enzyme.

When a problem begins to occur in the environment (lack of food, dehydration, etc.), a slime mold will emit an enzyme. Others in the area will sense the enzyme and move toward the source of the enzyme as they themselves emit the enzyme. This feedback of enzyme into the environment attracts even more slime mold cells towards the group which leads to more enzymes being released, which leads to more gathering, etc. At some point these individual cells grouping together reach a critical mass and they become a slime mold colony.

The slime mold colony takes on the appearance of a small slug, but it is made up of undifferentiated slime mold cells. There is no specialization among the cells. There are no "leader" brain cells or muscle cells. They are all individual slime mold cells, but their interaction has created a new "organism," the slime mold colony.

Slime mold colonies have capabilities far above the additive capabilities of the individual cells. The colony is capable of independent movement as a unit. It can travel great distances (for a slime mold) to solve its problem (find food or water) or it can create new slime mold spores to await better conditions. These colonies have even shown a rudimentary intelligence and can traverse a simple maze to find food.

These are not simply additive capabilities. These are not extensions of capability of the individual slime mold cells. These are completely new capabilities that did not exist in the individual cells but emerge from the interaction of the colony of cells.

Anthropomorphizing a bit, we can translate the slime mold rules:

1. When I recognize I have a problem, I tell others, "Hey! I've got a problem, I need help."
2. When I find someone else has a problem, I recognize that if it is not solved, it will be my problem, too.
   a.  I say, "Hey! We've got a problem."
   b.  Let's get together and deal with it.

With these rules in place, slime molds are able to deal with environmental issues as a group that no individual could possibly handle. Let’s see what would happen if any of these rules broke down. As an example, we'll assume the puddle where the slime mold cells live is drying up.

If Rule 1 breaks down, as conditions worsen in the environment, each individual slime mold may recognize the distress, but never communicate it to any others. There is no way for the other slime molds to identify where to go to solve the problem. As the puddle dries up, the individual slime mold cells are incapable of independent movement of any distance. They all dry up with the puddle.

If Rule 2a breaks down, the individual cells acknowledge the problem and even communicate that out to the others. No cells respond to the original enzyme message. Without feedback, there is no concentration of the enzyme in any particular area. Even if a few cells in the area gather together, critical mass is never reached and the cells are still incapable of independent movement of any distance. Again, they all dry up with the puddle.

If Rule 2b breaks down, even though the first cell communicated the problem and the other cells picked up the problem and repeated the message, they never come together. The individual slime mold cells can complain all they want, but if they don’t come together to do something about it, the individual slime mold cells are still incapable of independent movement of any distance and so they all dry up with the puddle.

You can see how imperative it is for slime molds to follow their rules. Now, let's take a look at software developers and see if we can extrapolate what lessons they might take from the lowly slime mold.

Software Developers

People are a little more complicated than slime molds, but we can successfully run a software development project with rules only a little more complicated than slime molds. We call our rules Scrum.

The customer emits his virtual enzyme by saying, “We have a problem (or we want a new feature, a change to a program, a new product to sell, etc.).” In Scrum, we call this a backlog item.

The software developers respond, saying, “We have a problem to solve. Let's get together.” We call this a sprint planning session.

We create a small colony of individuals that together has capabilities far beyond any of the individuals themselves. We call this a Scrum team.

Then we take action and start moving. We call this a sprint.

As we are moving, we keep the feedback loop running. We get together everyday. We check in with how the individuals are doing on this journey and see if we need to change anything. “What did I get done yesterday?” “What will I do today?” “What's getting in my way? (I have a problem, I need help.)” "How are we doing on solving our problem?" "Do we need to raise the call louder to bring in other help from outside the current group?" We call this the daily Scrum meeting. The ScrumMaster is the enzyme that goes outside of the group to get more help if needed.

When we get where we’re going, we stop to make sure we’ve solved our problem. We call this a sprint review. Being a little more sophisticated than slime molds, we also look back on what we've accomplished and try to identify better ways to solve similar problems in the future. We call this the sprint retrospective.

Now, if our problem is truly solved, we may disband the current “colony” or choose to take on another problem.

Self-Organizing Systems

Slime mold colonies and Scrum teams (and many other agile teams) are self-organizing systems. The results from these types of systems are not caused by leaders or managers. Results emerge as a result of interactions between the individuals on the teams or colonies. Individuals within the system need to follow a set of rules of interaction that allow feedback loops to be created and to grow. New behaviors and new capabilities emerge from these feedback loops.

When adopting Scrum, it is important that a team consistently follows the basic Scrum rules. The “right” rules create positive feedback loops that allow the systems, the “colonies,” to achieve results that are not even in the scope of the individual's capability. Not doing these simple things can create feedback loops where things spin negatively out of control and add to the problems. (Think of leaving out Rule 2b for the slime molds.) The Scrum rules have been shown to work. When fully adopted, they have been shown to create positive feedback loops that lead to exponential increases in performance. New behaviors and capabilities emerge from the team that the individuals did not know existed. It takes some time for critical mass to be reached. It takes time for the colony to form. It takes time for new capabilities to emerge.

As humans, we have the ability to inspect how the rules are working and decide whether to adapt them to our individual situations. Inspecting and adapting are what allow humans to continuously increase our capabilities. However, do not be too hasty when modifying or discarding any of the basic Scrum interactions. Give your individual cells time and resources to reach the critical mass where they can go where no scum has gone before.

ScrumMaster: Appointed or Team-Selected

By Mike Cohn

The selection of a new Scrum team's ScrumMaster can impact the success or failure of the team's Scrum adoption. Choose the wrong person and the team could face the uphill struggle of trying to become self-organizing while under the thumb of a command-and-control style manager. Choose the right person—matching the skills of the new ScrumMaster with the initial needs of the team—and the team will have an incredible headstart in adopting Scrum.

I had intended to use this short column to provide some guidance on how to select an appropriate ScrumMaster. In preparing to do so, however, I realized that a much more fundamental question needs to be answered first: Who should choose a team’s ScrumMaster? Should it be the team members themselves? Should it instead be a departmental manager? The Project Management Office? Maybe the Product Owner should choose the ScrumMaster with whom they think they can work best?

I’d like to answer that, in all cases, the team members should choose their own ScrumMaster. Unfortunately, that's not always possible. Whether the team should choose their own ScrumMaster is dependent largely on how far along in their adoption of Scrum the team is. In many cases when a team first adopts Scrum there are many parts of it they are unsure of. There are many parts they will struggle with and will be tempted to omit or weaken. New teams often, for example, are tempted to conduct their daily scrums less often than daily. They aren't used to working closely with others and have not ventured far beyond their individual roles. Taking a team at this level and saying, “you’re self-organizing so you figure out who your ScrumMaster is” often leads to disaster.

Instead, these very new teams often benefit from a telling style of leadership. They need to be told that they will produce software that is working and “done” at the end of each sprint, that they will meet daily, that potentially shippable means tested, and so on. I’m not implying that they are told this in some heavy-handed, command-and-control way. Rather, my point is that the team needs a leader/ScrumMaster who will tell them it’s not acceptable at this point in their Scrum adoption for them to experiment with the fundamental, generative rules of Scrum. These teams probably aren’t ready to choose their first ScrumMaster.

By contrast, consider a team in which individuals are comfortable working with each other; where each team member may have a defined functional role but where each is comfortable and capable of stepping beyond that role for the good of the team; and where team members have a greater willingness to stick to the rules at first. A team such as this would likely bristle at being assigned a ScrumMaster.

So, who should select a team's ScrumMaster? My default position is that the decision should be left up to the team. However, a caveat to that position is to first make sure the team is up for the initial challenges of adopting Scrum. Don’t make it harder for them by piling this decision on them if they won’t have a framework for making the right decision or if the decision will be taken away from the whole team by one overly aggressive member who sees the role of ScrumMaster as a ticket to increased authority, greater power, and a seat on the corporate jet.

When the team isn’t in a position to choose their first ScrumMaster, my fallback position is that the decision belongs to the departmental manager whose neck will most be on the line for the success of the project. I prefer to avoid having the product owner select the ScrumMaster because that has the possibility of eroding the beneficial tension that should exist between a good ScrumMaster/product owner pair.

In a future column, I’ll provide some practical advice that can be used to help select the best ScrumMaster, whether that decision is being made by the team members themselves or by a departmental manager outside the team.

Rethinking Sprint Length

By Alexey Krivitsky & Ragnar Birgisson

Our project takes place in a distributed environment—the development team and product management are located in different geographical places. When we first came to the project, our job was to help establish an outsourced, offshore office for a project that had survived years of ad-hoc development with no fixed iterations and no pre-planned releases. The domain was not complex, but the poor code quality and the onsite absence (or remote presence) of the knowledge-holders made the start-up trickier than we and the project stakeholders had anticipated.

We spent the first three to four months learning the codebase (by fixing bugs and adding some new pieces of functionality). Finally we were ready to think about how we should approach our project. We knew we wanted to try an agile approach and, after much debate, we decided to try Scrum (how that came to be, how Scrum was introduced, how it should have been introduced instead, and how eventually it changed the way the company works are topics for another article or two—maybe next time).

Setting Sail for Scrum

When we first began, we chose to use four-week sprints. For our product backlog items, we used per-feature requirement documents that we called feature specs. A feature spec is typically a three- to five-page document with a feature description, main workflows, and the screenshots. Our feature specs were created by the remote product managers.

These documents worked to some extent. However, from time to time gathering the needed amount of specifications for the next sprint was difficult for the product owner. He and the product managers struggled to find the time to write the specifications. Even after they managed to write some things down, more often than not, the information they provided would not be enough for the developers to provide reasonable estimates.

The length of the sprints felt fine to the team, but management felt they needed more visible results. At the same time, we wondered if a shorter sprint would help focus the team and optimize performance. We decided to switch to the shortest duration deemed possible: a single week. We could always switch back if it didn’t work.

Some of the results of our change were positive. For instance, each week the stakeholders received more visible results. However, the drawbacks far outweighed the positive. First, the development team started to feel pressured by having to deliver every week. Second, it was quite difficult sometimes to deliver valuable functionality in a just a week’s time. Finally, the cost of starting and stopping a sprint felt quite high, both in time and emotional investment by the team.

Miles to Go Before We Sleep

After the rather disappointing results of our weekly sprints we decided to revert to four-week sprints.

Compared to the rush we experienced trying to deliver weekly, the next few months felt relaxed. As we began to adjust the process to our ideals (and our ideals to the realities), we managed to start collecting the specs earlier and with more detailed explanations for the programmers and the testers. Things were improving. However, when we looked closely at our sprint activities, we realized that instead of a four-week sprint, we’d really been doing three-week sprints plus a one week cushion for finalizing unfinished sprint tasks. This was definitely not what we wanted “our Scrum” to be.

Ahoy! I See Land

It had been more than a year since the project was outsourced. Things had improved, but were not yet where we wanted them to be. At that time, we made a fundamental change to our requirement management process: we substituted lightweight user stories (inspired by Mike Cohn’s User Stories Applied) for our mid-weight specifications.

As we had hoped, user stories increased communication between development and product management. They also raised our understanding of business needs by the team. As a result, inter-site trust and relationships improved. This, in turn, boosted the product quality (the increase in quality was also due to better planning through finer-grained user stories, a growing set of unit tests, and the increased size of the testing team).

Having achieved the conditions described earlier we decided to try out shorter sprints. What follows are the “hares” that we were supposed to hunt for by changing our sprint length. (Happily for the hare-lovers, some of the beasties are still hopping in the wild.)

• Boost the team’s performance. The team had been having a tendency to start losing focus in the middle of a sprint. To counteract this, they simply had another sprint planning meeting after the second week to find out the current status (though we used to maintain a burndown chart) and made corrections to their plans by redistributing the tasks. This was not an ideal situation.
• Get earlier feedback from the product management (user proxies) and thereby from the real clients. The user stories were usually available for review by the end of sprints. The high story-count of what had been developed within that three- to four-week period made it quite hard for management to ascertain the project quality and plan for fixes/changes for the next sprint.
• Let the company make more frequent releases. The company’s official plan was to have quarterly releases, but we wanted to provide the possibility of doing it more frequently.
• Remove planning difficulties. With monthly sprints, the product owner had to plan four weeks ahead, which sometimes was hard due to ever-changing business priorities. It was also hard for the development team—the large number of stories we had to consider made planning sessions long and energy draining.
• Learn faster. We had to wait at least four weeks to study the effect of any changes we implemented in our process. Also we often wished to make so many changes that we were not able to focus on all of them within a single sprint. Problems we identified during sprint retrospectives began to pile up in a queue to be resolved at some later stage.

Our Journey's Far from Done

So far the team has done three bi-weekly sprints. In that time, met the following goals (or captured the following hares):

• Boost the team’s performance. The teams started feeling more focused, which they like. They now also can remember most of the sprint’s user stories, which makes it easier for them to communicate their status to each other. Some of them claim, though, that if the complexity of user stories or internal system grows they will not be able to finish sprints this often.
• Get earlier feedback. This has been confirmed by the product managers: they were able to get clients’ feedback faster and obtain developers' estimates and updated plans faster, thereby reducing the whole feedback cycle.
• Decrease planning difficulties. This has been seen by all of the affected people. For Alexey (as a ScrumMaster), those planning days were the most difficult ones: too many stories to think of, too-long meetings to be kept organized. Now planning is almost as easy as the morning Scrums.
• Learn faster. Over the past six weeks, we’ve already had three retrospective meetings (compared to the maximum of two we might have had, had we followed monthly sprints) which were quite productive, and again, easy to do. The attendees were in no rush to list all known obstacles, since we knew in two weeks’ time we would be able to review it again.

The following goals have not been met so far:

• Let the company make more frequent releases. This is still a goal for the next quarter or two. Though quality has increased within the last months, it is still not possible to release the software just after any sprint without running one or two special bug-fixing sprints.

Are all of these positive changes a result of switching to a two-week sprint? No. Shortening the sprint length itself lent to the positive effect, but doing so would not have been possible without other essential changes, such as raising team motivation and moral, improving and increasing communication between product management and developers (with the introduction of user stories), and increasing internal product quality.

Should we have started with two-week sprints right from the beginning? We don’t think so. Again, we think we would have failed without those preconditions (trust, user stories, good quality, etc.) in place. By starting slowly and building these components, we were able to deliver more quickly and then naturally adjust the sprint length. After all, you must learn to walk before you run.