If you work in an IT organization that seeks to operate in an Agile fashion, you may have run across the challenge of getting your stakeholders — those people who you’re building solutions for inside your organization — involved in your work and keeping them engaged at an appropriate level.
This is a common challenge often attributable to the way you introduce your stakeholders to the way you’re working, if you introduce them at all. Arthur the product owner’s experience may be a little unique, but it is representative of how stakeholders often find out about how they’re expected to work with development teams.
Agile is a way of looking at and thinking about how to approach knowledge work. Instead of a noun, it’s an adjective. It’s a mindset.
The works most often cited to explain that mindset are the Manifesto for Agile Software Development and the 12 Principles Behind the Agile Manifesto. Those documents are good starting points, but it’s helpful to express them in terms meaningful to your stakeholders.
Describing an Agile mindset
Describing an Agile mindsetThe Agile Manifesto and corresponding Principles were written specifically for the context of software development and were intended to address issues that software development teams faced in the late 1990s and early 2000s.
While the ideas are certainly applicable to the entire organization, the specific wording of the two documents is focused on software development.
When I’m asked to explain Agile to people who don’t develop software for a living, I describe it in terms of a mindset that has two key aspects.
- Deliver maximum outcome with minimum output.
- Seek short feedback cycles so you can learn and adapt quickly.
The 12 Principles paraphrased
It’s usually not sufficient to stop there, so it’s often helpful to go a little deeper and provide some “operating instructions”. In that case, it’s helpful to paraphrase the 12 Principles in a way that’s meaningful to people throughout the organization.
- Deliver value through satisfying your customer’s needs.
- You don’t know everything when you start a new endeavor. Structure your approach so that you can learn and adjust.
- Strive for short feedback cycles to aid the learning mentioned in #2.
- Don’t construct silos. Keep your teams cross-functional.
- Pay attention to the people doing the work. Trust them. Give them the environment and support they need.
- Remove as many barriers to collaboration as you can for that cross-functional team so that they can have short feedback cycles.
- Determine the outcome you’re trying to achieve and measure progress and success based on whether you’re delivering that outcome.
- Keep a sustainable pace. Working overtime is not effective. People can’t multitask. Instead of trying to do a bunch of things at once, focus on the most important thing.
- Follow the appropriate practices for building your product or delivering your service. Pick the ones that allow you to learn and adapt.
- Simplicity — the art of maximizing the amount of work not done — is essential.
- Let the people who do the work figure out how they’re going to do the work based on their knowledge and experience.
- Use short feedback cycles to reflect and adapt.
I originally described the principles in this way when I was interviewed for an article targeted at small business owners.
Understanding the mindset is not the end goal
You most likely want to describe Agile to your stakeholders to aid in your efforts to embrace Agile as an IT team, and ultimately as an organization.
Embracing Agile should not be your end goal.
Presumably your organization is looking for a competitive advantage or are looking to continuously improve. Working in an Agile fashion will help you accomplish that. However, if your organization cannot clearly express WHY you think they should embrace Agile, you’re setting yourselves up for disappointment.
What are there some other ways to explain Agile in a business context?
There are some people looking to apply these ideas to broader organization and have adopted the term business agility as a label for those ideas. Agile Alliance has an ongoing Business Agility Initiative to explore these ideas.
There have also been reformulations of Agile values and principles that reflect what we’ve learned since 2001. A couple of examples are Modern Agile and Product Agility.
All of these different explanations are valuable and put forth great ideas. I personally long for the day where the adjective “agile” is no longer needed because the ideas described above are just the way people work as a matter of course.
What are some ways you have used to introduce Agile ideas to the people you have to work with? Leave your thoughts in the comments.
About the Author
[aa-author-bio]
