Uncharted Waters

Oct 2 2014   9:46AM GMT

The nature of software development

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

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.

That’s agile.

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.

nature of software development

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.

3  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • Matt Heusser
     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. 

    I read this and literally thought "I don't know about that, Justin ..." Cross-functional means the team contains all the skills it needs to get things done, not that every person is a generalist.

    Then I kept reading, and I see that is the point Ron tried to make, sweet.

    Does the book talk about component teams? They are typically described as the alternative to feature teams, and they brings other problems ... and a few strengths.
    4,860 pointsBadges:
  • Justin Rohrman
    The first part about agile rhetoric and cross functional was my take, you read it right. I got that interpretation from the large group of agile people that don't want to self-identify as anything in particular (tester, programmer, whatever) in conversation. 

    In practice, it may be very different and is probably more aligned to what you said there about a team contains the skill set needed to get things done. I think that people probably do fill very specific roles on a team. The book pretty much says to identify the skills you need, find the people that have them, and let them do what they are good at. This is opposed to "good cross-functional agile team member".
    2,130 pointsBadges:
  • AshishSingh10

    Yes, I too am very much convinced with the opinions of Mr. Justin Rohrman.

    Thanks and regards
    1,330 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: