In this blog I would like to share with you what motivated me to write my latest book, which is titled: “It’s All Upside Down”. And I would like to tell you a little bit about what’s in Part I of the book.
So let’s start with the motivation. The title of this blog post is actually the subtitle of the book, which has a lot to do with my motivation for writing it.
In just the past few years I have made such drastic changes in how I help software development teams as a coach that it often appears what I am recommending to my clients is the complete opposite of many well established long held software engineering principles.
Now, in fact, my recommendations are not really in opposition to these principles at all—but they appear to be because what actually works in practice oftentimes isn’t what we think based on what many of us have been taught.
This was my major motivator for writing this book. I wanted to share true stories of what we have recently discovered really works for successful software development teams in practice. There are eight stories in Part I of the book that all occurred in 2015 and 2016.
As I share the stories I also highlight 26—what I refer to as– “upside down” principles. Now, the principles themselves are not really upside down. What is really upside down is what many believe they need to do to effectively apply these principles.
To help communicate this message I focus each story around three key items:
- First, the activities successful teams conduct in practice
- Second, how much of these activities they conduct
- And third, when they conduct each activity
I expect many readers will be surprised to learn how little time successful software development teams spend on certain activities that have traditionally received high focus, and–even more importantly– how much time is actually spent by successful teams on activities that traditionally have received little attention.
In closing this blog I would like to point out that I am certainly not the first person to have observed that what works best in practice often doesn’t match the theory.
It is also worth pointing out that this observation is not unique to software development. As the immortal New York Yankee baseball legend Yogi Berra once said:
“In theory there is no difference between theory and practice. In practice there is.”
Now, in this blog I have referred to both principles and best practices. In my next blog I will share with you why I focus more on principles in the book, and I will explain the power that principles can bring to a software development team’s performance.