Published in 2001 the agile manifesto is now 20 years old, but it’s still alive. The values and principles of the Manifesto for Agile Software Development make a lot of sense to me, they resonate with me on how I collaborate with people to deliver value.
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.
In the first article The Agile Manifesto: A new mindset I explained how the agile manifesto gave visibility to a new mindset and explored how the alphabetically first six authors inspired me and what I learned from them. In the second article in this series, I show why agile makes sense. And I’ll share the second block of six manifesto authors, showing how they inspired me and what I have learned from them.
Why Agile Makes Sense
When the agile manifesto was published in 2001 is was both long due and way ahead of it’s time.
Plan-driven methods for software development have failed for many years in the past century. They still are failing. The Standish Group CHAOS reports show year after year that most IT projects either fail or are challenged. For those that succeed, agile often plays a role in them. At the time the manifesto was published it was long due: we knew for many years that making more and better plans and managing projects in detail wasn’t the way to go. We needed a new approach, a new mindset.
Then ideas like working in teams, collaborating closely with customers, delivering in short cycles, retrospecting and adapting our way of working, posed challenges to people and organizations in 2001. The world wasn’t ready for this at that time. I’m actually wondering if it’s ready now, twenty years later?
When the manifesto was published, it wasn’t something “new” thing to me. But it made a lot of sense. I started with agile before agile was invented, back in the 1980s. I took the approach to deliver value to my customer in increments because it made sense to me and my team. We collaborated, did product demos, reflected on our way of working, and adapted. Doing this helped us to deviler a better product faster. In 2001 this got a name: Agile.
The agile manifesto serves a purpose. Its values make us think about the way that we can deliver valuable products. Its principles provide inspiration on how to do it. Publishing the manifesto has supported a wave of fresh thoughts about how humans collaborate and communicate. Still, many people find it hard to apply agile within their specific context.
To help make sense of the Agile Manifesto and apply it to reflect and learn, I created the Agile Manifesto Retrospectives Questions Cards. They can be downloaded in my webshop for a nominal fee.
These cards contain powerful questions to inspire your agile retrospectives and keep them valuable and effective. There are 15 questions for each of the four values of the manifesto, both for the left and right sides of the value (it’s “over” so both sides are valuable). And 12 bonus questions that you can use to help teams to think about their agile journey, and empty cards that you can use to add your own questions. In total there are 78 cards with powerful questions.
Asking questions can help to deepen insights and better understand what’s happening. The agile manifesto doesn’t provide answers or solutions. It guides on things that make sense, that matter. With that guidance, we can come up with answers and find solutions that work for us.
Summing up, agile with the agile manifesto sounds like common sense to me to develop products. Unfortunately, common sense is not that common.
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, Twitter, Slack, or email. I also 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 second block of six authors of the agile manifesto (alphabetically).
I’ve first met James Grenning at the OOP 2015 conference. We spoke about code smells which is something that I’ve been working on in combination with code reviews. Inspired by my experience, our discussions, and reflecting on the way that I facilitate and teach facilitating agile retrospectives, I came up with the concept of retrospective smells: signals that there’s potentially something going wrong in your retrospective. I wrote a series of articles on retrospective smells and created the Agile Retrospective Smells Cards.
I did a Q&A with James Test Driven Development and Code Smells for InfoQ where I asked him why programmers need to have a good nose for code smells:
The programmer that wants to improve the code they are working on needs three critical skills. A good nose for code, skills to envision an improved design, and the skills to transform the smelly code to the better code.
Simply, if you cannot identify with some precision a problem in the code’s structure, how can you fix it. I recall code reviews in my career were usually just a matter of opinion. “I don’t like that, I would have done this”, totally unsupported. Any programmer can announce “this code stinks”, but that is not good enough. A chef in the kitchen takes whiff of the air and says “throw out the potatoes, they are bad, and get some fresh ones”. Programmers need to be able to identify specific smells to have an idea of how to make the code better.James Grenning on InfoQ
James came up with the idea of planning poker. It’s a great way of applying gamification and games to increase developer involvement and create a safe environment for people to share their thoughts and feelings about something as tricky as estimations. In planning poker, agreement requires no unnecessary debates. My experience is the same with techniques like wideband Delphi estimations and health checks; using these techniques I suggest spending time to discuss the differences as that’s where the learnings are.
I’ve seen Jim Highsmith presenting at one of the first SM/ASM conferences that I attended, I believe it was in 2001 or 2002. These were the first big US conferences that I went to and later spoke at. I learned a lot at those conferences which I used over the years to measure and improve software quality when working at Ericsson, and I expanded my professional network into new areas.
In 2004 Jim Highsmith published the book Agile Project Management. It’s recommended reading if you have to do projects and want to learn how to do them better:
In an agile project the team takes care of the tasks and the project leader takes care of the team.Agile Project Management by Jim Highsmith
Applying the concept of agile to the way projects are being managed made sense initially to me, but I’ve seen this fail way more often than being successful. Failing was most often due to not adopting the agile mindset but instead misusing agile as an excuse to distribute planning work over the team while still trying to micromanage everything.
Managing projects with agile is a challenging topic on which I’ve written several articles about in the early period of my one-person company: Agile project management, Managing and reporting agile projects, Fixing scope in agile projects, and Managing projects with agile teams. Over the years I’ve moved away from project management, where my attention shifted towards managing products and teams which I believe is a more viable and sustainable approach for delivering value. In the past years, I’ve been presenting and writing about the Dos and Don’ts of Agile Management.
Andrew Hunt wrote the book The Pragmatic Programmer (together with Dave Thomas). It was originally published in 1999, but the version I have read is the 20th anniversary edition published in 2019.
The essence of agility, as stated in the pragmatic programmer:
Agile is an adjective: it’s how you do something. You can be an agile developer. You can be on a team that adopts agile practices, a team that responds to change and setbacks with agility. Agility is your style, not you.David Thomas and Andrew Hunt in The Pragmatic Programmer – 20th Anniversary Edition
I share this view; agile isn’t what you are but what you do and how you do it. The manifesto only provides a set of values and principles, it up to each individual to think about how to apply those and act in a way that makes sense.
Reading the pragmatic programmer I wanted to do a Q&A (written interview) with Andrew and Dave. I came up with questions on topics to dive into. It turned out that Andrew and Dave preferred to do a podcast; here’s the interview that my InfoQ colleague editor Shane Hastie did with them: Dave Thomas & Andy Hunt on the 20th Anniversary Edition of The Pragmatic Programmer.
Andrew founded the Pragmatic Bookshelf series together with Dave. It turns out that I’ve read a lot of books published by them:
- Create Your Successful Agile Project by Johanna Rothman
- Code with the Wisdom of the Crowd by Mark Pearl
- Liftoff, Second Edition by Diana Larsen and Ainsley Nies
- Creating Great Teams by Sandy Mamoli and David Mole
- Agile Retrospectives by Esther Derby and Diana Larsen
- Become an Effective Software Engineering Manager by James Stanier
- Competing with Unicorns by Jonathan Rasmusson
I’ve been in contact with Ron Jeffries over the years by email. We’ve had short discussions related to discussions on Twitter, publications on InfoQ, or one of my books. Ron is pretty direct on what he can or can’t do, something that I recognize and appreciate (I’m Dutch).
Ron Jeffries “invented” story points as a concept to estimate the size of stories in XP. Along with story points came velocity as a way to track how many story points a team can deliver. Yes, deliver: The only way to get story points is when a story is done, the software delivered, and hence the functionality described in the story is available for the users.
Over the years I’ve seen many discussions on awarding story points when stories are partly done (no value delivered so don’t do that), getting story points for solving bugs (again no value as the bug shouldn’t have been there in the first place), and normalizing story points over teams (which usually leads to comparing teams, don’t do it). There seems to be much going wrong and people have a hard time getting it. Which is a shame.
The real benefit I’ve seen in story points is the discussions that they trigger. If everyone comes up with the same number or estimates are close to each other, my suggestion is to quickly consent on a number and move on. Don’t spend time if it should be a 3 or 5, it’s not worth it. When there’s a bigger spread in estimates, discuss to increase a shared insight into the story and not to estimate. Once people become aligned on what the story is about, estimating it will be easy. If it’s hard to estimate, then there’s a lack of good understanding. Work on that.
In 2019 Ron published the article Story Points Revisited where he explored how story points are being misused. I like this statement about putting pressure on teams:
The best way to deliver value isn’t more, more, more, it’s to do small valuable things frequently. If instead of estimating stories, we slice them down to “small enough”, we can come to a smooth flow of value, delivering all the time.Ron Jeffries in Story Points Revisited
Given how much time is wasted with estimation, I’ve become a fan of the estimation approach that Pawel Brodzinski came up with (1 / TFB /NFC) and of #NoEstimates. It’s not about the estimation. It’s about slicing things down to the smallest piece that still has value and delivering a continuous flow of value that matters.
I did a Q&A with Ron Jeffries on The Nature of Software Development for InfoQ, where I asked him about the role of management when an organization adopts agile:
First of all, organizations should not “adopt” agile. They should create some truly agile teams and learn from them. Second, agile methods are about empowering teams to work directly with business people and the business need. This implies that many of the things that middle managers typically do are taken on by the team and its product champion. Managers need to deal with that.Ron Jeffries on The Natuire of Software Development
I like how he moves the focus to empower teams, collaborating with the business, and what the product needs to do. It’s not about becoming agile, this goes back to the values of the manifesto and how to bring them into practice.
I met Jon Kern at the Agile Greece Summit 2018, a conference that has invited many of the Agile Manifesto authors. It was great to talk with him and hear his experiences in his talk A Day in the Life of a Jon Kern Agile Project.
After the conference I worked with him on the InfoQ article Agile in the Context of a Holistic Approach. It’s a great piece with many practical ideas on being agile and using agile practices.
In the article, Jon shared his view on the state of the Agile Manifesto:
Sometimes I am asked if I would go back and change the manifesto if I could.
“No” is my answer.
If anything, we need to strive to (re)educate folks on what we intended when we wrote the Manifesto.Jon Kern in Agile in the Context of a Holistic Approach
I agree with him. The values of the agile manifesto are great and they haven’t aged over time. Debating if they should be updated or replacing a few words doesn’t help us much. Understanding what it’s about and bringing it into practice is what matters.
After doing an interview for Leanpub Frontmatter Ben Linders: Author of What Drives Quality I was introduced to Brian Marick. Having published his books through Leanpub (just like me) he also did an interview with Leanpub Frontmatter: Brian Marick, Author of An Outsider’s Guide to Statically Typed Functional Programming where Leanpub co-founder Len Epp asked him about selling points of agile and the agile manifesto:
What we promised was, “We will give you working software every month, every couple of weeks, that you can actually use and show. You get that. We promise you that if you decide halfway through the project that actually we’ve got all the features that you want, you can just stop then and ship what you have there and fire everyone else, and not finish the project” – which is very appealing to managers.
What we didn’t promise is, “We no longer pretend to tell you exactly what kind of text editor you will have at the end of a year. But we do promise you that you will have the best text editor, the most fully-featured text editor, with the most important features that you can have with this team at the end of that year, we just can’t tell you now what that will be. You get to do that, you get to know that, because we are going to let you tell us what the most important things are, and we will do those right away, rather than spending a year writing infrastructure before you can see anything.” It’s both a good way to develop things for most kinds of things, most kinds of software, and it was also a really powerful selling point.Brian Marick in the Leanpub Frontmatter interview
Getting this promise right was and has been a key thing in many companies that were thinking about adopting agile. Agile is about delivering value where you have to invest time in finding out what that value should be. It’s not about project or requirement specifications. What matters is a continuous intensive and transparent discussions that help to find out what user need mostly now and delivering that. If an organization isn’t prepared to discuss this, then don’t do agile.
In 2018 I was invited to the eXperience Agile 2018 conference where I spoke with Brian Marick. After the conference, Brian started working on an article on embodied cognition. Unfortunately, we never got it finished and published. But we had some great discussions.
Agile makes sense
The above-mentioned ideas are just some of the things that I could think of writing this article. It summarizes how agile has been making sense and is still making sense to me. As you can see, the authors of the agile manifesto have been an inspiration throughout my career in many aspects.
In the next article in this series, I’ll further reflect on what the agile manifesto has brought us and will share more inspirations from the manifesto authors. Stay tuned!