How agile is your team (and what you can do about it!)

This is a guest article by David Daly.

So, what can you do about this? Read on to find out.

Discovering the recipe for team agility

About three years ago, together with several colleagues at Worldline and Atos, I worked on an open-source DevOps maturity assessment tool (you can find it on GitHub here or see it in action here). This assessment covers seven different areas, ranging from technical aspects like architecture and automation to organisational aspects such as collaboration and culture. And one of the areas is team agility ­– how does a team organise itself to frequently deliver small increments of software?

A lot of thought went into these questions, including multiple reviews from other software developers, team leaders and project managers. In particular, we set out to achieve three things. We wanted to make the questions:

1. Neutral from any specific methodology. So, for example, we decided to ask how often you have a potentially shippable version of your product available, rather than asking if you deliver in sprints (which is a Scrum-specific term).
2. As easy as possible to understand for anyone, regardless of their knowledge and experience of agile. We firmly believed that this type of questionnaire is not very useful if you have to already be an agile expert in order to use it!
3. Have simple yes/no answers, partly to make them quick to respond to, but also to make them less subjective. For example, you’ll notice that we don’t just ask if you have fast feedback loops in place, instead we quantify what “fast” means for each type of feedback loop that you need.

So, without further ado, here are the 10 questions that you can use to quickly assess how agile your team is (or how agile any team is for that matter!). Simply go through and answer “yes” or “no” to each of them. Any questions where your answer is “no” could be a good candidate for improvement.

The 5-minute agility self-assessment questionnaire

Q1: Does your team have a new, potentially shippable, version of the product available every 1-2 weeks?

Q2: Does your team track the following metrics: elapsed lead time to deliver valuable changes (from initial request to production), frequency of deployments into production, change failure rate, and time to restore service after a failure?

Q3: Does your team regularly meet to discuss what is working well, what isn’t working well and what they can improve, and are the top improvement items implemented?

Q4: Does your team take actions to ensure that they do not create or experience bottlenecks with/for other teams?

Q5: Are any work items that are blocked swiftly identified and then people collaborate to rectify the situation?

Q6: Is there a clearly defined mechanism for prioritising the backlog?

Q7: Does the team work on the highest priority items in the backlog?

Q8: Are the most experienced team members allocated to tasks last so they can be free to focus on the most business critical or complex problems and help others develop cross functional skills?

Q9: Does the team have fast feedback loops in place from testers (at least every day), the Product Owner (at least every 3 days), customer (at least every 2 weeks) and end-users (at least every 2-weeks)?

Q10: Are there proactive steps taken to ensure there is no major dependency on “superheroes”?

Why do people get frustrated or disappointed with agile?

As we were designing these questions, I started to notice something about the typical frustration or disappointment that software teams, managers and executives were experiencing with agile. More often than not, they had reached for a particular agile method, tool or practice and tried to implement it into their environment, but then were not getting the advantages they had hoped for.

Sometimes, this was because there was a lack of clarity about the benefits they actually wanted. But often, in my view, it was because they tried to adopt a method but couldn’t apply it 100% for their team. To give a simple example, sometimes teams adopting Scrum struggle to fit a single user story into a single sprint, so they start completing individual stories across multiple sprints. However, this small and innocent adaptation of Scrum, significantly reduces its impact and effectiveness.

So, should teams always implement methods 100% by-the-book? The answer is usually “no”. Unless you are setting up a team from scratch, completely independently from other teams and starting work on greenfield software, it is rarely possible to implement any method completely as it is described in a textbook.

The trick is to understand enough about the underlying principles of Agile so that you can successfully adapt and tailor a specific method to your specific context.

The 3 agile secrets that every team can use to adopt agile more effectively

This is what led me to write “Better Agile: How every software team can spend less time firefighting and have more fun building great software”

In it, I have tried to distill the essence of what makes teams agile into three “secrets”:

1. Optimising for flow
2. Getting the right people doing the right things
3. Shortening feedback loops

I then explain how Scrum and Kanban achieve each of these goals, share some of the common mistakes I have seen teams make with them, and give a quick summary of how to choose between Scrum and Kanban for your team (or even benefit from them both).

But, honestly, once you understand these principles, you will be able to successfully adopt, adapt and tailor any approach to agile software development. I also include the same 10 questions from this post at the end of the book and, for each one of them, suggest the quick wins and longer-term actions that most teams can take to see improvements in each area. 

Time to make agile work for you!

I really hope you will take a few moments to answer these 10 questions for your team and that you can use the answers to start thinking about how you can improve your agility, without feeling the need to adopt any one specific method, tool, or practice. I truly believe that getting agility right delivers great business benefits: shorter lead times, higher productivity, and better products. But, more importantly, it’s also better for the people working on the software: less stress, more fun, and the chance to build great software that you can really be proud of. I hope this post will help you along your personal journey to make agile work…for you!

About the author: With over 20 years of experience in tech, David’s passion is how innovative technology solutions can enable new experiences, business models and operational efficiencies.

He has implemented Agile/DevOps within traditional, fixed-price environments and coached other teams to do the same. He is a Fellow of the British Computer Society, a Chartered IT Professional and a regular public speaker who has a passion for showing how new approaches can produce better results.

As well as writing “Better Agile: How every software team can spend less time firefighting and have more fun building great software” he has also co-authored the book “Deliberately Digital: Rewriting enterprise DNA for enduring success” – a handbook for enterprise-wide digital transformation. He has also written numerous thought leadership papers and blog posts.

He is based in Nottingham, UK with his better half and two young daughters. Beyond his passion for innovation and technology, he also loves running and playing piano in a 60s covers band.

Read next: Understanding Agile