9 Myths About Agile
Table of Contents
Agile development methods work both in IT and out of IT. In the time since the Manifesto was published, they have acquired ideas, stereotypes, superstitions, legends and myths.
Agile principles have transformed the development process and earned respect. The modern world is changing and evolving too fast - dozens of new solutions, applications and services appear every day. Agile methods enable companies to develop new products quickly enough to keep up with the pace of the market and of life, and to provide users with solutions to their problems as quickly as possible.
Agile is a philosophy of agile development, the principles of which are described in the Agile Manifesto for Software Development. The methods are based on four core values:
People and interaction are more important than processes and tools.
A working product is more important than comprehensive documentation.
Working with the customer is more important than agreeing contract terms.
Willingness to change is more important than sticking to the original plan.
Along with the popularity of Agile methodologies came stereotypes and myths that often prevent you from realising the essence of this approach and getting more value from it.
Myth #1: Agile only works for IT products/companies.
It isn’t. For example, Kanban came to the IT industry from Toyota, which used it to improve the speed and quality of new car production. There are a large number of non-IT companies that successfully apply Agile approaches. Agile methodologies are utilisied by banks, car manufacturers, telecoms executives and others.
Myth #2: Agile is not suitable for projects with fixed budgets.
There are many ways to work with a fixed budget. The only question is the relationship between the contractor and the customer. If you use Agile, you need to focus on solving the customer’s problem. This means that at the start of the project, the client and the contractor plan together and identify the key priorities for the product, but then nobody and nothing can stop them from identifying the most useful part of the product that the contractor can deliver within the budget. If regular demonstrations of the completed work are required, it will be possible to adjust the change process at short intervals and thus gain more leeway to regulate the costs of the project.
Myth #3: Implementing Agile will yield instant improvement.
This approach is very damaging. Every case and every company is different. And for each, you need to find an approach that will be effective in that particular case.
Agile will not take root anywhere:
- you have to follow a clear, detailed algorithm of actions to be successful;
- where there is no room for experimentation;
- where the cost of rework and revision is enormous or involves human sacrifice.
For example, building a power station, an aeroplane, a spaceship. These things cannot be done iteratively and incrementally as agile requires.
Myth #4: Agile methodologies do not overlap with each other.
It is necessary to separate the methodology from the tool. The methodology is an algorithm of the workflow. A tool is a component that is used in the algorithm. Different methodologies can include the same tools but combine them in different ways. For example, when using Scrum, some Kanban or XP tools are used. This is not unusual, as they all fulfil the values of Agile and make the workflow more flexible. But don’t think you can’t combine agile with waterfall. This is fine too - as long as you get an agile workflow out of it.
If we talk about specific Agile approaches that are the most common today, Scrum and Kanban are the most widely used. FDD, XP, RUP are used very rarely, or not in their entirety, but only partially in conjunction with another framework. The following methodologies can be used in companies today in full, in part or in a hybrid form:
- BDD, Behaviour-Driven Development
- RAD, Rapid Application Development
- DSDM, Dynamic Systems Development Methodology
- Scrum
- XP, Extreme Programming
- FDD, Feature-Driven Development
- RUP, Rational Unified Process
- Mobile-D
- SLeSS, Scrum and Lean Six Sigma
Myth #5. Scrum helps to make products quickly and cheaply.
Speed is hard to argue about, but cost is a very, very debatable point. Let’s look at what Scrum requires:
- form a full-fledged scrum team;
- provide it with 100% of the necessary competences;
- the team should be engaged in the development of only one product assigned to it;
- a product owner who can devote 50 to 80 per cent of his time only to this product and only to this team.
You will also need to get them together, provide a separate room, provide the necessary props for the team activities, etc. You also need to be aware that at least 8 hours of each sprint will be spent on communication, as Scrum involves a number of mandatory meetings.
You will have to make a significant investment to get the ultimate gain in speed and quality that Scrum offers. But believe me, it is worth it.
A sprint is a fixed period of time during which the team delivers a part of the product that is of value to the customer. In each sprint the team takes another step towards the project goal. A sprint usually lasts 2 weeks.
A sprint includes 4 mandatory meetings: planning, implementation, release, retrospective. In addition, there are short daily meetings (dailies) where team members synchronise and agree their next actions. No tasks can be added to an open sprint - this habituates the team to planning and protects them from management chaos.
Myth #6. Kanban is a board with tasks
Not at all. The board is only the first and simplest element of Kanban. The methodology is based on a mathematical apparatus based on statistical data. To talk about Kanban only as a board is not to look at what it really is. The main point of Kanban, in a nutshell, is:
- to make the current work process transparent and to cover all stages;
- from the origin of the task in the company to the transfer of the product to the end customer;
- to manage the workflow by identifying and eliminating time losses;
- to make management decisions based on metrics, not feelings.
Myth #7. Agile can be applied to any company and any project.
Firstly, we should remember what we talked about in Myth #3. Secondly, Agile is not about the administrative part of the process, it is about working with people. The implementation algorithm depends on the chosen framework.
For example, the success rate of implementing Scrum depends on the corporate culture. In a rigid hierarchical structure, where there may also be bureaucracy, no Scrum implementation will be successful unless it is supported by top management. Scrum implementation often starts with the company building a parallel structure based on a team approach, which is championed by a senior executive. This is followed by the more difficult task of spreading this culture throughout the organisation. There is no telling how long this process will take. However, research shows that for Scrum to be successfully implemented, about 30% of the organisation needs to follow it. Then the culture of this framework will spread without additional support and protection.
But Scrum implementation also requires changes in the way contractors are dealt with, the approach to budgeting, etc.
Kanban is simpler in that it does not require radical changes. It proposes to start with what is already there and improve it step by step. The speed of implementation and change in the company is much slower than Scrum, but the process is simpler and all changes are supported by statistics and have a clear justification.
Myth #8. Scrum is only applicable to creating a product from scratch.
There is no hard and fast rule that Scrum can be used for greenfield development. Transferring existing projects to Scrum is not only possible, but often makes sense. It all depends on the willingness of the performers and customers to restructure their work. If they are ready - everything will work out.
The creator of Scrum, Jeff Sutherland, in his book ‘Scrum: The Art of Doing Twice the Work in Half the Time’, tells how he applied Scrum to an automated data accounting system in the FBI. When he took on the project, development had been going on for 4 years and none of the features were in a usable state. He was able to accelerate the development and make it transparent to the customer. Six months later the first working version of the product was released and within two years the development was successfully completed.
In the 20 years since Jeff Sutherland and Ken Schweiber published their book and described the Scrum concept, the framework has spread beyond the IT industry to serve non-technology companies.
Myth #9. Implementing an agile methodology leads to conflicts with representatives of the classical hierarchy.
If everything is done properly, i.e. separating the team from the traditional hierarchy, giving the Product Owner a budget and hiring a good Scrum Master, there will be almost no conflicts. It is almost impossible to combine two different structures in one company. And there is only one way out: to build a new structure that ensures fast decision making and product delivery.
