It’s a public secret that I like the Manifesto for Agile Software Development. The values and principles make a lot of sense to me, they resonate with me on how I collaborate with people to deliver value.
Published in 2001 the agile manifesto is now 20 years old. But it’s still alive!
Over the years I got a lot of inspiration and useful ideas from the authors who wrote the agile manifesto. In this article series on the agile manifesto, I’ll explore what I’ve gained through reading stuff that has been published by the authors, talking with them or interviewing them, or collaborating with them.
The first article in this series explains how the agile manifesto gave visibility to a new mindset and explores how the alphabetically first six authors inspired me and what I learned from them.
Agile: A new mindset
My biggest appreciation for the agile manifesto authors is for giving visibility to a new school of thought and mindset about developing software and managing development.
With the manifesto, they challenged things that were commonly thought and widely accepted by the software world in the past century, but didn’t work:
- We need to define all work processes upfront and ensure that people stick to them.
- Tools should be used to enforce processes and prevent people from taking shortcuts.
- If every person does their individual parts then the result will be great. Collaboration can be built into the process.
- Let’s make sure that everyone always fully documents what they did, so that we can check if everything is ok.
- People should finish their part and then hand over their work to the next person following a documented process.
- We need to define everything that’s needed up front, in detail, and have it signed by the customer.
- We shouldn’t do any design work, let alone coding, before all requirements are frozen.
- Changes are evil. So let’s postpone them to the end of the project and make sure that we get fully paid to do them.
At times I’ve been guilty too to have one or more of the above things leading my thinking. During my early career, I’ve probably stated things similar to the statements above to my colleagues. Hell, did I know? It’s what I learned at school, what I’ve read in books, and what my bosses were telling me.
The Manifesto for Agile Software Development provides a different school of thought as stated in their values:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.Manifesto for Agile Software Development, (c) 2001 by the manifesto authors
When it was published in 2001 it confirmed things that I had experienced over the years, things that I’ve seen working and that I was doing myself:
- Processes are the way we work around here. They are not documents.
- We can and should change our way of working if we see better ways to do our work.
- Tools should support people doing work the way they can do it best.
- People can only be successful if they interact and work together.
- Collaboration is what people actually do, it matters.
- Let’s trust our people to deliver great products instead of having them write documents for documents’ sake.
- We can’t and shouldn’t try to define everything that’s needed upfront.
- Let’s collaborate with our customers to deliver maximum value continuously.
- Changes are normal, if there’s a need to change let’s find out as soon as possible.
- Let’s embrace new information and adapt to prevent wasting time and money on things that aren’t needed.
Where the agile manifesto was new, the thinking behind it was something that I was already familiar with. I started with agile before agile was invented. I’ve been working in an agile way most of my career, for more than 30 years already.
When the manifesto came out, the things that I was doing got a name :-).
How authors of the agile manifesto inspired me
Over the years I have met and spoken with most of the authors of the agile manifesto. I’ve interacted with them at conferences where we presented and shared our stories or did interviews together. I’ve been reading their books, articles, blogs, and much more. I’ve had discussions with them on LinkedIn or Twitter. And I interviewed most of them as an editor for InfoQ as I wanted to share their experience.
Here’s how I got inspired by them: Below find my stories with inspiration from the first six authors of the agile manifesto (alphabetically).
Kent Beck brought his ideas from extreme programming (XP) to the discussions that lead to the agile manifesto. I consider XP to be complementary to many of the other agile frameworks, given its focus on technical practices.
In my work, I try to ensure that engineering practices don’t get overwhelmed by management practices. Self-organization and reflection are important, but first of all, they should enable and support people in doing their technical work in a good way.
Where methods like Scrum fall short on technical excellence I feel strengthened by XP on how important technical skills and practices are. During my career, I’ve been pairing a lot. In my projects, I’ve always worked towards small releases and working at a sustainable pace.
As an editor for InfoQ I had the opportunity to do a Q&A with Martin Fowler on the second edition of his famous book Refactoring. I invited Kent to the interview to answer a question on code smells which was related to the chapter that he contributed to the book:
Since Martin already picked duplication I’ll choose complex conditional logic. When I see an if statement inside a for loop inside an if statement, I am immediately suspicious that there is a case that hasn’t been considered. A slightly more abstract smell I look for is violations of Composed Method, which states that all the operations in a function should be at the same level of abstraction. For example, if I see a bunch of bit twiddling operations in the same function with calls to other functions, I’m pretty sure there is a better way to express the computation.Kent Beck in Q&A on the Book Refactoring – Second Edition
Unfortunately, I didn’t get a chance to meet with Mike Beedle. He was murdered in 2018; I wrote Co-Author of Agile Manifesto and Creator of Enterprise Scrum Mike Beedle Passed Away to support remembering him and carrying his legacy forward:
In 2001 Beedle was one of the seventeen people who created and signed the Manifesto for Agile Software Development. He had been invited by Martin Fowler and Robert Martin because of his involvement in the early adoption of Scrum and the organizational patterns community. Beedle was one of the first to follow in implementing Scrum after Jeff Sutherland, and collaborated on writing the Scrum patterns article, which was the second published paper on Scrum.Co-Author of Agile Manifesto and Creator of Enterprise Scrum Mike Beedle Passed Away on InfoQ
Mike Beedle created the Enterprise Scrum framework which aims to scale Scrum and support business agility. Over the years I’ve seen organizations applying Agile and Scrum beyond Software Development.
Agile can be used in management to create transparency, increase involvement, and enable leadership at all levels. To become agile managers must think agile. Business agility is an area where there is still much to learn.
Arie van Bennekum
I recall seeing Arie van Bennekum first time many many years ago at a meetup in the Netherlands where he told his story about how he became a co-author of the manifesto (which is actually a funny story).
Knowing how important he considers facilitation, I asked him to write the foreword for the Dutch edition of my first book Waardevolle Agile Retrospectives. Here’s what he has to say:
Ik herinner mij een Oosterse wijsheid met de strekking van “als je niet achterom kan kijken, kun je ook niet vooruit denken”. De waarde van lessons learned, verbeterpunten, plus-Delta analyses over een afgelopen periode, etc. is bij de meesten van ons wel bekend. Binnen de meeste Agile methoden is het principe op een of andere wijze wel vertegenwoordigd. Probleem blijft voor velen bestaan dat het goed uitvoeren van een dergelijk proces geen eenvoudige taak blijkt.Arie van Bennekum in Waardevolle Agile Retrospectives
In his foreword, Arie encourages people to experiment with the different formats for retrospectives described in the book and to share their learning from doing this.
I like how Arie goes back to the roots of agile in our InfoQ interview Overcoming Paradigms to Become Truly Agile:
Van Bennekum stated that it takes “being agile” and not “doing agile” to achieve success. Overcoming paradigms is essential; people need the right mindset to become agile. Agile is an interaction concept based on the values and principles of the agile manifesto. Technology facilitates agile working, but tools don’t make you agile, van Bennekum claims. Agile is not something that you just implement; it’s a change to increase the adaptability of the organization.
Arie and I were also interviewed together at Bosnia Agile Day 2017 after my workshop on Dealing Effectively with Impediments. (video to be added)
In 2001 I was reading “Agile Software Development: the cooperative game”. I had to put it down several times as my head started spinning; it was (and still is) healthy food for thought.
I started following Alistair Cockburn’s website, where I learned a lot about how people collaborate and communicate. I came across Solution Focused and the way Alistair used this in his Delta Method (described in Veranderen vanuit je sterktes: Da’s anders!):
What you currently imagine “perfect” to beDelta Method by Alistair Cockburn
What allowed you to get even this far? (celebrate it!)
How can you use that to get a smidgy bit farther?
Alistair is known to be very open and willing to share (just like me). He came up with an Oath of Non-allegiance which I signed and is proudly state on my About Ben Linders page:
I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.Oath of Non-allegiance by Alistair Cockburn
I’ve met Alistair at several conferences, and we did back-to-back keynotes at the First conference 2016 in Melbourne: He spoke about getting back to the Heart of Agile where I presented the need for continuous improvement in Agile.
The heart of agile is Alistair’s current approach to help us focus on the essence of agile, by bringing it back to four words:
Collaborate closely with others to generate and develop better starting ideas. Communicate often to smooth transitions.
Deliver small probes initially to learn how the world really works. Expand deliveries as you learn to predict and influence outcomes.
Reflect periodically, along the way. Think about what you’ve learned in your collaboration and from your deliveries.
Improve the direction of your ideas, their technical implementation, and your internal processes.The Heart of Agile by Alistair Cockburn
Needles to say for those who know me, reflect and improve are key topics in the work that I do. This doesn’t happen automatically, you need to give focus and invest time in reflection and improvement to increase yor agility.
Who hasn’t come across, read, or contributed to a wiki? I’ve used them during my career on intranets to collaborate and share, and I’ve also done contributions to the Wikipedia. Ward Cunningham invented the Wiki as an environment where people can create and collaborate to share information.
Over the years I’ve been inspired by pages from Ward Cunningham’s Wiki, like the ones on patterns and pair programming. Another wiki that I’d recommend exploring is the Agile Retrospective Resource Wiki.
Unfortunately I’ve never had the chance yet to meet Ward in person.
The first time that I saw Martin was at the Goto Amsterdam conference 2013. After his talk, I interviewed him for InfoQ about agile essence and fluency.
Agile fluency is a great concept that Diana Larsen and James Shore came up with to foster the growth of agility. Martin also maintains a great blog, this is where I have read the article that started Agile Fluency.
Over the years, Martin made great statements about developing software. One that I like very much is:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.Martin Fowler
Developing software isn’t about programming a computer. It’s team works where people collaborate, and to do that they need to communicate.
Earlier I already mentioned the interview that I did with Martin on the book Refactoring. Here’s his view on how code reviews and refactoring support each other:
Review is an important component of any intellectual effort. When I’m writing my technical prose, I find it essential to get reviews on my work before publication. They will spot ways in which people can misinterpret what I’ve written, and places where my explanations aren’t clear. They don’t hold assumptions that are so baked into my thinking that I don’t even notice them.Martin Fowler on Refactoring
I’ve been doing reviews and having my own work reviewed ever since I started my career. If there’s any practice that I’d recommend, it’s reviewing.
The above-mentioned inspirations are just some of the things that I could think of writing this article. There are many more; the authors of the agile manifesto have been an inspiration throughout my career in many aspects.
In the next articles in this series, I’ll reflect back on what the agile manifesto has brought us and will share more inspirations from the manifesto authors. Stay tuned!