Book: Scaling up Excellence
Book: Scaling up Excellence
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
In the early days of this blog I used to regular blog book reviews. As I found ideas of my own to blog about - and found fewer books I wanted to read - so book reviews ceased. But right now I want to blog about a book because I want to recommend this book.
The book is: Scaling Up Excellence by Robert Sutton and Huggy Rao.
I’ve been a fan of Sutton’s work for a while now - specifically The Knowing Doing Gap. In this book he continues some of that theme (“Why don’t we do what we know is better?”) but he looks specifically at scaling.
Now scaling is a hot topic in software development (I wrote a little about this myself, Scaling Agile Heuristics - SAFe or not!) so its a book which should find a ready audience in the software community. Although I sometimes feel this is a book about change and on the whole I’m no longer a fan of books about change (there lies a long story for another blog). As a book about change what makes this book worth reading is that it is particularly focused on scaling up changes.
I hope this book becomes more widely known in the software development community, and particularly those concerned with “Agile” and “Scaling Agile.” For now here are some of the key points I want to remember from the book and I hope will wet your appetite:
- Sutton and Roa suggest “the problem of scaling” can also be defined as “the problem of more”. For example: how do we get more teams working in this excellent fashion? Or, how do we get this excellent team to be even more excellent?
- “In order to scale excellence you need some excellence to scale”: as I said in my post last year: If you can’t do it in the small then you can’t do it in the large.
- They introduce the idea of Buddhist and Catholic change models: in the Buddhist model the aim is to help every one/team come to their own understanding of improvement while in the Catholic model the aim is to help every one/team replicate an existing example of excellent. They don’t suggest either one is inherently better but they do suggest that sometimes one model if the context better.
- Continuing on the Catholic theme, they also spend a lot of time discussing standardisation. This is something the has troubled me in the past - I don’t like standardisation, I naturally lean towards the Buddhist model. But I also feel I need to think more about this topic, this book has given me more to think about, watch out for a future blog.
- There is good discussion of the role of hierarchies
- Scaling is a marathon, not a spring
They are just a few bullets from the first chapter or two but I could go on through the whole book. My (e)book copy is covered in highlights and comments.
Let me add a story of my own.
Early on in the book they give three reasons why scaling initiates often fail. I think these three are worth considering in the Agile domain:
- Illusion: leaders believe scaling will happen more easily than the facts suggest
- Impatience: lenders scale too soon
- Incompetence: leaders start scaling without really understanding the thing themselves
Arguably these three things are intertwined and overlap. The third one reminds me of some bank executives I heard speaking a few months ago. The 4 or 5 senior bankers were talking about why they loved Agile and why they wanted more people in the bank to adopt Agile. They were good. They came across as honest. Then they took questions.
The first question was: “Agile says collocated teams work best, how do we reconcile this with a bank policy of remote working and offshore development?”
Rather than say: “I understand your concern, this is something we are working on and we need your help, we might need to change policy or find new ways or working” the executive replied: “With modern tools this isn’t such a big problem any more…” Immediately it seemed that not only did the banker not understand Agile and why Agile said this but he set out to show that as a banker he understood more about modern technology than the technologist asking the question (who was wrong.)
Shortly afterwards someone said: “How do we reconcile regulation with Agile?” and a senior managers then started to wrap themselves in knots about allowing teams to choose Waterfall or Agile during which time one of them said: “Look, as long as your documentation is in order you can do what you like.” Again they demonstrated a lack of understanding.
With those two answers the managers not only shot themselves in both feet but destroyed all the credibility they had spent 30 minutes gaining.
Rather than continue, let me just say, if scaling (anything) interests you then read it - Scaling Up Excellence.
Published at DZone with permission of Allan Kelly , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.