Most software projects have been managed using a process known as waterfall. But, since the mid-90’s a revolution has been gathering pace and the Scrum framework is being adopted by organisations all over the World. Are you considering using Scrum? Here are my top 10 reasons why you should use Scrum instead of waterfall.

10. Scrum enables rapid reaction to changing customer requirements

Using the waterfall process, customers were required to state up-front, exactly what they wanted when asking for bespoke software development. Their requirements were written up in a specification document that was then used by the development team and testers to ensure that they provided precisely what the customer had asked for, no more and no less.

This approach operated on the expectation that customers knew what they wanted up-front. But, this was rarely the case and frequently customers would change their mind and request changes to the specification. There then followed discussions over who bore the cost of the change and the impact on the delivery date.

The more often it occurred, the less likely the software provider was to assume the costs, the more fractured the product became and the more difficult the relationship between the customer and the software provider became too.

Scrum not only recognises the problem, it addresses it up-front by:

a. Accepting that customers will change their mind

b. Actively embracing change

Additionally, scrum teams regularly and pro-actively invite customers to attend presentations on the product where they are encouraged to give feedback and request changes. This invariably leads to happier customers who also end up with a product that they want.

 9. Scrum teams possess all the required skills to get the job done

Most companies I’ve worked in have separate departments for software development, infrastructure, business analysis, testing and project management. Often, each of those departments has a different manager who has competing demands on his or her resources. The end result is that you’re often unable to get technical resources when you need them and getting them at short notice can prove almost impossible.

Scrum resolves this issue by requiring that a scrum team is both self-managing and possessed of all the technical skills it needs to get the job done. Essentially, scrum teams work autonomously and this gives them the ability to be hugely efficient. If you’d like to read more on this, I’ve written a separate article on why autonomous units are so effective.

8. Scrum teams incur less technical debt

When a software product is under development, the business comes under increasing pressure to deliver on-time. Any slip in the schedule is seen as a failure and, in an attempt to make sure that delivery happens on time, managers often feel pressured to cut things out of the development cycle. Because delays aren’t always obvious until nearer the delivery date, it’s the later elements of the software development life cycle that suffer and that’s usually development, testing and documentation.

If a product looks like it may be late, pressure builds and developers are asked to work harder. In trying to help, developers start to neglect items not directly related to coding, such as commenting code or refactoring. The rules governing the creation of tests by developers to test their code may be relaxed, the testing cycle may be cut and the need for documentation may be delayed. Usually a vague promise is made that these elements will be added back in after the product has been delivered but, experience shows that this rarely happens.

This set of missed work is referred to as technical debt and it’s a cancer eating at the software product from within. Software maintenance becomes harder because the code is sub-optimal and more complex than it needs to be. This poor quality leads to a greater strain being put on the support team who, in turn, make more demands of the maintenance team who are already overworked dealing with poor quality code.  Lack of documentation means that customers call the support team even more often, overworking an already overloaded system, and so on.

Scrum addresses this by requiring the scrum team to state their quality criterion up-front (referred to as the ‘definition of done’) and requiring them to meet that criterion for every iteration of the product (usually every 2 to 4 weeks). This way, quality does not suffer because its no longer at the tail end of the development life cycle. Simple but effective.

7. Scrum improves communication

Probably the best known element of Scrum is the daily standup. The meeting is attended by all scrum team members, who report to each other on three things:

a. What they have done since the last daily standup

b. What they will do before the next daily standup

c. Any impediments that they are facing

To encourage attendees to stay on-topic, meetings are limited to no more than 15 minutes. It’s an idea that works extremely well. By forcing the meeting to brief, attendees focus on what’s important and pay attention. Because they are reporting to each other (and deliberately not to ‘management’) there’s often a direct honesty about the real situation, enabling the team to get work done rather than waste time on politics.

Where daily standup meetings are intended only for the scrum team, the Scrum framework includes other meetings that involve both management and the client. They include the Sprint Planning Meeting, Sprint Retrospective and Sprint Review. Again, each meeting is time limited and focused and distractions are actively discouraged.

The improved communication that results from these meeting formats can, and often does, have a profound and positive effect on product development.

6. Scrum leads to better client relationships

In traditional software development, customers were involved in the software development process at three points:

a. Requirements gathering

b. User Acceptance Testing

c. Signoff

The big problem with this approach was the huge gap between requirements gathering and user acceptance testing. It was rare to have customer involvement during the development phase and in many cases, their involvement was actively discouraged. The primary reason for this was that the customer would often ask for changes during development and the traditional software development life cycle just wasn’t able to deal with this very well.

Scrum takes an entirely different approach. From the very start, a customer representative is involved in the project in the guise of the Product Owner. Then, at regular intervals (usually between 2 and 4 weeks) customers are invited to a Sprint Review meeting where the development team present the work they have done and pro-actively seek customer feedback.  This feedback is then fed directly into the next development cycle after which another Sprint Review meeting is held.  This process continues for the life of the project.

During the entire project life cycle, the customer is engaged and their wishes actively reflected in ongoing development. It puts the customer in control and the result is much improved harmony that benefits everyone involved.

5. Scrum improves personnel satisfaction and commitment

One of the major tenets of Scrum is that the business vests authority in the scrum team to get the job done. Essentially, the scrum team becomes an autonomous unit within the business. This is an immensely empowering act that most teams relish.

This, along with the improved likelihood of happier customers and ability to produce quality product in quick time, makes for a much happier workforce. As if that weren’t enough, the Scrum framework encourages active commitment from team members. For example, at the daily standup, team members report to the rest of the team on what they will be doing. This act encourages team members to meet their commitments to each other.

4. Scrum reduces time taken to get product to market

It’s often said that 80% of functionality in a software product is rarely, if ever, used. This means that a huge amount of development time is wasted.

Scrum actively avoids this problem by requiring that the most important features (as decided by the customer) are done up front and that less desirable features are moved further down the to-do list. In all likelihood, many of the less desirable features will never be implemented and that’s a very good thing. Why waste time and effort on something that’s not going to be used?

Scrum also requires that, once every 2 to 4 weeks, a potentially releasable product is built. The customer can decide to release the product if they wish and, depending on their requirement, this can often be sooner than was originally envisaged. For example, remember the first iPhone? When it was released, it had no copy and paste functionality. Many software pundits though this was a huge mistake on Apple’s part but, the market proved them wrong and Apple reaped the financial reward.

3. Scrum produces higher quality product

Before a Scrum team starts work, they agree on a definition of what ‘done’ means. It’s an important element and encompasses the level of quality that is acceptable to the team. Only work that meets this ‘definition of done’ is reported to the customer so, when the customer is shown a feature at the Sprint Review, it is not only feature complete, it’s also fully tested.

The massive improvement here, compared to traditional software development, is that quality is built-in up-front and not tacked on at the end of a project where it’s often trimmed to meet a delivery deadline.

The ramifications of this better quality are obvious. A higher quality product leads to happier customers, less drain on support, less work for software maintenance and happier team members. Additionally, there’s less technical debt meaning that the future of the product looks rosy.

2. Scrum succeeds by giving the customer what they need

A customer’s requirements for a software application evolve as time passes and as their experience with the product grows.  Traditional software projects don’t handle this very well. They’re designed to deliver what the customer asked for in the original specification.  If the customer asks for any changes, it usually generates a change requests and this can quickly become an administrative nightmare as well as a development headache. At the end of the project, the customer is asked to sign-off on the original specification and any added change requests, irrespective of whether the customers requirements have evolved.

Scrum manages this by pro-actively asking for customer feedback at regular points and reflecting customer wishes in upcoming work. The end result is a product that has evolved to meet the customer’s evolving needs leading to greater satisfaction for all involved.

1. Scrum increases productivity and lowers costs

My number one reason for using Scrum may well cause some scrum practitioners to snort in derision. They’re not really interested in higher productivity and lowered costs, they’re all about producing quality product that meets a customer’s needs. But the fact is that Scrum can only be successfully adopted where a business sees a clear and compelling reason to do so and what better reasons than these?

Adopting Scrum improves the productivity of your team for a number of reasons. Because you give them the tools, environment and authority to produce great product and remove any distractions that prevent them from doing so, improved productivity is a given. Productivity increases because team members are focused on their work and because they only expend effort on the most important features, as decided by the customer.

Costs are lowered because less time is wasted on unneeded product functionality and unnecessary meetings. Products are delivered faster and with less technical debt, reducing the cost of supporting the product.

Summary

These are my top ten reasons to use Scrum. Have I missed anything? Got anything wrong? Please let me know by adding a comment below.

Scrum training courses

Find out more about our Scrum training courses and book your Certified & Professional Scrum Courses with Derek Davidson, the first Scrum Trainer in Europe dual-certified by both the Scrum Alliance and Scrum.org