10 ways to talk about Agile without talking about Agile

A good friend was asked to talk to the executive management and give a brief 10 minute talk about Agile. But she was asked to not mention Agile. The context of that challenge is interesting and could hint at all kinds of good or bad reasons. But I was surprised when I saw other Agile coaches struggle with this challenge. They were drawn to talking about “Value Streams”, “Lean Flow” and “Release on Demand” but those are very Agile centric jargon that may not mean anything to someone a few steps removed from the software development. So I wanted to set myself a challenge: Ten ways you can talk about Agile without talking about Agile. Might be you want to sell someone on the value in Agile or just want to ensure you’re using a shared language. These are options you can present.

1. Risk Reduction

A traditional approach to planning builds up loads of risk that isn’t dealt with until the final moments. Heaps of time is invested into analysis, planning and execution of ideas before any of that is validated. How do you know the customer values the solution? How do you know you’re even solving the right problem? What chance do you have of understanding the complexities and issues of the real life implementation when you’re waiting for everything to be “complete” before you show a real user?

We want to turn all that on it’s head and verify everything as we go. Do smaller changes and get them out to real customers. Work closely with real users to find their needs and have them collaborate on solutions. Verify each stage as much as possible.

2. Productivity

We adopt a range of techniques that have been shown to improve long term productivity. From ensuring we collaborate to find the right solutions earlier. To testing at all stages to reduce the cost of fixing bugs. For software it even impacts how we design code so that future changes and additions become easier and easier.

3. Customer centric

As I mentioned in Risk Reduction we highly value customer collaboration. We want to know what real people need not what we guess they would like. We want genuine data on how they use the system or new features to inform what we should do next. We would much rather share an unfinished project to improve and learn how it could be better than worry about how an unfinished project may change how they think of us.

4. Time to Market

In cutting down work into small valuable pieces we can not just get features into the hands of customers sooner. We can learn sooner and quickly adapt or pivot as things change. If a competitor surprises us our customers don’t have to wait months to see how we’ve changed. In focusing on how to frequently and efficiently get changes out to real users we are always going to be a step ahead of slower competition.

5. Ethical Software Development

The old way of developing software asked people to stay in their box and discouraged collaboration. Teams and individuals were expected to be competing with each other to show how skilled they are even if it damaged the wider company. People would hide or be blind to problems until the inevitable deadline arrives and things are not ready. Then there is the crunch and everyone is doing overtime until all those problems are resolved.

In an Agile world collaboration is the primary way of working. We only succeed when the customer wins. Problems are made highly visible and discussed long before any deadline. Everyone works towards a sustainable pace that can be maintained for years. Deadlines are rarely discussed as customers are getting frequent updates and loving those benefits.

6. Long Term Efficiencies

Not just is a highly collaborative team focused on a sustainable pace. Development is done so that each change is a small investment in the future. Code becomes easier to extend and change. Teams continuously reflect and explore improvements. The delivery system is constantly challenging the company to improve quality, reduce costs and deliver sooner. This is not a “pick any two” world. The Agilist is constantly learning and experimenting to find better delivery options.

7. Enabling Innovation

Innovation comes from an environment where there is a diversity of views contributing ideas. Innovation comes when people bring together very different experiences and skills. Innovation comes from everyone being fully aware of the challenges that need to be overcome and not just solutions that have already been proposed. An Agile environment encourages the safety to contribute innovated ideas without feeling like you might face consequences for challenging people. We encourage an inclusive environment where everyone’s viewpoint is important. An Agile team allows the whole company to hear and understand the challenges your customers would like help with.

8. Reducing Complexity

The Agilist is happy to take on the most challenging work. All innovation requires learning and experimentation. It is through using sense making frameworks like Cynefin that enables us to guide teams through exploring new options or even pioneering things no team has done before.

9. Focus on Flow over Delivery

Kanban and Lean Software Development believes that focusing on flow and reducing the lead time of software changes will improve both productivity and how quickly a company can adjust. Tools like reducing the Work In Progress allow different possible benefits. It can reduce context shifting reducing the waste of people shifting between multiple tasks in multiple states. It can also be used to identify bottlenecks and handovers in the system, allowing you to focus on removing or reducing their impact. This constant search for waste removal is a constant search for new learnings and improvements.

10. This is what the Best Companies do.

Look around some of the biggest and most influential software businesses and you’ll find they are using Agile or have been trying to apply Agile approaches. The State of DevOps 2019 report shows a correlation between low lead time and high release frequency with other productivity measures. This requires a combination of technical competencies like Continuous Delivery, Loosely Coupled Software Architecture, Removing any heavyweight change controls, and building psychological safety.

What more can you add to the list?


Leave a Reply