It’s not the method. It’s not the framework. It’s your unique assemblage of innumerable small things that work together toward success. And some larger things: the people.
Though it is labelled #1, this isn’t the first article I’ve written on this subject. I’ll tag some others with this new category, as I think of them or rediscover them. This is, however the first article where I’ve committed to this particular direction: focusing on the small, solid ideas that contribute to what we call success in software development.
The basic idea here grew in part from yesterday’s article, Jam Session, where I started talking about the Law of Strawberry Jam:
As long as it has lumps, you can never spread it too thin.
The underlying issue here is the quite valid concern that the world of “Agile” is not delivering what its creators and early adherents feel that it should. Instead, “Agile” has turned into a world of process products and tool products, and is not delivering the effectiveness the creators and adherents know to be possible. Worse yet, “Agile” often turns Dark, delivering poor results and an unpleasant work experience for those who work under it.1
That’s certainly not the intention of anyone in the “Agile Industrial Complex”. I’m sure that they all have good will and are offering the best ideas that they have. The problem, I am coming to understand, is that by and large we have lost the thread. To an extent, many of us never had it. We had something else: a process or framework.
The authors and early adherents had all had a similar experience of working in an incremental and iterative fashion, following some practices that are more or less easy to describe, and we had all experienced success and joy in the work. Perhaps we can be forgiven for thinking that the common elements we observed were central to the success and joy. I’ve come to see–am coming to see–that they were not.
It wasn’t the Daily Scrum. It wasn’t the Sprint Planning. It wasn’t the Planning Game. It wasn’t TDD.
It was, not the canonical assembly of those practices that made the success and the joy. It was the team, which by some magic, had come together, and who worked together, co-creating the product.
That team did, of course, follow a process that probably looked like Scrum or XP. They did do frequent check-ins, of their code, and their thinking. They did plan and re-plan regularly. They did look back frequently to see how they were doing and to commit to the future. They did test their code and release it frequently.
They did all those things, and most of those things are what we’ll call “strawberries” in this series. They’re generally-valuable things to do, that are of value in many, perhaps most, rarely perhaps all software development efforts.
This series is about the Strawberries.
At the beginning of this Agile thing, and here I do not put quotes around it, we thought that it was the assembly of these ideas into a coherent framework that mattered, and we created XP and Scrum and Crystal. Later on came “SAFe”, “DaD”, “Industrial XP”, and various other brands. Let’s charitably assume that these brands were created because their creators saw them as a particularly coherent set of ideas. Let’s also be quite clear that many of these were created as brands, as individual- or company-owed brands of “Agile”, with the explicit intent of selling training and consulting in this new “Agile” thing.
There is nothing wrong with selling training and consulting, in my view, and there is almost nothing wrong with giving one’s offering a unique name that would-be buyers can come to recognize, talk about, and seek out.
I say “almost nothing”. I am not completely untroubled by the branding that came about, because it has not worked out as I had imagined that it would, so that “everyone” would be using these approaches that had success and joy in common. I had imagined that the world would be a better place because of what we were doing.
Well, in fact, it is a better place. It’s just not as much better as I had imagined. We’ve had good effect. (Listen up, HIll.) We’ve just not had as broad or deep effect as we imagined. And we imagine that it somehow was possible that history could have unfolded differently and that more people, “all” people, could be benefiting from these ideas.
History can only unfold as it does. We can influence future history, though generally less than we imagine, certainly less than we’d prefer. But we cannot influence past history, and while we can learn from what happened, time spent on regret is time wasted.
We all did the best we knew to do, and things evolved as they did. Since Jerry Weinberg came up Monday night at the Friday Zoom Ensemble, and in yesterday’s article, let’s have another Weinbergism:
Things are the way they are because they got that way.
We all wave our arms and dance around the fire, and stuff happens. We influence that stuff, somewhat.
This series is about the future and how we can perhaps influence it more in the direction we’d prefer. And it’s mostly about the future of software development, though I have a feeling that we may touch on other aspects of influencing the future.
A “Modern” Trend
Are two things enough to constitute a trend? I have two in mind, though perhaps I’ll think of others.
The idea is to simplify the Agile ideas down to four, collaborate, reflect, improve, deliver. These are good ideas from one of top 17 Agile Manifesto authors. It is, unfortunately, apparently trying to become, not just a community of ideas, but another “brand”.
And there’s “Modern Agile”, from Joshua Kerievsky and Industrial Logic. Curiously, it also has a lovely picture with four parts:
The four parts here are phrases:
- Make People Awesome
- Make Safety a Prerequisite
- Experiment and Learn Rapidly
- Deliver Value Continuously
Here, again, Modern Agile seems to be trying to become, not just a community of ideas, but also a brand.
But the common notion behind Heart and Modern is–I believe–to bring “Agile” back toward Agile, with a focus on essentials. The two are perhaps more similar than they appear at first glance.
Both Modern and Heart include a focus on delivery. They focus on people and collaboration. They focus on learning via reflection and improvement. They are two points that are close together in the multi-dimensional space that is Agile.
I want to think of this as a trend, a coming back to the essence of the good ideas we share, together with a greater understanding of what’s really important, based on over two decades of learning–“by doing it and helping others do it”.
It is my personal view that an important part of what has “gone wrong” with “Agile” is branding. It started with picking a desirable term like “agile” as part of the name, it continued with XP and Scrum, it worsened with DaD and SAFe, and it continues with Heart and Modern.
In fairness, Heart and Modern are both trying to focus more on community. A cynical author, if we could find one, might observe that the mass success of the Scrum and SAFe brands (ptooie!) means that these smaller entities can’t compete at the brand level, but that the individuals and organizations still seem to want a “thing” to sell, not just their organization name.
But, people meeting payroll gotta meet payroll, and I know that both Alistair and Industrial Logic offer fantastic opportunities for people to learn to help themselves be more successful. Still, you have to ask yourself, if these are communities, isn’t it obvious that they have so much in common that they should merge their ideas and communities and form Modern Heart of Agile Community?
But they’re not going to do that, are they?
But all that’s by the way. I’m here to talk about Strawberries.
What Are Strawberries?
The process aspects that have grown up around “Agile” are all capable of being spread thinly, of being understood so poorly, that they deliver only mediocre results at best, and do not provide the joy in the work that the authors and early adherents came to know and love.
The Strawberries idea is to find the “strawberries”, the ideas that are solid enough that they almost cannot be watered down or spread thinly. Some of these may be solid enough to be defined as “practices”, but some may fall more into the realm of values and principles.
Curiously, the Agile Manifesto is about values and principles. Too often, the packaged frameworks have lost sight of the very values and principles that should be central to them. Here, in this series, we’ll surely come back to the V’s and P’s often.
- Individuals and interactions over processes and tools
To me, this is the most important one3. Success and joy come from the individuals on the team and how they interact. Nota Bene: Not just joy, but also success. If you want a really fine, sharp, integrated, nifty product, you’ll need a team who come together and interact well.
I expect that a lot of our Strawberries will come back to ways of bringing people together. We’ll see as time goes on. Let’s get a bit more specific.
What Are SOME Strawberries?
It’s early days for me to be thinking about this, so I’m not sure. I’ll find out by writing. You’ll find out by reading, and thinking, and, hopefully, contributing to these ideas, here or in your own space.
- Retrospectives are a big topic, so we may need a better term, or a smaller breakout, but I am quite sure that we can only improve by looking back at past experience and resetting our direction going forward.
Sometimes we’ll probably want regular intervals for these reflections, and sometimes we’ll want to do them after events, good or bad, such as code commits, releases, or outages.
- This should be put ahead of “Retrospectives” but I’m not going to do it because I think there should be a tighter bond between Retro N and Planning N+1 than between Planning N and Retro N. Planning works best in the clear light of experience.
- This idea4 comes from Twelve, the “method” that Chet and I wrote about and plan never to offer as a method. That’s a lovely article, full of beautiful hand-crafted pictures, and I hope you’ll read it.5
The “brackets” notion says that all our work should fall into a pattern of “entry bracket”, where we define what we’re going to do, “build”, where we work to accomplish the thing we set out to do, and “exit bracket”, where we look back to see how we did, so as to inform the next entry.
- Complete Team
- This notion, also from “Twelve”, says that we build our product with a coherent, close-knit group of people, with all the skills necessary to the effort. “All” means product knowledge, management knowledge, development/testing knowledge, …, everyone we need. Everyone.
- Close on the heels of “Complete Team” is another large topic that surely contains some Strawberries: Diversity. If we are all too much alike, our ideas will fall into a narrow stream and will be of more limited value. We’ll need to explore how to ensure that our teams have all the ideas they need, and the flip side, which is to ensure that all the people with ideas have a fair chance to be on the team.
- Frequent Delivery
- I’m sure that an essential Strawberry is to have, at every moment from the beginning of the effort, a complete, tested, running version of the product, continually growing in capability and quality.
We do this for some key reasons, including transparancy to our stakeholders, faster feedback, and earlier receipt of returns on our investment. We’ll surely find that the more frequently we deliver, and the further out we push the notion of “deliver”, the better we’ll do.
- Speaking of feedback, there will surely be Strawberries relating to feedback, including, of course, TDD. However, I suspect that TDD is too large to be a single Strawberry. A Strawberry needs to be of value, and solid enough that it can’t be watered down, and small enough to be understood and undertaken quickly.
Feedback is, of course, what Brackets are about. We set a course, we travel a bit, we look back and look forward. In TDD, our opening bracket is often a test. Over the course of a day or a week, we set larger goals and assess them more generally.
The above are just a few starting notes about what some Strawberries might be. I plan to write about more of them, and about these, in the near future. If you have ideas you’d like to share or questions to ask, please tweet me up or drop me an email.
In this article, as I often do, I’ll put the word “Agile” in quotes when I’m referring to the Agile that is weak sauce, and without quotes when I’m referring to the pure quill. ↩
“Pronounced ‘co-burn’, in the Scottish fashion.” –AC ↩
Probably it’s the only one he can remember. ↩
While we’re on ideas, I’d just like to say here that I lay no claim to any original good idea anywhere. My mistakes are surely my own, but all my ideas have come from somewhere, and someone, else. I try to give credit when I remember the source. ↩
I’m pretty sure that the Brackets idea comes from Chet Hendrickson, and I am quite sure that arranging them this way “[ ]” rather than this way “] [” was his idea. Probably both layouts have stories that need to be told. ↩