The book the nature of software development intents to help people to organize their thoughts about value and find ways to deliver value in software development. It's a book of questions, not of answers, says author Ron Jeffries, for readers to discover the natural way to develop software, the simple way, inside themselves.
A table of contents and extracts of the book are available on the publisher's book page for the nature of software development.
InfoQ interviewed Ron Jeffries about how the book helps to deliver more value to customers, the natural way to develop software, advantages of using feature teams, the role of management when an organization adopts agile, why Scaled Agile must be simple, and suggestions for professionals to become more fluent in agile.
InfoQ: What made you decide to write this book?
Jeffries: I still think it was demons.
I think that much of the time we who are doing software wonder why it’s so bloody hard, when it seems, somehow, that it ought to be simple. I’m reminded of the quote from Winnie the Pooh:
Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it.
The fundamental premise of the book is that there really is an essential simplicity to doing software development. But you can’t explain simplicity: everyone has to find it in themselves. So the book lays out a structure, sets forth some simple statements, and demands that you think deeply about what’s in it.
InfoQ: What's the intended audience for this book. How will it help them to deliver more value to their customers?
Jeffries: The audience is people who are interested in software and how it should be done, and who are able to read a bit and then think a lot, to begin to understand things that can help them move more smoothly through life.
The essential issue here, is that while every sentence doesn’t end with a question mark, the book is a book of questions, not a book of answers. I believe that people can and will find the answers, and that the book can help them, by helping them to organize their thoughts around value as they understand it, and around some simple components of getting to value, namely the half-dozen items on the cover.
The point isn’t for the book to answer our questions. It is for the book to help us sit down and answer them ourselves.
InfoQ: In your book you write about the "natural way" to develop software. Can you explain what you mean with this?
Jeffries: Well, that’s what the book is. And, as I’ve said, the job of the readers is to discover the natural way, the simple way, inside themselves.
That said, the natural way is to focus on value, and to base all the facets of software development on producing value, early, often, and well.
InfoQ: Can you mention some of the advantages of using feature teams in software development?
Jeffries: Value is what you want. Features are the bits that deliver value. Feature teams build complete features.
When you use feature teams, everyone builds features. Features are what deliver value. Value is what you want. That’s really all there is to it: any other organization of the work puts more levels and more stages between you, and what you want.
InfoQ: You mentioned in your book how feature teams can help to scale agile. Can you briefly describe this?
Jeffries: I believe that “scaling agile”, while a very popular and lucrative line of work for consultants, obscures what really needs to be done “at scale”.
We deliver value with our software, by and large, by delivering features. So to “scale agile”, mostly we need more features per unit time. So we add more feature teams.
Once we do this, we will have focused a big chunk of our organization on delivering value-bearing features, quite directly. For many companies, that’s all we need to do. If there’s more needing to be done, in some organizations, it will no longer be obscured, because we have streamlined all the creation of the actual product. What will be left will be the organizational bits that create friction and waste. Most of these will be well outside the stream of software creation, such as in bloated portfolios and long decision processes.
InfoQ: You stated that the only way to get software close to defect-free as possible is to test it. What about preventing that defects are made?
Jeffries: I’m not sure I said “the only way”. I might have said something to the effect that it’s the only practical way. IBM CleanRoom process produced very reliable code. It was expensive to do and to most of us who thought about it, CleanRoom may possibly have been the most painful and boring way of building software ever invented.
The book promotes incremental development. That means that you’ll be adding to the program, modifying it, enhancing it. Each operation we perform to change software has some chance of breaking it. The most straightforward way to find out whether we have broken it is to test it.
InfoQ: Value comes back many times in the book. Can you elaborate what value is, why it matters and how you can measure it?
Jeffries: The essential notion of the book is probably that value is simply “what you want”. It matters because we want it. You can measure it any way we wish, but at its base, value is not measurable.
One day, what we really value is information. The next day, we value an answer to some immediate question. The next, we get to focus on whatever our business really is. Value is complex and multidimensional. A number won’t define it, but our mind can deal with it just fine: it all comes down to whether we'd prefer to have this thing, or that thing.
In a way, the point of the book is that the things we can measure are not the things of value.
InfoQ: Can you elaborate on the role of management when an organization adopts agile. What should managers do, and what should they not do?
Jeffries: 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.
An interesting exercise that Scrum trainers and coaches often do is to have the group brainstorm a list of all the things managers do, and then to assign those things to the Product Owner, ScrumMaster, and Dev Team. There are always some left over: those are the things that managers should do in an “agile” organization.
As it happens, there’s a whole chapter about that in the book, with the somewhat surprising title “Managing Natural Software Development”. It looks at management through Drucker’s notions of planning, organizing, staffing, directing, and controlling. It talks about how those things happen in the natural style.
InfoQ: You stated "Scaled Agile must be simple — or it isn’t Agile". Can you share your thoughts on agile scaling?
Jeffries: Yes, there’s a chapter in there called “Scaling Agile” that, like all the chapters, gives the reader a framework for thinking about scaling.
The basic message is that if you can do “agile” in the small, you can begin to think about doing it in the large. If you cannot do it in the small, you’d be a fool to try to do it in the large first. That would be like trying to write a book without knowing how to write a sentence. Or a picture book without knowing how to draw.
Oops, I actually did that last one ...
InfoQ: Do you have suggestions what professionals can do to become more fluent in agile?
Jeffries: I believe the book mentions the notion of Agile Fluency. To understand that one should look at the work of James Shore and Diana Larsen. Diana wrote the InfoQ article Agile Fluency: Finding Agile That's Fit-for-Purpose which goes into more detail on this.
The simple answer is always the same. If we want to be good at something, we must actually practice that thing, mindfully, and preferably with help from people who already know how to do it.
About the Book Author
Ron Jeffries is one of the founders of the Extreme Programming (XP) software development methodology. He is an author of Extreme Programming Installed and Extreme Programming Adventures in C#. He is one of the 17 original signatories of the Agile Manifesto.