Scrum is Often a Waste of Money

The Intent of Scrum

Scrum allows development organisations to invest a little time at regular intervals to allow teams with autonomy over their work to identify and enact frequent, small improvements to the process and the plan. Over time, like regular payments into a savings account, these improvements build up and are compounded to produce high returns in the form of a mature, responsive team, building a relevant and valuable product. To achieve this, time is allocated at regular intervals to inspect and adapt the plan for the sprint; day; and release, and to improve the process:

This is not free: taking a whole team away from their work for several hours a month is an overhead. The Scrum framework caps the time allocated to sprint planning, daily scrums, reviews, and retrospectives at 20 hours for a 4 week sprint (proportionally less for shorter sprints) which represents just over 12% of the entire development effort. It is also suggested that up to 10% of the capacity for the whole team may be spent refining future product backlog items so that they are well understood. These timings are maximums and in practice the actual time spent is likely to be less, but nonetheless the time all adds up:

If done well, this investment pays off. New teams quickly identify and correct obvious problems, while mature teams keep themselves sharp and push the boundaries of their technical and collaborative practices. Release plans are put together quickly without undue commitment to delivering “on time, on budget” or solving all of the technical uncertainties up-front; freeing teams to make decisions at the last responsible moment and constantly re-adjust the plan to optimise value.

The reality of Scrum half-implemented

The trouble is, there is often very little attention paid to the effectiveness of these events. Ask yourself the following questions:

• What was the last tangible improvement to arise from a retrospective?


• How often do sprint reviews result in a revised release plan, ideas for more valuable features, or any form of change arising from new information that has come to light?


• During the daily scrum, are the development team truly in control of their plan for the sprint; taking pro-active steps if the plan is not going as expected?

You don’t have the answers?

If you struggle to find answers to these questions, then it is likely the time you are spending implementing basic Scrum practices is a waste of money. We’ve observed the following common issues getting in the way:

1. Split accountability – meaning no single person is accountable for the present situation.


2. Issues with your process come up time and time again, but the team has no authority or budget to resolve them.


3. Business representatives are distant and/or stuck in traditional a project management mind set.


4. Product owners are either constantly over-ruled and lack authority; or are senior enough to make decisions but busy running an entire department.


5. Development teams are not trusted to own the technical implementation and, as a result, feel less accountable for organising themselves.


6. Backlog items are regularly carried over from one sprint to the next with no questions asked, and there are no feedback loops to improve forecasting during sprint planning.

The common trend in all of the above is a lack of belief at all levels of the organization in the agile principles that underpin Scrum. Most organizations undertake an agile transformation with Scrum in order to gain competitive advantage, but unless the whole development organization embrace the principles and not just the practices, then the results could be worse than before you started. Time spent in Scrum events, combined with the challenge of working in teams of mixed specialisms, will reduce staff utilization without enabling positive change:

What to do next?

Option 1: Give up.

Accept the fact that agility in not a good fit for your organization, at least for now. In your conversation with the senior leadership team you may not convince them to accept fundamental principles – such as the advantages of responding to change over following a rigid plan. If this is the case, it would be more transparent and fair to the people doing the work to carry on with the established project management framework.

Option 2: Fully commit.

Organise a means of getting the Scrum team(s) together with the business and re-establish a sense of purpose. Ask questions like “should we be doing Scrum?” and if so, identify the drivers for achieving an agile capability that are specific to your organization. Once a sense of renewed purpose has been established, the proper execution of the Scrum framework provides a foundation for addressing all of the problems outlined above.

How to make it work: Build a culture of positive accountability

At the heart of the Scrum framework are three roles, each with very clear accountabilities. A culture of positive accountability is built on a foundation of trust and respect; allowing people to challenge each other productively without blame. As a result, pointless meetings and long-term inefficiencies have nowhere to hide. Here’s how you can contribute to establishing such a culture:

Scrum Master

If you are a Scrum Master, you are accountable for managing the process and should feel empowered to draw attention to poorly performing elements.

• Make sources of apathy or disengagement visible and don’t allow people to avoid discussing awkward problems.


• Facilitate regular retrospectives to allow all elements of the process to be called into question and improved.

Product Owner

If you are a Product Owner, you are accountable for maximising the value of the product.

• Start by developing a clear vision and strategy for what your product should be and what outcomes you want to achieve in the medium-long term.


• Do not accept anything that is getting in the way of realising this vision.


• Hold your Scrum Master to account if the process is not supporting your ability to capitalise on market opportunities.


• Hold your Development Team to account if you are not getting good engagement from them. You should expect a collaborative relationship with good quality technical options, reasonably accurate forecasts (depending on size and complexity) and a professional approach to software quality.

Developer

If you are a Developer, you are accountable for building valuable, high-quality software.

• If you are not sure why a feature is valuable, ask your Product Owner to explain the business context and hold them to account if you feel something hasn’t been thought through.


• Push back with the support of your Scrum Master if you come under pressure to cut quality to hit short-term deadlines.


• If you see one of your team-mates cutting corners, hold each other to account within the team. Try to create a sense of pride and ownership in the product you build.

Leader

If you are a leader, you are accountable for the culture you promote and the outcomes that arise from it.

• Make it clear what you expect from people, and give authority and autonomy to the people that are accountable.


• Ensure that everyone has the support, training and opportunity to grow into their new roles.


• Demonstrate the behaviours that you want to encourage in your team such as openness and respect, while holding yourself and others to account.

It is likely that it will take time to achieve high performance. Building a great team, just like building a great product, is best achieved in small, incremental stages.

Scrum half-implemented in not an option!

Source: B2C