Agile Coach Online

Expert support on demand

Agile Coach Online Logo

Misconceptions about Agile

These are just a few of the most common ideas which people can hold about agile and which can inhibit developing good agile. If you think about it, Agile would not be much good as a way to develop solutions if any of these mis-conceptions were true. This section is not trying to explain the detail of how to deal with these issues, but to make clear why they are issues and why they need to be thought about.

Agile is Anarchy

To an observer outside an Agile team, things can look like anarchy. There is no strict hierarchical decision-making and individuals often make their own decisions about what to do next and how to do it. It can look a bit like each person is doing what they want.

In addition, one of the big areas where Agile adds value is by being responsive to changes in user needs and business requirements. Instead of developing a complete, up-front, detailed specification of what is being delivered, we get 'just enough' detail and continuously adjust and improve what we are delivering as we learn more and get feedback from users and stakeholders. This can easily be mis-interpreted as allowing anyone to change anything at any time.

This is not dis-organisation, lack of discipline or anarchy. Teams can work in this way because there are very clear approaches to embracing and managing change in the work and requirements. They look different from more traditional approaches but are an essential part of having a successful team delivering well. While the details vary depending on which agile methodologies are being used in a particular case, there are some key ideas that we stick to:

This works because Agile teams are self-managing and working towards shared goals with shared responsibility. No single person can over-ride the decisions and commitments that the team make together. Teams will have clear processes in place for refining work requirements, planning ahead, making near-future commitments and managing change. It is essential that stakeholders working with the team understand these processes and work with them. This is how we maintain well-structured and responsive working. The result is an effective, distributed and structured system for planning and delivering solutions.

Teams are normally supported in achieving these things and keeping on track by a few 'special' roles - such as Scrum Master or non-scrum equivalent (representing good Agile working), Product Owner (representing the business), Technical Lead (representing good techical decisions such as architecture and standards). These roles are not the same as managers in those areas making decisions on behalf of the team, they are roles which inform and guide the team in delivering effectively. Events such as 'stand-ups', 'planning sessions', 'review sessions' and 'issue-based workshops' are examples of how we support these team processes.

There is no planning in Agile

There are rare occasions where a single team is working on a 'blue sky' project with no constraints on time, resource or what is delivered. For everything else, large scale planning is essential.

Fine grain planning for the immediate future is handled by the team as described in the previous section. It is part of being self-managing. There is no need for anyone outside the team to look 'inside' the team processes for that level of planning unless something goes wrong. Trust the team to do their job or escalate an issue if they cannot resolve it. This is much like "Management by Exception" - a technique that has been around for almost 100 years. It is also important to note that the fine-grain units of work a team uses (e.g. stories, epics, tasks) are not the appropriate things to use when dealing with higher level and longer range planning. These small work items are continuously being created, modified, split, joined, resized or abandoned. That is a natural part of agile processes and good work management.

In any but the most trivial case, higher level plans are needed. These plans can be used for many things including:

For a stakeholder, the goal of these plans can be concisely summarised as:

"I want to know that the solution being delivered is appropriate, will be delivered in a timely manner and will be delivered within the available resources"

This is all essential stuff. No-one who has worked in a large organisation would question the necessity for doing these things. Agile happily embraces them, but applies Agile thinking to look at them from a different perspective. In particular by being responsive to change, recognising that a complete up-front specification of a solution is rarely valid, and making good use of the team expertise lead to achieving these things in different ways than a traditional hierarchical and waterfall approach. Here are some key differences.

The above approach can satisfy the need for forward planning in the organisation without inhibiting the flexibility and effectiveness of Agile. Failing to do any of the above will reduce the agility and effectiveness of the teams.

Agile is incompatible with large organisations

Much of the early work on Agile focused on small teams working independently. The team takes responsibility for everything that they do. We want to maintain this as much as possible, but when a team is part of a larger organisation and/or set of teams working together there are clearly interactions between an individual team and the wider context. It is necessary to balance certain areas between centralised/organisation-wide control and monitoring and the devolved responibility of the teams. Areas where we have to do this might include:

Each organisation needs to find the best way to deal with these things while retaining the value that Agile adds. Deconstructing the existing hierarchy is one of the most difficult areas of change for a large organisation. There are examples of it being done successfully at highly regulated organisations (e.g. finance sector) and traditionally highly centralised organisations (e.g. central government), so it is certainly possible in pretty much all environments. If these sectors can do it, anyone can. The key is to work out what needs to be managed or monitored centrally and keeping that to the viable minimum. Distinguishing what needs to be done centrally, as opposed to what is currently done centrally is a significant change in thinking.

Here are a few aspects to consider:

Agile does not involve requirements, specification, design

At one extreme we have very traditional models in which reaching a solution involves capturing all requirements, then specifying a solution in full detail, then giving that specification to teams to develop, and then testing it. There are lots of reasons why this is ineffective and sometimes plain wrong.

At the other extreme, we can imagine a model where we do not do these things at all, or do them only at the last minute as we are building a solution. This is a caricature of what some people imagine happens in Agile. It is not how Agile really works.

The key is to make decisions at the latest sensible time. This is the time that satisfies the needs of all the participants in the most effective way. It is different for different decisions on each piece of work. Requirements, Specification and Design are all part of this process.

Agile is a magic fix for everything

While most of the above mis-conceptions concern negative views about Agile, it is also sometimes the case that people go the other way and 'over-sell' Agile as being the solution to everything. This is not the case. Deciding to become Agile is the start of a journey, not the end. It requires thinking about the specifics of a given organisation, team and product and working out the best approach to realise the benefits in that context. It is also an ongoing process of continuous improvement and learning. There is no 'end point' to an Agile journey.

There is no single 'right way' to be Agile, but there are plenty of wrong things that should be avoided. These are some ways organisations reduce or nullify the benefits of a more Agile approach: