If you were to explain Agile to someone who was previously unfamiliar, how do you convey what you do? As if you were explaining it to your parents/grandparents (or children)
I too run into this challenge often when explaining what Community as a profession is (especially to my parents and non-technology networks!).
I want to make sure I explain the importance of Agile in very simple terms as the audience may not be as well-versed in the discipline. I thought who could be the better experts than right here
Page 1 / 2
@Colleen Curtis -
A lot depends on the context of the word’s usage. For example, if you say “business agility”, it refers to the resilience of an organization’s value streams to changes coming from within or without. If we are referring to a delivery approach, then I’d define it as a means of delivering value to your stakeholders early and regularly, while progressively improving quality and making people awesome.
Kiron
@Colleen Curtis -
A lot depends on the context of the word’s usage. For example, if you say “business agility”, it refers to the resilience of an organization’s value streams to changes coming from within or without. If we are referring to a delivery approach, then I’d define it as a means of delivering value to your stakeholders early and regularly, while progressively improving quality and making people awesome.
Kiron
Thank you, Kiron!
@Henrik Ståhl any thoughts?
Hey @Colleen Curtis
Let me try to be as general as possible here.
For me agility is only measured when someone / some organization is facing a complex problem/challenge.
Being agile characterize one's ability, when facing this complex problem, to either: -Break it down into smaller, more easily manageable challenges, and actively participate into solving those to achieve targeted results. -by it's own (internal) means -or through identifying and activating a set of outside resources. or -Elaborate and set in motion a more or less complex strategy to "get around" said problem and achieve targeted results. -by it's own (internal) means -or through identifying and activating a set of outside resources.
Hey @Colleen Curtis
Let me try to be as general as possible here.
For me agility is only measured when someone / some organization is facing a complex problem/challenge.
Being agile characterize one's ability, when facing this complex problem, to either: -Break it down into smaller, more easily manageable challenges, and actively participate into solving those to achieve targeted results. -by it's own (internal) means -or through identifying and activating a set of outside resources. or -Elaborate and set in motion a more or less complex strategy to "get around" said problem and achieve targeted results. -by it's own (internal) means -or through identifying and activating a set of outside resources.
This is quite helpful, thank you @Adrien Painturier!
@Said Saddouk always delivering the humor! Is this an Agile requirement?
@Said Saddouk always delivering the humor! Is this an Agile requirement?
It is not mandatory, but it helps @Colleen Curtis
Here’s another Dilbert in a similar vein:
Very interesting topic @Colleen Curtis, thanks for starting the discussion!
I actually disagree with @Adrien Painturier and to some extent with @Kiron Bondale as well. Similar to Lean, it’s easier to explain what it’s not than what it is. But generally speaking, The Agile Manifesto is a set of principles and a mindset, inspired by Extreme Programming. Lean, and Lean UX, is also a mindset – not a process.
To me, what Adrien is describing sounds more like a process, or the ability to adapt to a specific process. Breaking down a challenge into smaller, more easily manageable challenges is a process, not a mindset; you can deal with huge challenges, not break it down into smaller challenges and still be agile. (Although I totally agree with the overall sentiment of actively participating in solving challenges to achieve targeted outcomes.)
And while I agree with Kiron about progressively improving quality and making people awesome, I strongly disagree with “delivering value to your stakeholders early and regularly.” It’s too vague, because a stakeholder might consider something valuable that isn’t valuable at all for the users or even the company and its business. If that held true, you could be a “high-performing team” releasing things with the highest amount of efficiency the world has ever seen and still not be agile – because the things you release have no real value.
There is surely nothing quite so useless as doing with great efficiency what should not be done at all,
as Peter Drucker once famously said (and other smart people before him, but in different phrasing).
Nowadays, we tend to differentiate between Agile and agile:
Agile with capital A is referring to different tools, methods, processes, and frameworks.
agile with lowercase a is not practiced or applied; it is lived every day – it’s basically traits or attributes characterized by endurance, resilience, speed, flexibility/adaptability, and readiness.
While the 12 principles of the Agile Manifesto describes ways to improve methods and processes, the 4 values is the core of agility:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Personally, I’d say the third value is obsolete (I usually replace it with “Cross-functional collaboration over bilateral cooperation”), and I would change “Working software” to “Working solutions.” But overall, these values still hold true.
And as soon as you put too much weight on processes and tools (like Scrum and Jira), or comprehensive documentation, or bilateral cooperation, or following a plan even though it doesn’t make sense anymore, you stop being agile.
The TL;DR version:
Agile is a set of values and a mindset.
Being agile is being adaptive.
Sorry about the wall of text.
Hi, @Colleen Curtis ,
I really like the description by @Henrik Ståhl which builds upon the formal definitions in the Agile community,
For a more non-technical audience, I might start with, “As a parent / grandparent / child, I want to understand Agile so that I can…?” The last part of that user story would help with answering your question.
If the story is “…so that I can understand what my child / grandchild / parent does in their job” a metaphor might be helpful. “Agile helps people work together to solve problems where the answer isn’t obvious and the answer might change at any time.”
If the story is “…so that I can see if I want to use it” then Henrik’s answer would help them better understand if they really want to try it. ;)
I hope that helps.
“Agile helps people work together to solve problems where the answer isn’t obvious and the answer might change at any time.”
@UpGaged thank you! This is so helpful.
@UpGaged I second what @Colleen Curtis just said, so beautiful! 🤩
Will probably steal with pride someday…
Hello lovely Lean-Agilists!
I come to you today for a bit of clarity.
If you were to explain Agile to someone who was previously unfamiliar, how do you convey what you do? As if you were explaining it to your parents/grandparents (or children)
I too run into this challenge often when explaining what Community as a profession is (especially to my parents and non-technology networks!).
I want to make sure I explain the importance of Agile in very simple terms as the audience may not be as well-versed in the discipline. I thought who could be the better experts than right here
This is a BIG question and I struggled with not writing an essay.
When I mention Agile to those with decades of experience with planning-heavy, multi-year projects delivered using the Waterfall methodology, I am usually presented with comments like “we can’t deliver only parts of the system in smaller pieces” or “that’s too big of a change for us to make” - and they are usually 100% correct.
Learning to be agile requires a large shift in mindset. For me, this shift came after first having years of training and experience in Lean principles which eventually led to my recognizing waste almost everywhere I looked. And even when you think you’re doing something better; more efficient, when you take the time to stop and ask, “Is there any way that could have been done differently?”, you are on the path to becoming agile (or is it Lean?).
So, how do I explain Agile to others? If they experience in software development, I like to use this statement I read somewhere on the Internet:
“Agile is a user-centric development approach that delivers value in short cycles so that customer feedback can be integrated into the process.”
And with my Lean background, I sometimes also like to explain Agile as,
“a mindset based on Lean principles.”
For example, you can build a solution in smaller chunks and deliver something functional that will provide immediate value, without spending additional time to plan, build, and deliver something that will not provide immediate value - this additional time spent would be considered “waste” as it could have been spent working on the next iteration/chunk/component while gathering feedback on what has been delivered so far and make the next parts better (it’s a cycle!).
Building a House
And if they are not familiar with software delivery, I default to the building a house analogy.
I’m sure we’ve all heard the horror stories of delays, being over budget, or things that the homeowner wasn’t quite happy with or they wish were different.
Agile will not necessarily have made the house be built faster or cheaper, but when embraced by those involved, the process should lead to a better, more desirable outcome - it should have also left everyone feeling better overall about the experience.
Imagine throughout the house building process you are presented with a number of questions from the builder which cause some delays.
For example, the electrician tells the builder that they cannot put a switch somewhere for “some valid reason”.
Your builder then has to contact you to describe the issue (a waste as it was now explained for a second time) and ask what you would like to do. In the meantime, the drywaller can’t finish their work, nor can the painter - they have to be rescheduled.
How could this one scenario be improved using a few Agile ceremonies/practices?
Instead of waiting for updates, you are onsite everyday at 9am for a 15 minute check-in with “the team” (you, the builder, and representative from every trade). It is during one of these quick huddles that the electrician mentions the issue. But because you are all present, the carpenter speaks up and says, “hey, I can move that 2x4 over a bit if I do “x” instead”, and now the problem was solved right there.
With exchanges like these, you will likely end up moving in with fewer surprises and end up with something that you really wanted, even if plans changed along the way.
Culture plays a key role in the success or failure of Agile.
@Kevin Kinisky +1. Culture plays the role in the success or failure of agile. That's why it's so difficult to succeed and easy to fail.
@Robert Johnson I will read a word-wall-by-Robert any day, any time. Thank you for this and the building a house analogy
@Henrik Ståhl thank you for illuminating and bringing together some of this commentary.
I will try to do you all proud!
@Colleen Curtis So, how did it go? Tell us everything!
(I’m 100% certain you made us proud but I’m still curious )
@Henrik Ståhl it was good! I used Miro to do an icebreaker, too!
Unfortunately, Agile did not come up (I was trying to squeeze it in!) -- but this conversation spurred such a great series of thoughts that we are looking at how we can build a more comprehensive community Agile series for April.
What do you think?
@Colleen Curtis Nice work the icebreaker! Too bad agile didn't come up, but there will certainly be other opportunities in the future to steal @UpGaged’s beautiful quote.
A community agile series sounds like a great idea
@Helena Brandist This was her idea!
What should we do in April to celebrate Agile? (and I will learn all I can in the process!)
@Colleen Curtis -
One way would be to hold a contest to have members provide their favorite templates for supporting “being” agile - whether that is at the individual, team or business-levels. I’d avoid retrospective templates as those are ubiquitous but other ones such as:
Personas
Product/project canvases
Support for SAFe (Yikes!) events
Pain snakes (look it up )
Another one might be a public, shared board or event where members could provide feedback on:
What does agile mean to them?
What does (fr/fake) agile look like?
What “flavor” of agile do they follow?
Kiron
Love these ideas @Kiron Bondale!
An Agile Flavor Wheel feels like the best thing yet… (meshed with a coffee flavor wheel for energy)…
awesome
thank you! This is so helpful. 
)
This was her idea! 
)
