Ron Jeffries, signer of the Agile Manifesto and co-creator of Extreme Programming, has a new book (currently in beta) out titled The Nature of Software Development. The Nature of Software Development is an accumulation of experience and ideas Ron has collected over his past 50 years of software work. The work is divided into two segments, The Circle of Value which explains his ideas on how software work should be done, and Notes and Essays which are questions from readers and reviewers as well as anecdotes from his experience.
Much of the first half of the book is almost exactly what you would imagine agile to be if you read the Agile Manifesto and had no other impressions. This book isn’t about the nature of software development, so much as what software development could look like for people who get it and just want to make a good product.
Grass roots Agile
Some of the ideas presented are almost built into the manifesto. Ideas like identifying the the most immediate value you can deliver to your customers, planning development around that value, and building your product based on that value.
One interesting idea that I’ve not come across before is the idea of feature teams. Agile rhetoric usually says that teams should be cross functional. This means that anyone on a team should be reasonably good at any given thing. This also might mean that no one on the team has a specialty that they really stand out with and can contribute.
Ron has turned this idea on it’s side. In his rendition, teams are cross functional, but that is because each person is a specialist. Since the team members are specialists, each group is completely self sufficient and can produce little pieces of value very quickly. Groups can be assembled and mixed and matched as needed to get a mixture that can build the little bit of feature that the customer wants right now.
This all seems so simple, doesn’t it?
Software just isn’t that easy
So why do agile teams spend most of their time struggling with how agile they are or are not?
The reality, is that software development is a really complex activity. Technologies come and go faster than people can learn them, companies have a hard time figuring out what problem(s) a client is trying to solve let alone how they could help solve them.
Agile isn’t hard because of the concepts. Those are easy: build things small, deliver fast, and iterate.
Agile is hard because of the people. Gerry Weinberg knew this years ago when he was quoted saying “No matter how it looks at first, it’s always a people problem.”
In fact, there are so many people having a hard time with these simple concepts that there are nicknames for the ways the idea has been abused: agile-fall, and scrum-butt, and so on.
What’s not there
One thing that is mostly missing from this book, is mentions of how you absolutely, positively must have scrum, a kanban board, various certified roles, and the whole shebang of testing styles and frameworks. That’s because, these things don’t really matter. To paraphrase the author, frameworks should fit loosely like sweatpants, not like spandex. People need room to move about and respond to surprising things that aren’t in the plan or covered by rules.
It’s deceptively easy
These ideas are so deceptive that in 10 years of software experience, I’ve seen this sort of agile done exactly one time. The one time I was on a team working with this vision was fantastic. The work felt smooth and natural.
I wish what this book described really was the nature of software development, but I don’t think we are quite there yet.