Those devilish actuals

By Henri Stegehuis

About a year ago, I had been struggling with an important "don’t" of Agile Scrum, actual hours. In the first phase of Sprint planning we take all of our actual hours based activities and transform them to ideal hours. The focus factor or productivity factor transforms the hours for these activities to the desired ideal hours. After this initial process actual hours are expelled from current Sprint.

It may take up to a couple of Sprints to get the team really used to the ideal hours way of thinking. Once they understand and have experienced that removing slack from the estimated hours is compensated by using the productivity factor and that the team has control over this productivity factor, this Agile Scrum concept is in place. During the first few weeks as a ScrumMaster you will find yourself pleased with how planning and estimating are addressed in Scrum.

Then reality is catching on

My company’s biggest assets are we, the employees. We offer software solutions; we offer knowledge and broad experience. It all comes down to selling hours and accounting for them. With fixed price projects this problem is easy to overcome by assigning invoice schemes to Sprint deliveries. However, with non-fixed price projects, the accounting is mostly hourly based.

Potentially, the accounting problem with our contractors could be solved by defining certain effort milestones. There is a third party that is really a tough nut to crack, and we need them instead of them needing us, the government. A lot of innovative projects are subject to subsidies. Every claim for a subsidy has to be accounted for based on actually spent hours. The Burndown chart gives no information, as it is intended to, about actual hours spent on a task. For Agile Scrum the past is not interesting but the future is, can we make it in time? Accountancy for contractors or subsidies though lies in the past.

How to integrate

This has kept me busy for a while. I need actual hours, but I don’t want to track them; it is just for accounting. Also, the team must never get the feeling of being micromanaged. Equally important, upper management may not see these hours; I just spent weeks getting them familiarized with ideal hours and the Burndown chart. I don’t want to give them a reason to return to using old methodologies.

The first approach we tried was having the team write down the actual hours once a week on a separate list. This was not working for two reasons. One, the relation with the real tasks became loosely coupled. If I ever had to explain myself on an audit I wouldn’t be able to do so. Two, there were two lists and the team members became irritated. They demanded a solution on the Scrum Board.

Because we would like to maintain a one-to-one relation between Scrum Tasks and actual tasks, we decided to use the Tasks cards. We used the back of the sticky notes to write down actuals information. At the end of the Sprint, I would take down the Scrum Board, and fill the role of Project Manager by administrating the actuals. The consistency was in place and the administrative actions for recording were relatively easy and outside scope of the team and upper management. The recording at the end of a Sprint, when the result was already in place, was so late that the actuals gave no up-to-date, controllable information.

Unfortunately this solution was not working for the team at all, again for two reasons. One, mixing ideal and actual hours in during the Daily Scrum was making people schizophrenic. Two, the other reason might seem over-sensitive, but turning over the sticky-notes was an annoyance, especially while we already had to tape down the sticky notes because they do not seem to really stick (we would always find a couple of them on the floor the next day).

The last approach though had given us valuable input. While we had to tape down the task cards any way, we didn’t have to use the sticky notes. We have decided to make task cards with a default layout. We still use different colors for non-default tasks. Three-fourths of the new task cards is reserved for the Sprint data and one-fourth with a background pattern is reserved for actual recording. In the morning Daily Scrum, we discuss ideal hours, and before we go home, we write down actual hours for that day.

Conclusion

In recent Agile Scrum projects the layout of the Task cards has changed mostly because of the team’s personal tastes. The concept has not changed and the team agrees with the current solution. We know actuals and ideals are conflicting, and it is not Agile Scrum. Now, we separate them by having a different background on the Task cards, and speaking ideal hours the entire day and accounting for actual hours at the end of the day.. We feel that we have found the best solution to secure our sources of income and still follow the Agile Scrum methodology.

Scrum in old fashioned software environments?

By Christoph Oberle

The “normal” Scrum project

When I look around in the Scrum community, I wonder whether Scrum is only suitable for modern software development. All these shiny, new ways of making really cute, web- based software, with modern source repositories, automated unit and regression testing tools, and other fancy stuff. If you look at typical job postings for Scrum specialists, you see the same situation: It's all about modern, web-based systems and applications.

How about legacy applications in an old-fashioned insurance company?

Because I was working in a “classical” software environment, I wondered why Scrum was not more frequently used in those environments.

Some excuses for not using Scrum include

• “We always do it like this; there is no need for change!”
• “I like the ideas, but I cannot imagine how we can deliver something in only three weeks time, even the regression test will take longer!
• Our processes prevent us from using the Scrum methods, we have to do X, Y and Z, otherwise we will not succeed.”

I think there is a fundamental reason for the reluctance to adopt Scrum in those software environments, and it is exactly the reason why Scrum was invented.

A typical example in a “classical” environment

Before we go into details let me tell you a short story about test automation of letter production. In an insurance company, the focus on regression testing of the software system was very high, because all the standard letters, which were sent to the customers, had to be tested manually. They had to be inspected manually and have been visually compared to the former versions. It was obvious that the effort to automate this process would realize its ROI even in the first project when it was applied. Nevertheless the automation was never implemented. It had been scheduled into each project, but because of time constraints it was always de-scoped in favor of some more “real” functionality.

How could this happen? Because the team who was able to implement the automation (the developers) did not get any benefit from it, and the team who was asking for the automation (the testers), was not able to implement it. Therefore it was delayed for years.

So what and who caused the effort to fail?

This question is not easy to answer. In every project the Project Manager made the right decision in de-scoping the automation task. It was always the right decision because it stabilized or even rescued his project. So if it was not the Project Manager's fault, who was to blame? Upper management should not be made responsible for the Project Manager’s decisions, which are real day-to-day work and should never be discussed at their level.

So, if nobody is guilty, then the process must be at fault. The established process leads to the situation where the automation task is always de-scoped. Also, it makes it less urgent than some other tasks in every project where it is included.. To summarize, there is no control in place that is able to monitor the effects of de-scoping the automation task in a global “cross project” view.

What rules must be changed to get the automation task done?

1. Obviously the testers must have the authority to request the development from the developers.
2. The Project Manager must not be able to de-scope the task in favor of new requirements.
3. At a minimum, upper management must be aware of any decision to delay the task

If we think about the probability that we can to achieve the above changes, I'm not too optimistic. How should I empower the testers to prioritize the developers' work? How should I limit the project manager, so that he is not allowed to de-scope the task? How should I make these tiny project decisions visible to upper management? All these changes are prohibited by the process. The process' rules prevent them.

And in a more “agile” environment?

Now let's have a look at a Scrum set-up. How would this situation be handled in a Scrum organization?

In a Scrum organization, the team would be cross functional, where all relevant parties participate. In this example the testers and the developers would be in one team. The team could not be successful if all tasks were not “done” at the end. And after the team has accepted a task it is responsible and stays responsible to get it done.

In a Scrum organization the product owner cannot change the contents of a Sprint. He cannot de- scope a task in favor of another task during a Sprint.

In a Scrum organization, if a task is part of a Sprint and it cannot be delivered, the managers are made aware at the end of the Sprint...
In a Scrum environment the problems in our example are resolved.

If it is this easy, why don’t all organizations just switch to Scrum?

It's all about agility

The problem is the transition to Scrum.

First, you need to have one team which is representing all aspects of product development and is capable to fulfill all the needed tasks.

To achieve this, the established walls between the different roles in the software creation process have to be torn down. And those walls have been so comfortable for all participants. (it is much easier to blame process as opposed to at a colleague). And if a development is not yet ready, a tester has no problem complaining about delays in his plan..

In my project experience I once tried to establish Scrum practices in a kind of a “silent roll-out”. I wanted the team to work together across departments and roles, but I realized that this was not possible. You cannot build a “real” team without letting the team define its rules themselves. And you cannot change the rules that have been used by the established processes, without explicitly changing the processes.

Second, you need to establish the Scrum roles. You need a “real” product owner, who knows how to play his role. You need a ScrumMaster who fights for his team and protects it from outside influences.

Third, you need to transition to a time-boxed approach as soon as you start with Scrum. The time box is the most revolutionary change to the classical environment imaginable. Once, when I wanted to establish some Scrum-like practices in a project, I convinced the IT line manager and the project manager to have fixed development intervals of 3 weeks. We had a pipeline from development to testing and finally to user acceptance testing. But as soon as we got a delay in development, the project manager wanted to have the dates shifted to get more results as soon as possible. The benefit of having a time-boxed approach and agreed handover dates from team to team, was sacrificed for a potentially “more complete” next code drop.

You need all of this to start with Scrum. And don't be overly optimistic. It will require discussion, training and good leadership to transition.

What did we learn?

As I stated earlier, I think there is a fundamental reason for the reluctance to adopt Scrum in “classical” software environments, and it is exactly the reason why Scrum was invented.

In some organizations, the established processes are stabilizing themselves even if they are not helpful. There is no culture for changing the established processes.

In some cases, the established roles in a “classical” environment do not take responsibility for the whole. There are situations where team members make excuses because something isn’t their responsibility. Also, individuals are not empowered to make decisions.

In “classical” environments, time and cost are less important than quality. Because of this approach, delays are widely accepted and at the end of the project de-scoping of less prioritized tasks is typical. This leads to projects whose status cannot be measured continuously.

In other words: with Scrum you constantly measure your performance, empower your team, and constantly improve your processes. These elements of Scrum are crucial for an organization to improve its processes and to accelerate the release cycles and the features delivered in each release. Unfortunately the inability of the processes in “classical” environments to support these improvements leads to the difficulty in implementing Scrum in those environments.

Implementing Scrum is hard work, but it's worth the effort.

Why Don't I Floss My Teeth? How Emotional Impediments Hold Us Back from Adopting Scrum

By Michael de la Maza

I've been going to the dentist for over thirty years. Whenever I visit the dentist, I'm told to floss twice a day. Flossing fights cavities, bad breath, and disease. Flossing is simple: it takes about two minutes and costs just a few cents.

And yet I rarely floss my teeth.  Why?

The problem is not at the knowledge level. I know why transitioning from not flossing to flossing is a good idea, full of wonderful benefits for me and my teeth. The problem is not at the behavior level. I know how to floss my teeth because my dentist enthusiastically practices on me every time I visit her.

So if the problem is not at the knowledge level or the behavior level, what is the impediment that causes me not to floss?

Understanding the answer to this question is, I believe, key to understanding why Scrum adoption is so difficult. Understanding what Scrum is (knowledge) and what to do (behavior) is fairly simple. But there is another level, the emotional level, which I have found contains the key impediments to the successful adoption of Scrum.

Many Scrum coaches have transition plans which include garnering the support of senior executives, providing appropriate training and coaching, and creating a transition committee. While these are certainly important considerations, they do not address impediments at the emotional level. A person who has to transition from being in QA to being a member of a Scrum team and is worried, nervous, afraid, and anxious is not directly helped by knowing that the larger organization has a Scrum Transition Committee or has implemented a Scrum Pilot Project.

For ideas on how to address emotional impediments, I have found that studying Weight Watchers is instructive. Weight Watchers was started in 1961 when Jean Nidetch confessed to a group of friends that she was overweight because she could not stop eating cookies. In launching Weight Watchers, Nidetch explicitly said that while she knew how to eat right, she needed emotional support. Today, Weight Watchers provides weight loss information (knowledge) and teaches a point count system (behavior). But, most importantly, it provides emotional support for people who want to lose weight.

A successful Scrum transition effort will do the same.  Not only will it bathe people in the knowledge and behavior needed to do Scrum, it will provide individuals, teams, and organizations with support at the emotional level as they transition to Scrum.

How Scrum Helped Our Team

By Samir Bellouti

In 2008, I began work with a client on a new project. The client was a airline and travel agency that needed to rewrite, from scratch, their online travel booking application. The new website had the following primary requirements:

• Improve end user experience, including performance and security issues;
• Offer new set of products on the website (Hotel booking, car hiring and insurance purchase); and
• The new application had to connect to a brand new back-end system.

After learning about their process and project, I suggested that we try a new approach: Scrum. My clients did not know much about Scrum. In fact, the only Scrum-like practice my client had tried was daily meetings. I insisted that using Scrum could help us build software more quickly and build it with higher quality. This was not easy to sell. The client had a number of questions, such as:

• How can you accurately estimate a project with an iterative process?
• How can you determine the delivery date of a project if you re-estimate it after every sprint?
• How can your customer agree on an analysis and “sign it” if you do not have an analysis phase?
• Isn’t Scrum just a cowboy development process since we do not have a detailed design phase?

I answered their questions or worked with them to find answers. At the same time, I did not pretend that Scrum could solve all of their problems. I did point out what they already knew:  their existing waterfall methodology, with its detailed estimates and phases, only gave the illusion that it could deliver a high quality product with all required features on budget and on time. Scrum, on the other hand, could mitigate some of these risks. After much debate, we decided to give Scrum a try.

Early Sprints

We called the first phase Sprint 0. We spent the iteration doing refactoring, as some of the code was written and the application was growing in size. We decided not to develop a user interface during this sprint but instead focus only on the framework and the design.

We quickly identified some problems with our first sprint. First, Sprint 0 had no pre-determined length. Instead, it lasted roughly two to three weeks. We decided that our next sprint would last four weeks--no more, no less. Second, we had not clearly defined our deliverables and goals at the beginning of the sprint. We learned that we should set our goals much more clearly for the subsequent sprints.

Even with our problems, we were highly encouraged by the outcome of Sprint 0. We managed to deliver most of our infrastructure components, including the globalization component, the interface to the Java-based SOAP legacy application, and the general structure of the web application.

By the end of Sprint 1, we had delivered our first functionality: the home page and a couple of related user stories. We had completed our sprint goals. We had developed solid product and sprint backlogs and had begun to use a tool to support us (Team Foundation). During this sprint, all the team members also had completed Scrum training, which helped them understand the Scrum philosophy and their responsibilities as Scrum team members.

By now the business was convinced that the team was capable of delivering working software every four weeks. They also began to believe that they could trust the team: they could give the team direction, let them work for four weeks, and only check the results at the end (rather than during the sprint). This realization was very important for the team and the organization. I believe that this is the most important thing in Scrum; trust the team. Trust the fact that the team can self-organize and deliver.

Immediate Effects on the Team

In most of the organizations I have worked for, when we talk about teams we actually mean a set of individuals grouped under the same manager. Scrum development teams are true teams.  The difference is major.

On a waterfall “team,” the project manager plans the tasks and their precedence. Most of the time, this same Project Manager will then assign tasks to developers according to their skills, which are more or less well known by the PM. These tasks are generally large (generally taking few days if not few weeks to complete). In most cases, team members talk to each other only when there is an issue. Everyone on the team does his work on his own and, at the end, delivers what he was asked to do.

On a Scrum team, the team commits to deliver some set of functionality by the end of the sprint. No one person is accountable for a particular piece of the software; rather, the whole team is accountable for all the software they engaged to deliver by the end of the sprint. People choose their own tasks (or choose to work together on tasks). The tasks they pick from are relatively small (taking a few hours to a day to complete). At the beginning of each day, the team meets to talk about what they worked on yesterday, what they’ll be working on today, and what kind of help they need to complete their work. Throughout each day, Scrum teams reach out to each other for help or to coordinate tasks. At the end of the sprint, the whole team is accountable for what is delivered. There is no “I finished my tasks, so I’m good.” The sprint is not a success unless every promised feature is delivered.

As I mentioned earlier, the tasks in Scrum are relatively small. On our project, we limited the size to less than sixteen hours each. A detailed task list improves team productivity for the following reasons:

• A list of very specific tasks reduces or eliminates work on tangential tasks—those that may be important but are not part of the current sprint. A common example for our team was when a developer would grow interested in a performance or security issue and would interrupt his primary task to focus on these side issues. It’s not that these tasks are not important. They are. However, they often caused us to be late with the work we had committed to deliver. With Scrum, developers must only work on tasks from the backlog. If security or performance tasks do not appear in the list, no one should work on them. If anyone does choose to do work outside the backlog, he/she will have to justify it to the whole team during the daily meeting.
• By having a clearly defined task list, no one can say, “I don’t know what to do today,” and then wait for someone to assign him a task. On a Scrum team, a developer should pick up something from the task list and get to work, even if it’s not something he might normally think of as “his job.”
• Tracking small, specific tasks is easier that tracking high-level tasks. If a user story (use case) has multiple tasks and, for some reason cannot be finished, it is easy to find out exactly what is wrong (which task is slipping).

Working on a Scrum team means that team members will be asked to be accountable to each other. They will be asked to interact with each other daily. They may have to do work outside their comfort zone or help with tasks they wouldn’t normally undertake. This level of communication and coordination is not natural in IT world where developers are chosen for their autonomy. But the beauty of Scrum is that it really works. I can tell you that it took us less than two sprints (two months) to raise the level of trust among team members and improve the performance and the communication level of a team that had been working together for a couple of years.

The Effect on the Business

During Sprint 3, our software was growing from the functionality point of view. We were no longer increasing the number of lines of codes without seeing a concrete deliverable in return (concrete here refers to something the business or project owner can measure and play with).

At the end of Sprint 3, the business and the CIO of the company were convinced that this “new” methodology would help to deliver the software more quickly than with the waterfall model. The fact that the marketing guys could play with the application gave them the opportunity to point out a few potential issues. We prioritized these issues, bringing the most important into our next sprint and adding the less important ones to our product backlog.

During the Sprint 5 planning meeting we had a breakthrough. After hearing that we could not complete a feature by a certain date, our business sponsor reacted in a surprising way. Rather than bemoaning the loss she thanked us for the advance notice. “Usually I only find out a month before we’re going live that I’m not going to have a certain feature. This time, I know five months in advance. That gives me some options.” This was a very big step forward in terms of the relationship between the IT department and the business. They can finally see the impact of a change on the overall schedule. Moreover, they understand that they have to cut some other backlogged items in order to have their change done. This helps them to deal with the reality: a change has a cost and the development team has a limited capacity; either you cut somewhere else or you hire new developers. You cannot ask for changes and just hope that everything will be delivered on time.

For me, who insisted that the client to adopt Scrum, this statement was a real proof that iterative processes are the way to go for any software development project. I see, even today, many projects where development teams keep using the waterfall process. They all have their own reasons for avoiding a shift to a new approach. I strongly believe that the underlying objection is a combination of a fear of the unknown and a real lack of knowledge of Scrum. Most of the project managers I talk to refuse to admit that the waterfall model is over. Some other PMs, who use heavy iterative methodologies, will argue that it is too hard to trust a team for a whole sprint before they can see the results. That’s a very interesting point and a fundamental aspect of team and project management.

I know that in our case, after just a few months of using Scrum,  we and the business had a much better understanding of our capacity (what we can deliver in a certain time frame). Also, because requirements, change requests and bugs were all logged in the PBI, everyone involved with the project had a more accurate view on what was involved in delivering the product and what remained to be done before the delivery date. Having this detailed backlog enabled the business to cut some nice-to- have functionalities in order to ensure the delivery of a critical functionality or bug fix. Because we knew our capacity and had a clear view of what remained to be done, we could predict fairly accurately what we could accomplish over the next 5 months.

One Year Later

After a year of sustained efforts, we delivered the first version of the application, a public website. Our last sprint was dedicated to bug fixing only. We expected that, as is the case with most multi-million-dollar projects, we’d be putting in massive amounts of overtime as we made the final push to go live. We did not have to work any overtime. None.
Why is that? We have some theories:

• Quality assurance (testing) was done as part of the sprints. Therefore most defects were already known, had been prioritized, and in most cases had already been fixed.
• Our capacity was well known and our estimates gained precision as the project went on. (We did find that we had to work to avoid the trap of overestimating tasks in order to make the sprints easier.)
• The business knew the application very well by the last sprint and we did not have major change requests. This helped us to stabilize the code and focus only on remaining bugs.

After the launch date, no priority 1 issues were reported. We also did not have any major complaints, which pleased us greatly as we were serving thousands of unique users a day and dozens of closed transactions. The iterative aspect of Scrum played a major role in this result. We addressed security, performance and functional issues long before the live date, which mitigated the impact of the changes we made.

From my experience, Scrum’s concepts are often viewed at first as an unreachable ideal. Self-organizing teams with facilitators in place of command-and-control managers sound great in theory, but organizations are predisposed to believe they won’t work in reality. What we found, though, was that Scrum’s common sense rules really do work, mainly because of their simplicity.

My advice is to try it before you dismiss it out of hand. We’re very glad we adopted it.

Scrum and the Recession: Why Scrum Is the Best Choice for Projects in Times of Crisis

By Rafael Sabbagh

The world faces one of the worst financial crises in history. Several European countries, the United States, and Japan are already in a state of recession. The International Monetary Fund (IMF) recently stated that the recession will continue to deepen and the recovery will be slower than in the past. As a consequence, emerging and developing economies such as India and Brazil will suffer massive net capital outflows. IMF also said in a forecast that the world economy will shrink 1.3 percent in 2009.

Forrester and Gartner predicted technology investments will suffer a drop of 3% or 4% in 2009, respectively. Particularly, spending on IT services will fall this year. Companies like Toshiba and Nokia recently reported losses or drastic profit drops, and plan to fire thousands of workers. Intel saw their stocks plunge. Even the internet giant Google, which seemed untouchable, reported its first-ever drop in quarterly profit and cut hundreds of jobs.

The New Scenario for Projects

In this environment of uncertainty and constant changes, project market players are facing resource rationalization, limited access to credit, margin pressure, and financial problems with most clients. The decision process becomes longer and the demand for projects is notably shrinking. This new configuration demands that organizations change the way they work in order to survive. A true paradigm shift is necessary. Surviving IT organizations will exhibit the following characteristics:

• Work well in rapidly changing environments, allowing frequent replanning;
• Focus on maximizing the client's return on investment (ROI);
• Help reduce time-to-production or time-to-market;
• Avoid wasted effort and time with subproducts and features that will never be used;
• Always deliver value to the client, even if the project needs to be halted before its end;
• Increase the communication and feedback between the project's stakeholders, so people will know what needs to be done and what's being done.

Scrum is a framework for project development that focuses on all those issues. Scrum is the best choice for projects in times of crisis.

Why Scrum?

Let's look at the players in the project market within a financial crisis context:

1. An organization or group that provides service on projects. It must increase competitiveness in order not to lose clients, both internal and external;
2. A director or manager needs to cut operational costs so that his organization may survive. He chooses to use internal projects focused on getting better results;
3. A client needs to outsource specific projects but needs to cut costs in order to keep them viable.

We will provide important arguments to help these parties (as well as other decision makers and those who can influence them) defend the choice of Scrum for their organizations in turbulent times.

No Waste!

Traditional methodologies spend a meaningful part of the cost and time of the project generating and maintaining massive documents. However, once complete, these artifacts are rarely updated as much as necessary, because changes occur faster than the team is able to keep them current. In the end, a great part of that documentation becomes useless and ends up being dismissed.

In The Enterprise and Scrum, Schwaber states that about 50% of a typical project's time (and money) is spent on requirements, architecture and specifications, and all that is done before building any functionality. However, 35% of the requirements change and 65% of the functionalities described by the requirements are never or rarely used. In times of crisis, such waste of time and effort is not acceptable.

Scrum reminds us that the objective of a project is the product - not the documentation. On Scrum, desired features are captured in a prioritized list called the Product Backlog. The exact specifications and design for each feature on this dynamic list is determined only a few weeks before it will actually be worked on. Features can be added, removed, or reprioritized throughout the course of a project. They are always kept in priority order. A new set of functionality is delivered at the end of each timeboxed iteration, or sprint. Therefore, whatever is delivered has a much better chance of actually being used by the client.

Better Value First!

On a typical waterfall project, the client may wait up to a year before he ever sees a finished product and begins to receive any return for his investment. In today's economic environment, companies can't always wait that long.

Scrum, on the other hand, delivers a return on investment at the end of each sprint. One of the Product Owner’s main roles is to maximize ROI by constantly updating and prioritizing the Product Backlog. This allows the items of most value for the client to be implemented first. Prioritizing the Product Backlog based on value allows the organization to stay competitive by delivering results to its clients faster than the other players, by putting in production functionalities that add better value to their businesses more quickly, or by launching products and new versions more frequently, so that they keep up with the inevitable market changes.

May Changes Come!

Speaking of inevitable market changes, at no time are there more sweeping and frequent market transformations than in times of crisis. Legislation and regulations are created, business rules change, new opportunities appear, important players leave the market, previously available budgets become scarce, companies face big losses, mergers and acquisitions increase, governments intervene to maintain stability.
For traditional methodologies, where change is undesirable, risky and expensive, this kind of upheaval is almost impossible to manage. It creates stress on the project team as well as stress on the relationship with the client.

Scrum follows the Agile Manifesto assertion that responding to change is more important than following a plan. Scrum maintains that change is a natural part of the development process. It has mechanisms in place to make change a constant, rather than a stressor. The dynamic nature of the Product Backlog allows client’s new requests to immediately be introduced on the product by the following sprint. Such quick response to change becomes a great competitive advantage, making it possible to turn a crisis into an opportunity.

Parcels or Partners?

On a typical waterfall project, the client is encouraged to participate at two times during the project: at the beginning for requirements analysis and in the end for the acceptance tests. The client perceives the project as a big package stamped "Do Not Open Until..." , whose contents will be revealed solely at the end of the process. Their only glimpse into the future product is through documentation, most of which is out of date or out of touch with changing requirements. In today's fast-paced, ever-changing market, it's unlikely that what the client asked for in the beginning will fulfill his needs in the end.

On a project that adopts Scrum, the Product Owner is always in touch with client to identify his needs and keep the Product Backlog constantly updated and prioritized. The client frequently gets new versions and can give feedback more quickly to the team through the Product Owner. The client feels involved with the whole process, sharing the responsibility over the project with the team, increasingly trusting the team and the process itself. The relationship with the client ceases being merely commercial and instead becomes a partnership, fostering complicity, satisfaction and fidelity. A long-term relationship is then developed with the client, which can often overcome strong periods of crisis.

Communication doesn't just happen between the product owner and the client. Everyone involved with the project is given a daily glimpse into what the team is doing. Daily meetings allow members of the team to show other members what they’ve done since the previous meeting and what they will do until the following one. The sprint backlog or kanban shows everybody all the activities yet to happen, those already happening, and those which are finished. Working in a collocated environment stimulates teams to communicate. Burndown charts show everyone the project’s progress. Frequent demos show the Product Owner what’s been produced and give opportunities for feedback.  Finally, retrospective meetings allow everyone to see what has worked on the sprint and what can be improved.

Keeping communication open between the project’s stakeholders is the best way to assure that everyone knows what needs to be done and what’s being done. That increases productivity, which is essential to surviving a crisis.

What if the Project Gets Suspended?

In times of crises, it is common for the budget to dry up or the supplier to leave the market during the project. When this happens on a non-agile project, what will the customer be able to deliver to the client?
If the project gets suspended right after the initial phase of specification, the client gets a series of documents that won’t be of any use to him. In case it happens in the middle of implementation, he will get incomplete and untested functionalities. Even if it happens in the middle of the tests phase, the product hardly will be trustworthy. In fact, chances are the client won’t be getting any return whatsoever on the investments made if the project is stopped prematurely.

A project with Scrum always produces an increment on the product which is potentially deliverable at the end of every sprint. If the project gets suspended at any moment, the client may utilize what has been generated on previous sprints, minimizing his risks. On an environment of uncertainties, that becomes an important competitive advantage.

What if You Have to Cut Down the Team?

In periods of crisis, it may be necessary to dismiss or relocate members of the team. With waterfall, roles inside the projects are very well defined. On an IT project, for instance, the programmer programs, the tester tests and so on. So, if the designer leaves the project, new windows will have no graphic design; if the tester leaves the project, it will go untested; and, worse of all, if the project manager leaves it, it will go ungoverned. Therefore, the whole project’s success is threatened by the loss of a team member.
With Scrum, responsibility over delivery belongs to the whole team, no matter the roles. Although there is a natural specialization, people are stimulated to develop and utilize their secondary abilities and, in general, will do their best to compensate for the lack of team members. This way, even with less capacity, the team can keep delivering.

It’s important to point out that firing members of the team must never be the first alternative for cutting costs. Shrinking the team also diminishes its capacity to deliver value. Consequently, the client will be less pleased and will search for suppliers that can provide him better service. That makes the organization’s situation worse, creating a vicious lose-lose cycle.

Conclusions

Scrum is the best choice for projects in times of crisis. It surpasses other methodologies for working well on an environment with constant changes, for frequently delivering better value to the client, by focusing on maximizing return on investment, by avoiding waste and prioritizing communication and visibility to what is important for the good developing of the project, and by creating a cross-functional team.

Once the crisis is over, organizations that adopted Scrum will be closer to their clients, focused on results, more compact, objective and transparent. To these organizations, the crisis will have worked like a propelling spring, so that when market recovery comes, these organizations will be ahead.

Tips for First-time ScrumMasters

By Tirthankar Barari

Most new ScrumMasters have a basic understanding of their new role. Many have been through training and received their Certified ScrumMaster designation. When their teams ask them to step in as ScrumMaster, they are often excited and eager.

But after the initial exuberance fades, a nagging doubt begins to form. Each day, while the ScrumMaster is listening to and facilitating the daily standups, a quiet thought begins to circulate in his mind:

The last day of my first Sprint is approaching soon. Are we going to deliver all the items we promised? What exactly do we demo, anyway? What if the thing crashes during the demo? Are we overlooking something? Did we misunderstand the requirements? Does the estimate of work remaining truly reflect reality? What if we hit a snag? Are we missing or overlooking any impediments?

Sound familiar?

If you are a first-time ScrumMaster it’s normal to have all of these concerns. Honestly, the more questions you have, the better. After all, while searching for the answers, chances are you will resolve issues before they bust, rather than after. From my own experience as a first-time ScrumMaster for a development team moving from a traditional software development process to Scrum, I have compiled a list of things you need to keep an eye on, almost all the time, during your sprints.

Bite off only what you can chew

During the sprint planning phase, as the team is committing to backlog items, help them question whether or not they can truly cover all the items. Typically, during planning, development team members have at least some tasks and items they know they will be working on. Individual team members will often know when they are being overloaded, but your job is to be an extra set of eyes. Make sure no one person is taking on too much and that the overall workload seems feasible. Ask questions and challenge assumptions. Bringing potential problems to light early helps mitigate the risk of over-promising and under-delivering to some extent.

You thought of apples, I gave you oranges

Many times, what the Product Owner when he wrote the user story is not at all what the UI designer or the developer understood it to be. Your job is to make sure they are all on the same page as early as possible in the sprint. As a follow-up to the marathon sprint planning meeting, make sure these players stay in sync and in agreement on each backlog item.

For complex backlog items or features, one of many ways to accomplish this is setup one or more mini demos along the way. These should be quick 10-to-15-minute presentations run from the workstation of the designer/architect/developer. Do not involve the whole team for this. Ideally, this mini demo should include one or two team members who have been working on the backlog item and the Product Owner. No fancy slides or preparation time. Keep it very informal. If it is difficult to get the Product Owner and others together for ten or fifteen minutes, you can accomplish something similar by circulating screen shots. The point is to keep the lines of communication open and receive feedback earlier rather than later.

Many people may have inhibitions against running mini demos, as opposed to one overarching demo at the end during review. But for large, complex features, periodic mini demos can be extremely helpful in catching discrepancies in understanding early on.

Plan to plan for the planning meeting

Issues that crop up time and time again during the Sprint Planning meeting include:

• The backlog item is not well defined, so how can we estimate?
• Is it really technically feasible?
• What is the scope of the work here? This, this and also that..? How about that other thing..?

One step that immensely helps in eliminating such drags during our planning meeting was to run a preplanning meeting. Certain things to keep in mind here.

• Do not involve the entire team in this meeting
• Try to schedule it as many days prior to the beginning of the next sprint as possible
• Include the Product Owner and some members of the team who might have more insight or prior knowledge on the features to be discussed

At the end of this meeting, the Product Owner should have shared many more specific details about the backlog items destined for the next sprint. These details should be captured and recorded so that when those inevitable questions about the scope of the work pop-up during effort estimation time, the answers are already there.

What we say standing up is what we do sitting down

Stress to the team that their fellow team members are depending on them to follow-through on what they commit to during the daily standup, and help them in their efforts to do that. I do not mean to imply that you should police or micromanage the team on what they do once they leave the daily standup. On the contrary, the team should manage itself. Team members will and should hold each other accountable to their public commitments.

So where do you come in? At times, team members become victims of external forces. They are pulled off to work on something else in parallel, or asked to start on something “more important.” It is your job to ensure that such distractions do not jeopardize the delivery of your sprint outputs. Other impediments can also stand in the way of delivery: maybe the machines are not in yet or the software or tools needed by development haven’t arrived yet. Sometimes the team members are shy or uncomfortable about bringing these kinds of impediments up during the daily standup meetings. Look for opportunities to encourage them to mention these obstacles. Once they do, help resolve them.

Plan the demo and demo the plan

If you happen to be the ScrumMaster of a team that is ushering in agile to the organization, your sprint plannings, standups, reviews, and retrospectives could garner interest and attention from many quarters. You may even have distinguished members of the organization sit in such activities occasionally. This is definitely good news, an indication that the organization is taking this new approach seriously. At the same time, though, it puts a little extra pressure on you to have your meetings, and especially your demo, go smoothly.
Just as actors have rehearsals before a performance, your team may need to practice before the live demo. Planning and rehearsing the demo would also help to uncover problems before they happen in front of a live audience.

Clearly, a rehearsal would be nice, but you do not want to spend much of the team’s valuable time on just this activity. They are busy executing the tasks in the backlog, right? So, spend some of your own time chalking out a plan for the demo. You have the backlog items already. Arrange them in a sequence you thing fit. Help setup a demo machine yourself, if need be. Then let the team members for each backlog item decide who will demo that feature. Since the members of a backlog item know the feature the best, they would hardly need any more time to prepare for the demo. You need to keep control on the sequence of the demo, the setup and the support. We have found a short plan that shows the list to be demonstrated and a quick meeting the day before the demo makes the review session a reasonably smooth sail. Also, keep backup plans, in case something fails at the eleventh hour (the “demo effect”).

Think end-to-end from beginning to end

Often during a sprint, all the individuals on the team are too focused on the immediate tasks in hand. There could be many interdependencies among features within your own team’s backlog items or with features from other Scrum teams. Issues related to these interdependencies may often get overlooked during the daily standup meetings or the scrum of scrum meetings.

It is vital for more complex system development that you (or another designee or even an end-to-end team for very large systems) keep track of these interdependencies along the way. It would serve you no good to learn on the last day of the sprint that a feature from team A needed a parameter to be passed by a feature from team B and it is not done yet. Many times, team B may not even be aware of the need, while it was quite obvious to team A. One way to bring these issues to the surface early on could be to visit and revisit the system flow in mini end-to-end review sessions (even by acting out the roles)

The organization is not for Scrum. Scrum is for the organization

Are we doing 100 percent Scrum 100 percent of the time? After all, according to line 7 of page 17 of this book from that author, we should complete this meeting within 3 hours, else we are violating the rules of Scrum. How many times have you, as the ScrumMaster, faced these questions, particularly during the early stages? Wish you had a scale to measure your ”Scrumness” that you could display on top of your desk or on your wiki page in real time?

Sometimes we forget the basic premise for doing Scrum. In the end, your customers will not pay the bills on how “Scrummy” you were. Certainly it is important to follow the guidelines defined in Scrum, but the ultimate goal is to deliver what you promised, within budget and on time. In that respect, Scrum is a great enabler and more of a means to an end rather than an end by itself. While you are helping your team follow the process, don’t get so caught up in the nitty-gritty details that lose sight of your organization’s goals.

Human Resources and Scrum: An Incremental Pathway to a Vibrant Organizational Culture

By Laszlo Szalvay

Historically, the function of the human resources department has been twofold: to police the organization for compliance and to help cultivate a vibrant culture in which employees can flourish by recruiting and retaining the best talent.

But as the global recession affects more and more companies, policing employees has taken a backseat to creating a workplace that is not dominated by fear, anxiety, and apathy.  A quick glance atHR Magazine’s editorial calendar reveals the next four issues will all focus on employee retention as a means to realize cultural improvement.  So how can human resources create an environment in which its employees are engaged, motivated, and empowered? Those familiar with Scrum will recognize those attributes as the same ones commonly used to describe self organizing teams.  Product Owners and teams working in Scrum environments already know that the Scrum framework can enable those benefits on the team level. But human resources departments need to wake up to the fact that Scrum can be leveraged to realize similar results at the organizational level.

In the recent report “Ensure Success for Agile Using Four Simple Steps,” Forrester researchers David D’Silva and David West conclude that “too many agile projects fail because the main focus of the implementation is not improving the way IT delivers software but instead simply adopting agile principles and practices.” The analysts’ observations are correct: Scrum and agile are means to an end; not ends in themselves. One of Scrum’s most essential “ends” is to create functional and rewarding workplaces where employees can pursue the work they love.  A vibrant culture that allows teams to create a better product, faster, is a very desirable end, both for the IT department and the company as a whole.

There is an intersection between human resources’ role in a company and what a successful Scrum implementation can yield.  It stands, then, that human resources departments should be working in tandem with the leaders of Scrum transformations so they coordinate end goals.

This article will consider three ways human resources can be involved in a Scrum transformation to ensure that end goals are aligned with company goals.  As a prerequisite, I would begin the transformation process by educating human resources on what Scrum is (from an “ends” perspective).  This could occur as an informal conversation about goals or as a more formalized training session.  There are many individuals who are certified by the Scrum Alliance¹  to perform ScrumMaster Certification training.  They are all capable of teaching not only the mechanics of Scrum and techniques to improve Scrum skills but also the important cultural benefits of team dynamics and workplace happiness.

Include Informed HR Representative as a Stakeholder in the Pilot Project.

The best way to convince management of Scrum’s value is to make the first few projects highly visible (something you can champion later to peers or supervisors).² I would argue that an organization’s first Scrum projects should also make cultural end goals visible and relate those goals to the human resources staff.  One way to do this is to invite the HR department to attend sprint retrospective meeting in a listen-only mode. Make sure to dedicate part of those meetings to sharing how the sprint brought the organization closer to achieving cultural end goals.  This “inside” view of how the team is achieving organizational end goals will help persuade skeptical stakeholders of Scrum’s inherent cultural improvements.  It will also help to legitimize Scrum from an orthogonal layer within the enterprise.  As other departments within the organization witness the team’s success, it provides a powerful testament of Scrum’s potential that can, in turn, translate to organizational support later on.

Create Scrum Career Paths.

Once the HR department is on board and measuring the team’s happiness meters, it’s time to sit down and discuss career paths. Because Scrum values teamwork over individual heroics most organizations will need to revise how they compensate their employees. While it would appear this issue is central to employee satisfaction, it's just as important to employers who want to secure and retain top level talent. Given that Scrum only identifies three roles in the framework, employers will want to find new ways to compensate and promote employees that allow them to grow professionally without contradicting Scrum values. Here are some recommended questions to get the conversation started:

• What does a ScrumMaster’s career path look like?
• If I am an intern and a team member, and the person to my left has 20+ years of experience and is also a team member, what is the pay scale and why?
• Should there be a formalized team bonus structure? Why?
• Who’s my functional manager? Why?
• Who does my performance reviews? Why?

I would not want to prescribe any answers to these questions (much of it will depend on company culture), but it’s important that Scrum roles are given legitimate career paths that are understood and embraced by human resources. It’s important to note that a Scrum implementation may indeed present at least a few headaches for HR and management, but who said Scrum was easy? Nobody.³

Get Better at Talent Acquisition.

When the qualities that will translate to success in Scrum are well understood by the human resources department, hiring the right person becomes a more involved process than simply reviewing a resume. Again, it is critical that stakeholders understand Scrum’s inherent cultural end goals in order to make informed hiring decisions. Being informed begins with a conversation between the recruiter and the hiring manager. We’ve all been there – a bunch of keyword-filled resumes that the corporate recruiter is pressuring you to review.  Instead of searching keyword placements on a resume, recruiters need to be educated about what it means to have a mentor on your Scrum team – how to translate teamwork and self-organization into a better culture. Like American Idol, some have it and others don’t.  One litmus test we used at Danube when we recruited about 20 employees (out of a pool of 200) for a large scale Scrum transformation was to ask them to write code. If they refused because of title and rank, they were immediately cut from consideration.  Another warning sign we avoided was a title request.  If a candidate demanded a certain title; we politely excused them from our recruiting process. We wanted hands-on doers, not jaded architects who were too important to be bothered to write code or help the team member next to them.  This might seem like an unusual approach to recruiting, but had we not screened potential hires for personality attributes as well as coding acumen, we could not have gone on to improve our end-client’s culture. 

As your goals for a successful Scrum transformation continue to expand to include a formal cultural improvement initiative, it is imperative that you continue to solicit support from different departments within your organization.  One department that could be a potential partner or sponsor is human resources.  Through successful alignment of your cultural end goals, you can bridge the gap by sharing tactics, mechanics and techniques to use Scrum to transform your organization’s culture into something vital.

The Sprint Review: Mastering the Art of Feedback

By Bob Schatz

The sprint review in Scrum is a critical part of the inspect and adapt cycle. Having worked with many teams and organizations, I have noticed an overall reluctance (and in some cases fear) to do them in the way they were intended.

First, let’s understand what the purpose of the sprint review is.  As my friend and mentor Ken Schwaber writes in his first two books, the sprint review is “a 4-hour informational meeting for the team to present to management, customers, users, and the Product Owner the product increment that is has built during the Sprint.”

Focus on the End User

Some companies are reluctant to involve their end users for fear of “scope creep,” others feel they aren’t allowed to ask the end users to be involved, and certain others don’t even know who the end user is! Whatever your reason for not involving them, find a way to do it.

That’s what we did at Primavera when we adopted Scrum back in 2003. We started off demonstrating mostly to our product managers, but we knew something was missing. So we kept thinking about how to increase the value of feedback we were getting, then the obvious solution emerged—we should involve our actual customers! Customer collaboration, remember? So, we started by inviting some of the customers we had always worked closely with and began to expand it little by little.

We had our own challenges to deal with in involving end users. For one thing, we had about 15 Scrum teams all working on the same release of our software. To help keep end users focused, we started using themes for each sprint. Each team had some piece of work that related to the Sprint theme. Having a theme helped end users tailor their feedback towards the theme for the sprint.

Our sprint reviews could best be described as being like science fairs at school. Each team set up a station where they demonstrated what they worked on. The end users, stakeholders, and a few others from our company formed small teams. Each reviewer team started at a different station. We ran 15-minute iterations moving reviewer teams from station to station.  It was an environment of high-energy, excitement, and fun.

Involve the Product Owner

You’ll notice that the product owner was not part of our reviewer teams. Instead, the Product Owner was actually responsible for presenting the project. This deviation from the original book definition of a sprint review greatly improved the dynamics of our sprint review.

Too many companies and projects set up their sprint review so that the team is presenting to the Product Owner, as if he should grade them or judge them on their work.  This is nonsense! The Sprint Review is not an inquisition or a court of law; it is a way to get feedback from the customer. Instead of presenting to “Judge Product Owner,” teams should instead work with the Product Owner during the sprint to review each story as it’s completed.

Then, when it’s time for the sprint review, the Product Owner should be the first person to stand up, welcome people, and give an overview of the state of the project. The Product Owner should discuss what the overall goals were for the Sprint, what was achieved/not achieved, the quality level of the product, and the release/product burndown.  He should then let the reviewers know what they should be looking for and how to provide the feedback.  After setting the stage, the  Product Owner turns the “show” over to the Scrum teams for the demonstration of functionality.

Understand Group Dynamics

Changing the sprint review audience from a lone product owner to a team or teams of stakeholders and end users dramatically alters the group dynamics. Let’s look at how these roles change once the product owner is part of the presenting team.

Product Owner: The Product Owner is put in a position where he now is acting as a true owner of the product. He has the responsibility and accountability, as part of the overall team, to present the results of their decision-making to the end users and stakeholders. He stands up and presents the product increment and gives insight into the state of the project. Knowing he must do this at the sprint review enforces the discipline to maintain a product/release burndown and know the quality level of the product. Another byproduct of this approach is that any discrepancies between the Product Owner’s representation of the end users’ needs and the actual needs of the end users will surface immediately.

Scrum Team: The Scrum team is now in a better position to present what they’ve done in the sprint with a sense of pride. They get time with the end user, in the best cases face-to-face time. The best way to develop good software that provides the most value to the end user is to know the end user. The team learns how to take feedback, and with every sprint they get a better appreciation for the people they are developing the system for.  Another ancillary benefit is that presenting to the end user takes away the feeling of being graded or judged by the Product Owner. Instead, the team leaves the review motivated and energized for the next sprint.

Company Executives/Stakeholders: When executives and stakeholders are invited to the review, they not only get a great view of the real status of the project, they also get to see their teams in action. Additionally, they get time with the end users to hear directly about their needs. Perhaps most importantly, they learn how to behave themselves. It’s amazing how different the dynamics are when customers are around. Instead of the criticizing and bickering that usually goes on, everyone is on their best behavior, so the review becomes much more productive and motivating.

End Users/Customers/Partners: The end users are the stars of the sprint review. They get valuable face time with the people that are developing the software. They come to feel like they are part of the development team. They are engaged. Because they have been so involved in the product’s development, once it is released and put into production, they are usually the product’s biggest supporters inside their own companies. Having knowledgeable advocates for the product at the customer site can also help reduce the usual flood of support calls that are typical immediately after release.

ScrumMaster: The ScrumMaster’s sole role in a sprint review is to facilitate. She makes sure the environment is set up for all of this great stuff to happen—that the right people, supplies, and facilities are there. And she makes sure the pizza is ordered. This may seem like a small detail, but don’t forget to feed people. Food is a great collaboration tool. We had some great conversations in the times where we shared some food.

Remember, this is not a ScrumMaster show. During the review, the ScrumMaster should support the teams, make sure the end users are welcomed and made to feel like part of the team, ensure that they get a chance to be heard, and stay behind the scenes.

Be Courageous

If you want to master the art of feedback, the first step is to create an environment that allows it to happen. It can be scary to involve the end users in the process but remember: it’s better to hear the feedback early and have time to make adjustments than to go down a long path only to find out it was the wrong one. Still afraid of scope creep? Let it go. First, the Product Owner will make the decisions on what trade-offs will be made after each sprint review; and second, you may find out more about what the end users don’t need, which will stop overproduction of features that may never be used.

Focus on the end user, create energy and excitement, and make your sprint reviews an event that your customers want to be there for. All you have to do is create a review that has direct value for them. Then just sit back and listen. You may be surprised by what you learn.

Top Ten Organizational Impediments

By Craig Larman and Bas Vodde

When we were writing the "Organization" chapter in Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum we asked a group of agile development experts working in and with large companies about the most challenging impediments their organizations faced. We aggregated their responses into a list of what we call the top ten organizational impediments.

10. Failure to Remove Organizational Impediments

Jeff Sutherland, co-creator of Scrum, considers the failure to remove organizational impediments to be the main obstacle facing large organizations. Common reasons for not removing impediments are "That's the way we've always done business" and "We won't change because we invested so much in this."

9. Misguided Cost Savings and Synergy Efforts

Peter Alfvin, an experienced development manager involved with introducing lean principles at Xerox, and Petri Haapio, head of the agile coaching department at Reaktor Innovations, both mentioned centralized departments looking for cost savings and synergy, leading to local optimization as an impediment. They offered several examples of these misguided efforts. The first was a centralized tool department that required all departments to use the same tool. This well-intentioned savings slowed development efforts for at least one group because the "mandatory tool" didn't fit the job they were doing. Also cited was a time when the so-called furniture police forced all groups to use cubicles in order to standardize and minimize cost. This led to inefficient workplaces for many teams. Another example was the IT department limiting video conferencing to lower network traffic, which hurt teams who depended on that method of communication.

8. Lack of Training

Sami Lilja, global coordinator of agile development activities at Nokia Siemens Networks, noticed that some organizations seem to consider learning a waste of time and money. Those organizations tend to educate and coach people only "when there is time for it." This distorted view results in a vicious fire-fighting cycle—mistakes made because of constricted developer skills, followed by hasty emergency repairs and a management team unwilling to allot time to analyze the causes of the mistakes, then more mistakes made.

7. Single-Function Groups

Larry Cai, a specialist at Ericsson Shanghai, mentions functional organizations (single-function groups) as one of the largest impediments to becoming agile. These single function groups create barriers for communication and abet finger-pointing among units.

6. Local vs Global Optimization

Esther Derby, consultant, coach, expert facilitator, and author of two books related to organizational learning, considers systems that foster local optimization over global optimization a major barrier to success. She gave several examples of these systems, including management by objectives(MBO)and budgeting systems.

5. Assumption that Book Learning is Enough

Mike Bria, a former agile coach at Siemens Medical Systems, mentioned what he called "do-it-yourself home improvement" as an impediment. He said that many people mistakenly believe that they "know how now" after reading one or two books, proving the truism that a little knowledge is a dangerous thing. These organizations usually do not bring in outside expertise, electing instead to do it themselves. Lasse Koskela, the author of Test-Driven, mentions a similar impediment, what he calls an "unwillingness to look outside the organization."

4. Individual Performance Evaluation and Reward

A trainer (name removed on request) at one of the largest e-commerce sites, mentioned individual performance evaluation and reward as a major obstacle he had noticed. These archaic practices frustrate developers and managers on agile teams, hinder team performance, and foster command-and-control management.

3. Unrealistic Promises

Lü Yi, an agile trainer and department manager of a large development group in Nokia Siemens Networks in Hangzhou, considers "commitment games" and unrealistic promises to be a leading organizational obstacle. Unrealistic expectations lead to shortcuts, continuous fire fighting, and legacy code. We cover this topic in more detail in the "Legacy Code" chapter of the companion book, Practices for Scaling Lean & Agile Development.

2. Assuming Agile Is All About Developers

Diana Larsen, expert facilitator and, together with Esther Derby, author of Agile Retrospectives cited this impediment, "Assuming it's all about developers." Too often, organizations mistakenly assume that agile and lean involves only developers. They don't understand that a successful move to agile requires a shift in thinking and behavior at multiple levels of the organization.

1. Silver bullet thinking and superficial adoption

Almost everybody we interviewed cited some version of silver bullet thinking and superficial adoption as an impediment. Dave Thomas, founder of OTI, large-scale lean product development consultant, and managing director of ObjectMentor, spoke eloquently about this problem. He said that many companies make the mistake of equating agility with productivity, rather than with adaptability. This, coupled with a lack of educated executives, leads to the mistaken notion that agility is some kind of silver bullet. This, in turn, fosters the belief that meaningful problems can be solved by saying "we do agile" and going through the motions of doing so, with no deep understanding or change by the leadership team. Ironically, because this behavior leads to no real change and no real result, these same organizations eventually abandon lean/agile principles because they "don't work."

A related impediment is the wishful thinking that significant improvement in large product groups can and will happen fast, within only a few years. In reality, significant improvement in large organizations can take five or ten years—if there is sustained executive support.

Our Two Cents Worth

After publishing this top ten list, we decided to add our own personal favorite organizational impediments to the list. The first impediment we have uncovered is a culture of individual workers rather than real teams and teamwork. Too many groups of individuals disguised as teams are ostensibly adopting Scrum, yet they still have the mindset of "Jill does Jill's tasks, Raj does Raj's tasks and so forth." These organization have yet to move as a whole team together, pairing and multi-learning within the group.

The second impediment we see is the gap between people in management roles and those doing the hands-on work. Frequently, changes made at the management level have no impact (or at least, no positive impact) whatsoever on the actual work. Similarly, decisions by hands-on developers are often not aligned with the direction of the organization. This gap is caused by managers who do not go and see the real place of work—sometimes because they have lost the skill to do so—and by developers who do not think outside their normal job responsibilities—they are "retired on the job." The gap leads to shallow agile and lean adoptions that happen either only on the management level—without any change in technical practices—or only on the development level—without any change in the organization. The lean practices of go and see and managers-as-teachers help to reduce this gap.

The replies from the agile development experts validated our own experience and acknowledged that we were covering the right topics. The remainder of the "Organization" chapter in the book explores these organizational obstacles and what you can do about them.

9 Tips for Creating a Good Sprint Backlog

By Luciano Félix

The sprint backlog is a simple list of the tasks that must executed by the team in order to deliver an increment of functional software at the end of that sprint. Sprint backlog creation happens in the second part of the sprint planning meeting with the participation of every team member. Giving some real attention to this process is fundamental to a better understanding by the team about what should be done and to better planning during the sprint. Despite this, many teams still struggle with this activity. I hope these tips will help.

1. Involve every team member in the process. It can’t be said enough: the involvement of every team member in the process of sprint backlog discovery is essential. On a multi-disciplinary team, everyone can contribute to task creation, enabling the team to draw from several different perspectives about the story. This generates a much richer Sprint Backlog than if only coders or a technical guru were involved.
2. Discuss how every item should be implemented. Before any tasks are written on post-its it's necessary for the team to spend some time discussing every story that will be brought into the sprint. In fact, the majority of the meeting should be dedicated to understanding how the team is going to tackle the stories. This discussion will involve creating basic designs, checking existing code, discussing architectural possibilities, and so on. Having a shared understanding about the story and the possible solutions will enable the team to create a task list that truly expresses the work to be done.
3. Have a definition of done. Having a common definition of done in place, available and visible to everyone is extremely important. This definition will serve as a guide to what should be done and will remind the team what the general acceptance criteria are for every item in the backlog.
4. Identify all kinds of tasks. Too many teams focus on coding tasks. The truth is, though, that coding is not enough to deliver real working software. The sprint backlog should include every kind of task: object modeling, coding, learning a new technology, database activities, tests, and so on. Having a posted definition of done will help to remind teams of the tasks they are forgetting. By listing every aspect of delivering working software and going through those tasks, the team will gain a new understanding of the real effort the next sprint will require.
5. Don't estimate tasks at all. This is a sensitive one. Estimating tasks in hours is popular and may be necessary when a team if first starting out. In the end, though, we can drop this without losing much. (See Alan Atlas’ article about this topic) The team commitment to the sprint should be done with the backlog items in mind, not the tasks. After all, if we estimate that a task will take 4 hours but it actually takes 12 hours, as long as the team achieves the sprint goal, what difference does it make? Identifying as many tasks as possible and creating a sense of constant progress during the sprint should be enough.
6. Don't assign tasks up front. Resist the temptation to direct work; the team should decide who is going to do what according to the circumstances. If you start to assign tasks to the “most suitable” team member, it will prevent the rest of the team from learning new things, block communication, and decrease collaboration. Empower and trust the team to manage themselves.
7. Review the sprint commitment. After task identification, when the team has a much better understanding about the real effort that is needed, the sprint commitment should be reanalyzed. Does the selected sprint backlog really fit in the sprint? If not, there are some alternatives. Drop the item with the lowest priority or split stories into smaller pieces. What matters in the end is that the team can commit to something they have a good understanding about.
8. Don't use too much time. Respect the time box. Define a meeting duration and stick to it. Timeboxing forces the team to concentrate and intensively discuss the items, making it much more likely that the tasks will be uncovered. The team cannot always identify everything that should be done during the sprint, but that's not a problem. It is much more important for them to gain a thorough understanding of the stories they are bringing into the sprint.
9. Evolve the Sprint Backlog during the sprint. The team will understand more about the stories as they work on them. New ideas may arise and old ideas may be dropped. The Sprint Backlog should reflect these changes. The Daily Scrum is an excellent time to create new tasks and lose unnecessary ones.

If the team invests the time and effort to build a good sprint backlog it will be rewarded with a much better overall understanding of the work to be done, a sense of progress on a daily basis, and a clear commitment to what will be delivered. It may not be easy, but it will be worth all the hard work.

Explaining the Sprint Budget Chart

The Sprint Budget Chart maps how a team consumes its budget over the length of the sprint relative to the planned budget consumption calculated by ScrumEdge. This chart is based on three variables, the Planned Budget, Budget Used and Actual Completed.

Planned Budget

Once sprint planning is complete and tasks have been assigned to Team Members, ScrumEdge calculates the Planned Budget by assigning a percentage value to each day of the sprint.

Planned Budget:

Planned Budget = Previous Day’s Planned Budget + (100 / Total Days in Sprint)

Example: If a team is working on a 10 day sprint their Planned Budget value will be calculated as follows:

Day 1: 0% + (100 / 10) = 10%

Day 2: 10% + (100 / 10) = 20%

Day 3: 20% + (100 / 10) = 30%

…

Day 10: 90% + (100 / 10) = 100%

Budget Used

The Budget Used line shows what percentage of the the planned budget a team member has used. It is calculated every day by dividing the total number of hours burnt till that day by the total number of hours estimated in the sprint.

Budget Used (Whole Team):

Budget Used = (Total Team Hours Burnt till this Day/ Total Team Hours Estimated in Sprint) * 100

Budget Used (Team Member):

Budget Used = (Total Member Hours Burnt till this Day / Total Member Hours Estimated in Sprint) * 100

Example: If a 2 team plans a sprint where their total task estimates are 100 and burns a total of 12 hours on the first day, and 15 hours on the second day their Budget Used for the first two days will be as follows:

Day 1: (12 / 100) * 100 = 12%

Day 2: (27 / 100) * 100 = 27%

Actual Completed

The Actual Completed line shows the percentage of actual work that is completed in the sprint and is calculated only when a task is completed. The Actual Completed is calculated by dividing the total estimates for completed tasks by the total number of hours that are estimated in the sprint.

Actual Completed (Whole Team):

Actual Completed = (Total Task Estimates for Completed Tasks/ Total Hours Estimated in Sprint) * 100

Actual Completed (Team Member):

Actual Completed = (Total Task Estimates for Completed Tasks for Member/ Total Member Hours Estimated in Sprint) * 100

Example: A team plans a 100 hour, 10 day sprint. 1 task with estimates equaling 7 hours is completed on Day 2 and another with estimates equaling 3 hours on Day 3. On Day 4 a task with estimates equaling 12 hours is complete. The Actual Burn for this sprint would be calculated as follows:

Day 1: (0 / 100) * 100 = 0%

Day 2: (7 / 100) * 100 = 7%

Day 3: (10 / 100) * 100 = 10%

Day 4: (22 / 100) * 100 = 22%

Analyzing the Budget Chart

If used properly the Budget Chart can be a powerful tool. During the course of a sprint, the ScrumMaster can use the Budget Chart to see how much of the plan budget their team uses every day and how much actual work is completed based against the team’s budget consumption.

If the Budget Used line goes over the Planned Budget line, the ScrumMaster should immediately recognize that the team is taking longer to complete tasks than they had estimated. However, this does not mean that the sprint is headed for disaster. It is normal for team members to go over their estimates from time to time. A good ScrumMaster should investigate further to see if this could actually a problem later on in the sprint.

The Actual Completed line is an important indicator of how much work is actually being completed through the sprint. There may be a case that the Budget Used and Planned Budget lines match up perfectly but the Actual Completed line hovers at 0%. This would indicate that the team is using up the time they had planned to spend on tasks, but not actually completing any tasks. It is normal for the Actual Completed line to hover close 0% at the start of the sprint and pick up as the sprint moves forward and tasks are completed.

It is important for ScrumMasters to understand these trends and facilitate the team members in completing committed tasks.

Explaining Sprint Burn Rate Charts

 
The Sprint Burn Rate chart maps the average number of hours a Scrum team burns over the length of the sprint relative to the required burn rate calculated by ScrumEdge. This chart is based on two variables, The Ideal Burn and the Team’s Burn.

Ideal Burn

Once sprint planning is complete and tasks have been assigned to Team Members, ScrumEdge calculates the Sprint’s Ideal Burn rate by adding up the total number of hours required to complete all tasks in the sprint and dividing these over the length of the sprint to get the average number of hours the team should be burning each day to complete their tasks.

Ideal Burn: (Whole Team)

Ideal Burn Rate = (Total Sprint Hours / Number of Days in Sprint) / Total Team Members

Ideal Burn: (Single Team Member)

Total Sprint Hours Assigned to Team Member / Number of Days in Sprint

Example: If a 2 man team plans a 10 day sprint and their total tasks estimates are 100 hours their Ideal Burn Rate would be as follows:

(100 / 10) / 2 = 5

The ideal burn rate stays constant through the course of the sprint.

Team’s Burn

The Team’s Burn is the average number of hours the team burns every day.

Team’s Burn: (Whole Team)

Team’s Burn = (Total Hours Burnt By Team / Number of Days) / Number of Team Members

Team’s Burn: (Single Team Member)

Team’s Burn = Total Hours Burnt By Team Member / Number of Days

Example: If a 2 member team was to burn 10 hours on Day 1, 15 hours on Day 2 and 20 hours on Day 3, their Burn Rates would be as follows:

Day 1: (10 / 1) / 2 = 5

Day 2: (25 / 2) / 2 = 6.25

Day 3: (45 / 3) / 2 = 7.5

The Team’s Burn Rate changes from day to day.

Ideal Burn vs. Team Burn

The Team’s Burn when mapped against the Ideal Burn should give the ScrumMaster an idea of how many hours their team is burning every day. The Ideal Burn tells the ScrumMaster how many hours the team committed to burn every day through to course of the sprint. On the other hand the Team’s Burn tells the ScrumMaster how many hours their team is burning every day.

It’s important to keep in mind that the Sprint Burn Rate Chart does not help predict the success of a sprint. A Scrum team may be working at ideal burn levels and still not complete tasks because of incorrect estimation. However, this chart does give the ScrumMaster an idea of  how much time each team member is spending working on a sprint everyday. If a member’s burn rate is well below the Ideal Burn this chart should help the ScrumMaster raise a red flag and investigate the matter.

Similarly if the Ideal Burn at the start of the sprint is higher than the team’s overall velocity, the ScrumMaster should note that the team may have overcommitted. At this point it would be a good idea to regroup with the team and if need be, revise their sprint plan.

Strategist: A New Role for Scrum Organizations?

By Srinivas Suravarapu

One vague area in Scrum is vision and strategy. Most discussions about Scrum fall within the boundaries of daily scrums and release plans. What is needed is more understanding of how Scrum and a company’s vision work together. To help senior management comprehend the limitations of Scrum and to help Scrum teams visualize the big picture, each organization that wants to implement Scrum needs a strategist –someone responsible for creating a level playing field where all stakeholders and participating parties in business can contribute and add more value. The strategist’s role should be to evaluate ever-changing market trends, sales, and the organization as a whole to make sure that what engineering builds is not just feasible but valuable.

Value, in this case, is not about metrics. Value is the perceived financial gain or goodwill that a product or innovation will create. Potential sales or new business are often used as measures of this value. It is important that a strategist be able to research this kind of data and have it available before taking up a project for implementation. Feasibility is equally important in determining value. Market opportunities must be balanced against organizational capabilities. Too often companies enter markets where they do not have sufficient capabilities to compete effectively. The strategist’s job is to act as ScrumMaster of the organization, recognizing the market opportunity but evaluating it against existing capabilities, not just of the engineering team but of the entire organization.

Scrum will help a team deliver a quality product but a Scrum team, in the end, can only deliver what it was asked to create. If what was asked for is too expensive given the current capabilities or not appropriate for the existing market, the company ultimately won’t receive the value for its investment. This isn’t the fault of the Scrum framework. It’s a function of garbage in, garbage out. A strategist is essential in a Scrum organization to ensure that the needs of the market are balanced against the capabilities of the organization.

You may wonder, isn’t this the product owner’s job? I don’t think so. Not only does the product owner have enough on his plate already, he is usually not in a high-enough position to be able to see the whole picture. The strategist must be someone in the organization who has a global view and a data analysis background: a traditional strategist or senior management executive. Below are several reasons why I recommend a strategist in addition to a product owner.

• The product owner is more intrinsically oriented to the development of the product. The product owner usually comes from a business analyst or project manager background. Taking on the strategist role would require that the product owner spend too much time away from the team.
• A traditional strategist operates agnostic to the technicalities of a product and bases her job around market trends. A strategist’s strengths are non-project-management areas such as market research and trend analysis.
• A strategist has the unique ability to translate market needs into terms of financial gain for the senior management team and into terms of engineering work for development. These two components create a road map for organizational prosperity.
• A strategist acts as a liaison between senior management and the product owner to streamline communication and help both parties make well-informed decisions.

Overall the strategist should enhance the value added by Scrum. Having a strategist ensures that what senior management envisions and what the engineering team paints are in harmony not only with each other but with the market as a whole.

Unlearn What You Have Learned: Ten Habits You Must Break To Be Successful with Scrum

By Nimesh Soni

In the Star Wars movie The Empire Strikes Back, Luke tries unsuccessfully to rescue his X-wing fighter from the swamp. After some time, he gives up. He tells Jedi Master Yoda that lifting the fighter is impossible with the force, the new approach Yoda is trying to teach him. Yoda has these words of wisdom for him:
“You must unlearn what you have learned.”
Scrum is no different! Like the Jedi force, the Scrum framework is conceptually easy; it’s putting Scrum into practice that is difficult. In order for a team to be successful, the team members must unlearn what they have learned so far in their careers.
Here are nine habits you must break in order to be truly successful with Scrum.

Habit One: Create email trails

Often, on traditional projects (i.e., waterfall), team members create trails—written proof to cover themselves. Scrum, like all agile methodologies, values communication and collaboration among team members. Individuals are encouraged to pair with other team members, discuss the story or task at hand, and drive it to completion (and not worry about getting it in writing). Team members must unlearn the mentality of creating a trail and learn to trust and depend on their teammates.

Habit Two: Use command and control

In traditional project management, the project manager uses a command and control approach to steer her project in a certain direction. She generally is responsible for the success or failure of the project. On Scrum projects, team members must learn to take collective ownership of the project. In turn, the project manager has to learn to facilitate and empower rather than dictate and drive.

Habit Three: Create disciplines and silos

On traditional projects, each team member is assigned certain tasks and is responsible for completing theses tasks. Generally, the tasks assigned are discipline-specific, focused on the primary skills of each team member. A systems analyst, for example, will be assigned only the tasks that relate to requirements gathering. This creates silos and requires hand-offs.

On a Scrum team, each member has to unlearn the tendency to specialize and instead should use pair programming and role sharing to expand his or her understanding. No more staying in your own lane. Scrum team members are encouraged to venture into others' lanes.

Habit Four: Be a hero

Our traditional work environment promotes heroism. An individual team member is applauded for her achievements on a project. This often encourages individuals to look after themselves. This behavior must be unlearned by the team members on a Scrum project. On Scrum teams, there are no heroes! For the greater good of the project, the team members must be willing to work with each other to drive the stories to completion. The team, as one unit, is responsible for success or failure of the project and must take the collective ownership of the project.

Habit Five: Sign off on a detailed requirements document

It is difficult for management to accept the fact that you can work on a project that has a fluid top line or scope. This is the most difficult trait to unlearn. On Scrum teams, we adjust the top line of the project at the end of every sprint. With each sprint, the team gets better, smarter, and learns more about the project and the environment. Based on what the team learns, the team adjusts the top line of the project.

Habit Six: Stick to the iron triangle

The traditional approach to project management refers to scope, schedule, and cost as the iron triangle. This iron triangle, though, is broken because it does not take into consideration the quality of the project deliverables. The requirements and priorities of the customers might change as they see more working software.  The management must unlearn the urge to box customers into committing to a pre-defined and well-documented set of requirements. Instead, Scrum teams should emphasize the quality of the product that the team creates through various levels of testing and inspections to achieve a done state. The team must learn to focus on quality and make it a central requirement of its work and deliverables.

Habit Seven: Be plan driven

The world is not standing still, so why should your project plan be written in stone? Traditional project management is very stubborn about setting the project plan and sticking to it no matter what. Project Managers spend many hours trying to come up with a perfect plan; the truth is, no project plan is ever going to be perfect. It might be perfect for the moment; however, the world is changing constantly. Your customer’s requirements and priorities will change, the work environment for the team will change—the plan must change in response. Management must learn to accept the truth of change, and allow teams to respond and adjust accordingly.

Habit Eight: Be IT driven

How many times (in your career) have you come across a situation where the IT management is driving the projects? Where IT is dictating what it can and can not do for the business? In Scrum, IT must learn to play a supporting role. The business must drive the projects (priorities, scope, what gets delivered and when—all to increase the ROI). IT should work with the Business to deliver the required artifacts. The Product Owner, thus, is the single most important factor for the success or failure of an agile project.

Habit Nine: Have a big bang delivery

With waterfall projects, you typically get a single, big-bang delivery, where the finished product is delivered to customers at the end of the project. The big misconception with the traditional waterfall approach is that any complexity can be effectively dealt with in a "big-bang" approach.
Scrum emphasizes the delivery of the product in an iterative manner. On a Scrum project, the team must learn evolutionary (and iterative) delivery of the product. With each delivery, the team learns from the customer’s feedback and communication of changed priorities. What the team learns is applied toward making subsequent deliveries better, delivering value to the customers, and in turn to the business.

Habit Ten: Tell teams “How,” not “What”

Management has learned to dictate how the team should complete the tasks at hand. In Scrum, management must unlearn this urge to tell the troops how to execute the tasks. Instead, they must learn to provide the priorities, and then trust the teams collective instinct and experience to complete the tasks. Let the troops on the front line (the folks who are actually going to work on the tasks) decide how to execute and get things done within the boundaries established by management.

Scrum is a simple framework, but executing it properly is not easy. You must unlearn certain long-held beliefs to be successful, and as we all know, breaking habits is never easy. Keep in mind the words of Jedi Master Obi-Wan Kenobi to Luke Skywalker: “Luke… Let go. Trust the force.”