Thinking Beyond the Agile Manifesto – Agnostic Agility

By Joshua Render on October 22, 2018 • ( 1 Comment )

There are many sources available that discuss Agile and Agile principles. One of the most well-known is the Manifesto For Agile Software Development, which is commonly known as the Agile Manifesto. This includes the 12 Principles behind the manifesto.

I personally have some issues with the Agile Manifesto, one of which includes the dedication to software development – when Agile practices can be used in non-software and non-project work. I have a preference for the principles of Agnostic Agile, which are not dedicated to a framework, software development, or iterative projects.

The first thing you may notice is that it doesn’t require or lay out a lot of things that seem restricting about the Agile Manifesto. It doesn’t try to define your environment and places more of the focus on doing the best thing rather than doing a specific thing.

The 12 Principles of Agnostic Agile Are:

1. To put my customer first, making them independent.

Whether it is your direct employer or a customer of your employer (or you are self-employed and your employer is your customer), the goal of Agile is to place the focus on the business requirements. What will work best for your customer or employer?

2. To do my best, complementing theory with practical experience.

Using your past experience and education, do everything in your power to attain high quality work results that align with the objectives of the business. The 12 principles specifically state “…come from my own experience or from any frameworks that best fit my customer’s needs and context.”

3. To tailor agility to context.

Best fit decisions should be made using empirical evidence and unbiased opinions. Agile is half art and half science. You don’t want to blindly guess at best fit, but you may find you have to interpret evidence to find the best solutions. The best way to do this is to remain unbiased, using everything you know and every piece of evidence you have and work to select the best-fit

4. To understand hindering constraints and work to remove them.

Customers and employers are unique. What works for one, may not work for others. You need to understand the specific situations as best as you can and use that to help remove constraints hindering agility.

5. To share, learn and improve.

The best organizations to work for, in my opinion, are learning organizations. The problem is, organizations try to do this by mandate. What really needs to happen is that it needs to start with the employees. This is where the fifth principle comes in, you need to be willing to share your knowledge with others and work to continuously improve the organization.

6. To respect frameworks and their practitioners.

Respect what Agile frameworks try to do. Some work differently than others, the best thing you can do is try to understand them. Also – you don’t even have to use a framework. Frameworks are there to help you become Agile, they are not mandatory to be Agile.

7. To acknowledge unknowns and seek help.

Don’t be afraid to admit when you don’t know something. Help when you can, but also be willing to accept help and acknowledge when you may not have the skills needed.

8. To never mislead and to never misrepresent.

Work towards transparency. Lay the cards out on the table and avoid hiding things. I have been asked too many times in my career to hide things (I have gotten in trouble too many times for not hiding those things). You build trust and respect by not misleading and misrepresenting. Yeah, you screwed up, you look bad. you will look even worse if you try to hide your screw up and someone catches it.

9. To remember that agility is not the end goal.

Being Agile just to be Agile is not very Agile. Agile is about making the best choices and sometimes the best choices are not Agile ones.

10. To acknowledge that dogmatism is non-agile.

It may be helpful when first beginning an Agile framework to be dogmatic, but as you learn do not be afraid to adjust and adapt the Agile approach. Strictly adhering to an approach may not always make sense, in fact, it rarely will.

11. To recognise that there is more to agile than agile.

Organizational agility may require some work. You may have to build process, train employees, coach and instruct, and in general, work to apply Lean and Agile thinking. You can’t just say you are Agile expect people to automatically adapt.

12. To give to the community as it has given to me.

Work to improve the Lean and Agile community so that everyone can benefit. You find problems, share those problems. You learn things, share those things. The goal is to create an interaction and a cycle of improvement among all Agile practitioners.

Reflection

Personally, I think these principles more align with what Agile is or should be. It doesn’t try to define your environment or limit Agile practices to software development. Software development is just one common and well-known use of Agile, but the roots of Agile date way back before software development even began utilizing Lean and Agile ideas.