Does Agile equal Chaos?

With agile projects becoming more popular than waterfall projects, we are increasingly associating agility in software development with buzzwords such as "welcome change,” flexibility, “shorter time-to-market,” “self-reliant teams,” “higher staff motivation,” and many more. What sounds positive on paper at first is much harder to achieve than it often seems – but is beneficial if done right.

A truly agile transition of a company’s IT and business units is often a long and arduous process, full of pitfalls and drawbacks. However, becoming agile can be very rewarding, both from personal and business perspectives. Although there are many popular definitions of what “agility” really means (and many companies and agile practitioners put their  spin on those definitions), there is one thing for sure: Agility is NOT chaos!

What Agility is NOT

Agility does not mean that everyone is doing what they want, when they want, and how they want. It also does not mean that teams do not need leaders just because they are supposed to be self-organizing. It certainly does not mean to start working without thinking through and proper planning. It does not mean to react to every change immediately, just because one can.

Following Scrum, for example, agility means that you “only” react after every sprint, which usually lasts 2-4 weeks. During the sprint, all work items and agreements should be locked in, and nothing should be changed, added, or removed spontaneously.

If you adopt  a more Lean/Kanban style to organize your work, you  can immediately react to any changed circumstance and use the fast lane to implement it – but even then there is a limit on how much work can be done in the fast lane, at any given time.

Now, you might want to know why I state the obvious – but if my consulting experience as an agile practitioner has taught me something, it is that very often teams and organizations throw every rule and commitment overboard and just descend into chaos when trying to adapt to the agile principles.

What is the issue?

Discussing on a management level, I often feel that the perception of what agility is and how an organization adopts its principles is quite far from reality. The management usually focuses on the buzzwords but forgets the hard work required to achieve the benefits. Some managers tend to adopt a mind space where they believe that a team can switch its focus every other day and act accordingly by frequently changing team compositions or forcing new stories into the sprint-backlog, even if they have not been agreed or committed to, by the team. Others tend to encourage the agile transition but cut back on the budget for agile coaches, scrum masters, or training for their product owners and teams. Some think that certain roles are just overhead - either not needed or can be taken up in parallel by any team member.

Apart from management, let us look at the teams. By not adhering to things like timeboxing and definition of done - or  coming late to the stand-up repeatedly – teams can jeopardize their work as well. One team I worked with, together with management, decided to get rid of retrospectives permanently. They planned to use that time to implement more stories – even though they had not completed any sprint in which they fully finished their committed artifacts. So, instead of discussing why they could not finish their sprints and trying to take countermeasures, they committed to even more work which was not possible to finish – the resulting chaos was inevitable and followed almost immediately.

How is the chaos affecting us?

Take the scrum framework for example and look at all the rules, roles, and rituals described in it. Teams need an immense amount of discipline, honesty, openness, self-criticism, and willingness to take responsibility in order to adapt to a somewhat strict framework. At least in the first few sprints, teams should be guided and allowed to  stick to the rules and rituals to learn from their mistakes. The beauty of agility is, that teams can adopt the rules and rituals to fit their style, but the essence should be kept. If teams are interrupted in their endeavors from the start, they will never learn the “proper ways” – resulting in a chaotic style of working. Once the damage is done, it is challenging to get back on track. Negative mood and constant pressure from the management tends to spiral the team motivation and productivity further downwards. This is the moment where the agile critics in organizations come in to play and state that they always knew “agility doesn’t work.” This leads to the management rethinking their willingness to support an agile transition which in turn can split the employees into three groups - one that wants to adapt to agile principles, one that doesn’t, and one that doesn’t even care. If it comes to that, you have the perfect recipe for chaos, misunderstandings, blockades, and bad mood.

So, by doing things half-heartedly from the beginning or by adopting principles whose meanings are not fully understood, it can be challenging to get to a point where the organization can start to reap the rewards of agile software development. Often the opposite of what one sets out to achieve happens, making the software lifecycle even more inscrutable and harder to measure.

You can fix this!

First, you as an individual, your teams and stakeholders need to realize that you fell into the “Chaos-Trap” – this is often a difficult thing to acknowledge. Try to be honest about your ways of working and evaluate if your agile transition is running as planned. Talk to your colleagues, gather different points of view, and use regular, scheduled retrospectives to point out the issues, and discuss them. Keep in mind, every opinion is valuable. Especially at the beginning of agile transitions, it seems that you are running in chaos mode, but a healthy dose of uncertainty and disruption is perfectly normal and in fact, exactly what you need to change your company’s culture and the way you work. It is not easy to realize the moment when it might be too chaotic for a long stretch of time without any signs of getting into a more stable work mode. An experienced agile coach can prove to be a great asset here, preferably with a high degree of independence to provide a neutral view on the situation.

To improve the situation, be critical towards yourself, and challenge the way you and your team are doing things. Don’t be afraid to take a few steps back and try to do things properly once again – even if it means cutting down the backlog or reconsidering some decisions already made. Again, consider help from an outside coach, someone who is not a part of the problem. Be sure to keep communicating often and early about the steps that are taken to get back on track. One of the most important things in such a situation is to get the management on board, let them be part of the agile meetings, and involve them as much as possible. Only by having everyone’s commitment, there is a chance to get things going again. Don’t hide the fact that you, your team, or your organization have made mistakes – this is a part of the agile learning journey, and only by acknowledging the failures can you adapt and improve.