Deconstructing Being Agile

Agile vs. Being Agile

Agile became popular shortly after ‘The Agile Software Development Manifesto’ was published in 2001. Companies focused on being agile saw great success, and others wanted to follow suit. Organizations began looking to consultants to help them become more agile, and the Agile industry was born.

The Agile industry has taken the principles of the manifesto and added on an ever-growing set of processes and tools. It has reached the state that Dave Thomas, one of the creators of the Agile Manifesto, has declared Agile as dead, stating that the values of being agile have been totally lost behind the implementation.

Blindly adopting Agile is not a guarantee that a team will be agile, as these additional Agile rules are not essential to being agile. For example, Scrum and Kanban are excellent tools, but teams outside of software development may find zero use for them.

Process should adapt to the environment, not the other way around. This is why one-size-fits-all Agile solutions are a bad idea. Just because a set of rules worked for one team does not guarantee they will work for another. Focus should shift away from Agile processes, and back to the principles of being agile.

The Principles of Being Agile

The idea behind the Agile Manifesto was to share a few principles based on agility. Agility by definition is thinking, understanding, and moving quickly.

As Ray Dalio explains in his book Principles:

Principles are fundamental truths that serve as the foundations for behavior…They can be applied again and again in similar situations to help you achieve your goals.

While tools and processes change over time and across business environments, principles will remain consistent. Principles guide process.

Businesses are aiming to achieve long term goals, while operating in complex, evolving environments. Constant change can make it difficult to stay on the desired path. A thorough understanding of the principles of being agile will act as a guide through uncertainty, keeping you on track for hitting long term goals.

Principle 1: Constant Evaluation and Adaptation

Constant evaluation allows a person to recognize when something is wrong, course correct, and ensure that the business is continuously moving in the right direction.

Being agile is not meant to be limited to the development team. Unless being agile is a core focus across the organization, bottlenecks (the arch-enemy of agility) will form.

This is the reason the lean framework works well with helping teams be agile. It’s simple, can be used by any business team, and focuses on the building blocks of being agile: build, measure, learn.

• Build: Work towards a long term goal
• Measure and Learn: Continuously validate that progress is on track, typically through user feedback

The things that pull progress off track depend on the environment. This is why the additional Agile rules that one team uses may not benefit another. What will never change is the need to recognize issues, learn from them, and course correct.

Principle 2: Limit Complexity

Complexity and agility have an inverse relationship. The more complex an environment or process becomes, the less adaptable it is. This is the basis of Ashby’s law.

When more complexity is added to an environment, two major things happen:

1. The product becomes harder to change going forward, as there are more moving parts.

2. The organization must grow to match the products complexity. More people are needed to maintain it.

When making product decisions its often best to choose the least complex option.

Principle 3: Limit Bottlenecks Through Decision Making

Decision making is the crux of agility as it keeps work moving. In a state of constant learning, many decisions will be made around which direction to take next. A lack of decision making creates bottlenecks, which stops work.

No matter how pragmatic of an approach taken when making decisions, there will be things that happen that were not accounted for. Some poor outcomes are going to happen, and that’s alright. What’s important is learning from them.

Decision making is a skill, and skills can be refined. If a bad decision is made, own it, and learn from it. Through learning, the next time a similar decision is faced, the outcome is more likely to be positive.

Principle 4: Understand Your Environment

A common misconception is that being agile is operating in a chaotic manner. This couldn’t be further from the truth. Chaotic environments are hard to control, agility requires a level of control. Being agile is thinking and understanding quickly. Operating with a low understanding of the environment results in poor decisions, and poor decisions slow you down.

Control over an environment can be increased through process and rules. The essence of being agile is adding the lightest business process possible, which allows for easier adaptation and change as the business environment evolves.

Rules Beyond the Principles

Agile rules are constantly compounding, leading to a lot of confusion as to which are best for your team. Before committing to anything, it’s important to experiment with these rules to ensure they are adding value your team.

For example, how do you decide between using Scrum or Kanban? The best answer is to experiment with both, and find what works best for your team. Realistically you‘ll likely have good results using either. You may even find that neither work, and come up with your own project management method, which is also great (and I’d like to hear about it!).

Knowing that being agile is rooted in core principles will help you cut through the noise. This is backed by the Pareto principle, AKA the 80/20 rule. The principle states that 80% of your results stem from 20% of your actions.

Once the 20% of total effort has been consumed, any additional focus has greatly diminished results. It’s more productive to shift that additional focus to something more important in order to maximize ROI on our time, as time is the most valuable asset we have.

The further the rule is separated from the principles of being agile, the less relevant it becomes, and the less time and consideration it warrants.

Beware of Echo Chambers and Silos

People new to product leadership may fall into the Echo Chamber trap. They believe that because a successful product used certain Agile rules, they should blindly adopt those rules as well. This can result in adopting a set of processes without understanding the total business impact.

The desire of the human ego to validate a decision can lead to Confirmation bias — looking for any validation that their decision was right, and ignoring conflicting opinions. This can include suggestions for improvements from team members. It can also cause internal conflict between teams that have a slightly different view of being agile. It’s a vicious cycle.

Focus on the Things that Matter

Start with the basics, be lean, and add tools that you believe will give you operational efficiencies. Evaluate the tools often. Some will work, others won’t, adapt and refine as needed. As soon as you adhere to a set of hard and fast rules, you lock in the way you operate, and become inflexible.

Set long term goals, work towards them, and constantly validate that you are on track. If you happen to stray off path, pivot back towards the goal. Keep a principle-first mindset, let them guide any additional process needed, and you’re on the path of being agile. There’s beauty in simplicity.

Thanks for reading!

If you liked this article check out a few of my others, and feel free to connect with me on Twitter.