I’ve alluded to my kind of Agile in previous posts, but let me spell it out. I’ve hinted at it for quite a while, most recently in my popular post Right to Left: a transcript of my Lean Agile Brighton talk, which helps to explain the necessity and urgency of a Right-to-Left treatment of Agile.
I’m in the process of reworking the second chapter of my 2019 book Right to Left: The digital leader’s guide to Lean and Agile. Verbatim, here’s a key passage from chapter 2, Right to left in the digital space:
In chapter 1, we saw some of the quite different ways in which Lean is understood. Before we get to Lean-Agile, let me describe my kind of Agile, a kind of Agile that should already sound familiar:
- People collaborating over the rapid evolution of working software that is already beginning to meet needs, their teams placing high value on collaboration, continuous delivery, and adaptation
If you want to know what Agile is, the manifesto is where you need to start. Agile isn’t a defined process, method, or framework; Agile means embracing manifesto values. To embrace them you must understand them, and to understand them you must catch something of how they reveal themselves in environments that have allowed them to flourish.
Clearly, the manifesto values resonate with many. Meaningful conversations, the opportunity to build things that actually work for people, and the ability to keep improving the working environment to the mutual benefit of developers, customers, and the organisation – who wouldn’t want that? In other words, these things are valued for their own sake (which is why we recognise them as values).
For a values system to be more than just wishful thinking, there must be a clear relationship between the values, the kinds of behaviours expected, and the assumptions that underpin these behaviours. In the case of Agile, these assumptions are well documented – not least by the manifesto itself – and they go a long way to describe the behaviours:
- Assumption 1: Direct, ongoing collaboration with customers is necessary to develop and maintain a mutual understanding of needs and potential solutions
- Assumption 2: Collaboration across the entire process is what makes the whole greater than the sum of its parts – not just multiple perspectives brought to bear on complex problems, but new ideas created in the interactions between people
- Assumption 3: The most effective way to build anything complex is to start with something that works, and ensure that it still works as it evolves. This is true not just for products, but for the working environment in terms of its technical infrastructure, processes, practices, organisation, and culture (not to mention all the complex interactions between those all of those internal elements, the product, and the outside world).
- Agile’s breakthrough comes from bringing these assumptions together to everyone’s attention in the form of a compelling values statement. The underlying message is clear: wherever those assumptions are likely to hold, you would be wise to behave accordingly!
 I would stand by this definition outside of the digital space too and would argue that it is far more achievable than some would admit. But that’s outside the scope of this book.
 See Gall’s law, en.wikipedia.org/wiki/John_Gall_(author)#Gall’s_law, and John Gall’s rather wonderful book Systemantics: How Systems Work and Especially How They Fail (Pocket Books, 1978).
How does this resonate with you? Is there anything there that you would challenge?
The book is due early next summer; if you’d like to stay on top of developments and perhaps even get involved:
- Subscribe to updates via the book’s landing page here
- Join the Agendashift Slack community and its #right-to-left channel, the place for book-related conversations
- On Twitter, follow @Right2LeftGuide &/or hashtag #Right2LeftGuide
(Note: I’ve only just stopped using the more generic hashtag #RightToLeft, so don’t expect to find much at the new one just yet. I’ve renamed the account accordingly.)
Upcoming public Agendashift workshops (Germany * 2, India * 2):
- 21-22 November, Berlin, Germany, Mike Burrows (Advanced, 2 days):
2-day Advanced Agendashift workshop: Coaching and Leading Continuous Transformation
- 03 December, Munich, Germany, Julia Wester (Core, 1 day):
Core Agendashift: Facilitating Outcome-Oriented Change
- 16-17 Jan 2019, Gurugram, Mike Burrows (Advanced, 2 days):
Coaching and Leading Continuous Transformation with Agendashift
- 20 Jan 2019, Mumbai, Mike Burrows (Core, 1 day):
Facilitating Outcome-Oriented Change with Agendashift
Links: Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter