Home > Project Management, Team Building > Fears of Scrum

Fears of Scrum

Fears of Scrum

Major objections for moving from Waterfall Project to Scrum and how to address them

By Vitaly Dubravin

Scrum is a flavor of an agile software development methodology and is widely adopted by all major software shops. It cuts sharp corners of a “traditional” waterfall approach, eliminates unnecessary tensions and makes your development team very lean and efficient. I’ve started practicing Scrum several years ago when Kindle Innovations has decided to move ahead with a Facebook challenger – www.tabUp.com project. Everyone on the team had his own vision and understanding of the site to be, many ideas were similar in nature, but had “minor” differences in tactical approach. Even though our “final” scope at the beginning looked solid like a rock, we had to adapt to the Internet changing demands. TabUp today has only a few elements of the original idea and everything you see on the site is a response to the early birds and current users’ behaviors and suggestions. TabUp team got to the point where we can implement a feature within a few days from the suggestion and push it into production right away. This would be absolutely impossible to do without using Scrum.

I was so impressed by Scrum results on tabUp project that started evangelizing this approach to my other customers. Some of them had already adopted it, others are in the process of internal fighting with “natural” fears. This is what I’m going to review down below – Fears of Scrum.

Fear of Budget Crunch.

Many old-school financial managers are used to the idea of paying a bottom dollar for the product they need. It is proven to work for the stock items, but fails miserably when applied to the software development projects. It would be nice to limit your financial exposure and get a system you need, but the problem is that no one knows what is really necessary. And for that simple reason any initial financial estimates are wrong and will be changed later through the Change Request process. Guess which way the original budget will fluctuate? Shrink? Keep dreaming. Most IT projects cost 150% to 1,000% more at the end. I’ve described this process before in “Fixed Price IT Project – The avaricious pays twice?”. This clearly shows that delusional expectations of limited financial exposures are completely groundless.

Business people see even bigger budget threat when looking at scrum. How come you cannot tell the price of the system? I can, but it looks different from the way it used to be. Scrum team has fixed operational costs (budget) for each Sprint cycle and there is a tangible product to evaluate at the end. Number of cycles left is defined by the Product Backlog and can be quickly adjusted by Product Managers by adding or removing features from it. When a Product manager knows that there are only X dollars left in the budget, it means that only Y Sprint cycles can be approved. And that Product Backlog should be carefully reviewed to make sure important features with high priority fit into production schedule and all luxury items with lower priority may be postponed until better times. Sprint team will get to them, if time permits. There are no secret in-scope/out-of-scope negotiations, everything is on the table (actually on the wall) and expectations are well managed within the approved budget.

Fear of Scope Creep.

Scope creep is one of the biggest headaches for the Project Manager on a waterfall project. It is cause of tensions on the Steering Committee. Scrum eliminates the need to fight for scope. Some people say that there is no scope at all. This is not true. Scrum team has a clear and committed scope for the current Sprint cycle and an open-ended scope of features for the upcoming Spints. Long-term Scrum scope (Product Backlog) is “creepy” by its nature. But the short-term scope (Sprint Backlog) is solid. It is easy for implementation team to commit to the single Sprint scope (because it’s short) and any fluctuations are minor and are easily addressed with the team.

This notion of flexible scope makes it easy for the system users to request new features or even try two-three feature variations till the right mix of “ingredients” is found. It is not always possible to comprehend the feature till you use it and Scrum allows fast changes without painful Change Request process. Business people can get new features right away (almost) and not in the next 3 month or a year.

Fear of Loss of Power.

Project Manager on a traditional (Waterfall) project has almost God’s power. He is accountable for absolutely every move on the project and project failure is always considered his personal fault. That is why many Project Managers behave like dictators when it comes to the decision making. It is not rare to hear from a Project Manager: “Because I said so!”

There is no Project Manager on the Scrum project, and there is no cult of personality because of that. Scrum team has a Scrum Master. His is role is to ensure everyone is working at peak performance and there are no obstacles to slow down the team. Scrum Master is not the Boss, but a helping hand for every team member. He is a leader, not a manager, he motivates, not orders. Not every Project Manager is ready for motivational management, but many are. There is absolutely no resistance from the team. Everyone wishes to be treated as an individual, not as a slave.

Fear of Engagement.

End-users are rarely involved in a system creation. They may be a part of initial requirements gathering and participate in acceptance procedure. Everyone is very busy and do not have time to work with the project team. Waterfall approach is “fine” with that. But it leads to an unpleasant result – accepted system matches approved requirements, but are not very friendly to the actual users. Or the requirements are already outdated and the system has to be changed again to reflect recent business moves.

Scrum assumes deeper end-user involvement into the process. First of all, there is always something ready for production deployment at the end of each Sprint, whose acceptance process happens every few weeks. Second, Scrum team is glad to get a feedback as soon as a new feature (may be not fully functioning) is added to the daily build. It helps to stay on the same page with the user of the feature, make fine-tuning on the fly and avoid unnecessary development efforts. End users are getting exactly what they need and developers can implement even more features for more users. Clear win-win case. Simply have to convince users to participate and contribute. Scrum Master and Product Manager will balance end user disturbance, but it is more intense than users used to see.

Fear of Fuzzy Deadlines.

There is common misunderstanding that it is impossible to tell when the system will be ready, as if there are no deadlines in Scrum. The reality is completely different. There is a deadline defined for each Sprint cycle and a set of features, fine-tuned by the end-users, ready for deployment. Instead of having one Big Bang deployment on a specific date, Scrum team has micro-releases every few weeks.

Scrum is designed to meet micro-deadlines. There are no sleepless nights at the end of the project, no religious monitoring of the Critical Path. Even completely disorganized person works harder when the deadline is approaching and there is no luxury of a few month long phases in Scrum. Moreover, team can see individual performance issues and will jump in within a day or two to either help this person or initiate a replacement. Team may have to work extra to meet every micro deadline, but all extra efforts are motivated by the prior individual and team commitment, not by the management decisions.

Primal Fear – Ultimate Fear of Change.

Scrum is a change to the corporate culture. It drastically accelerates system implementation, but requires new internal processes. It also rewards active and innovative people and punishes office plankton. Company gets leaner, but more efficient. It raises morale and promotes team spirit.

Scrum’s openness and transparency are a new way of doing business. It is a Change and faces “natural” resistance. Previously established procedures have to be modified, organization structure may require reshaping, power will be redistributed and some folks may lose their jobs. Tough, but doable. Use Scrum philosophy to deploy Scrum. Explain every step of the process and gain understanding from each individual. Some folks may disagree and leave, but other will be committed to the success of this transformation. You will no longer see silent slaves, but highly motivated individuals committed to the success of this endeavor.

This is a price to pay in order to stay fit and remain ahead of competitors.

(originally posted on CIO.com)

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: