Have you heard about “doing agile” vs “being agile”? Taking a two-day course with an exam to become a CSM can help you and your team to do agile, but being truly agile takes a lot more: Practicing, experimenting, and learning by doing. Here’s my view of how true agility looks.
Warning: Explicit Content
This is not a regular “tips and ideas” blog post. It’s a personal cry out in which I share my thoughts on a delicate but important topic. If this is not what you like to read then there are hundreds of other articles on my website, so just pick one and enjoy.
In this article, I’m going against ways of working that a large part of the software industry adheres to, supports, and accepts as being the “best and only way to do it”. I also challenge common beliefs in the software industry. If your salary depends on this or if you are easily offended then you might want to skip this article.
On the other hand, if you have an opinion on being vs. doing agile, an open mind, and want to learn about my ideas and experiences, read on!
True Agility starts with the Agile Manifesto
My opinion is that you can only be agile when you truly believe in and act according to the values described in the Manifesto for Agile Software Development:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Believing in the agile values means that you deeply agree with them. For example, I believe that working together with my customers in a way that makes them successful matters more than making detailed agreements about what I will or will not do. While learning along the way we will find out what works for us and what doesn’t, and then we can decide what to do next.
Tue agility also means that you will act according to the values described in the agile manifesto. For instance, your behavior should clearly show that you value people and interactions over processes and tools. I do this in my workshop where I train people how to collaborate and work together effectively. I don’t teach them Scrum, Kanban or DevOps, instead, I coach them in applying an agile mindset and practice using agile techniques to deliver value while working together as people in
Agility is not about certificates
True agility doesn’t come with a certificate. You can’t learn it in a course or take an
I do not have any agile certificates and I’m not a member of the Agile Alliance, Scrum Alliance, Scrum.org, Agile Consortium, or any other official agile membership organization. In an earlier article, I explored the alternatives to agile certificates for delivering quality and value. It’s all about value delivered by people who have experience and dare to try out new things!
Value comes from someone who truly tries to understand your problems and provides multiple solutions that might work instead of pretending to have the one right answer. Who experiments, verifies, learn, and improves. That’s what I do!
Talking about true agility, I was already agile before agile was invented. In my first project in 1990, I managed a team that was distributed over two locations to deliver software in increments to our customer. We used version control and automated testing, did design and code reviews, pairing, and improved our way of working as much as possible by reflecting and learning from the things that happened in our daily work.
How does true agility look?
How can you recognize true agility? My suggestion is to check your organization and teams, the people doing the work, and look for true agile behavior:
- Do people collaborate and communicate frequently; are they honest and open about how things are going?
- Are your teams empowered, self-organized, and do they feel responsible for delivering working products and services?
- Do people check if the products and services delivered are valuable for the users and customers?
- Is quality being build in from the start, are people aware of technical debt and do they take action to reduce it?
- Do people give attention to technical excellence, craftsmanship, and good design?
- Are risks brought up and addressed as early as possible, and are actions taken to mitigate risks or reduce
impact? Is it ok to fail?
- Do teams and product owners together demonstrate their products to get feedback, and is this feedback used to improve the products?
- Are impediments recognized and brought up, and are they solved by anyone (not only by Scrum masters, coaches, or managers)?
- Do people feel safe enough to experiment and try out new things, and are they learning from how this works out?
- Are agile retrospectives done frequently and are the actions coming out of the retrospectives done to improve continuously?
- Do people truly embrace change and dare to adapt their behavior?
The above list of agility questions is based on cards from the Agile Self-Assessment Game, a card-based agile coaching tool used by teams all over the world to improve their performance and agility.
The Agile Self-assessment Game helps teams to discover how agile they are and what they can do to increase their agility. It’s a book & cards package: A PDF/jpeg download with images for 52 cards with statements and playing instructions used by teams and coaches to self-assess their agility. There are also expansion packs for Scrum, DevOps, Kanban, and Business Agility.
If you truly want to increase agility, then start by taking the first step. Reflect, be open to learn, and experiment. And encourage people in your organization to do the same. Don’t tell them what to do; allow them to come up with their own solutions and trust them to get the job done.