Wednesday, August 27, 2014

Book: Scaling up Excellence

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.

Monday, August 04, 2014

Bug Strategies & Xanpan volume 2

The summer lull has finally allowed me to get a lot done. In particular I’m very pleased to have finished a piece of writing I began some months ago: Bugs - Management Strategies.

This is an important piece for two reasons. Firstly I’ve been wanting to write this essay for a few years but never found the time. It has taken about four months in total and it runs to about 30 pages, now I know why it took so long.

Secondly, this is one of the corner stones for Xanpan volume 2. Volume 2 was going to be subtitled “Management Heuristics” but I’m now thinking it will deal more with organising so the sub-title might become “Management Heuristics and Organisation” or “Heuristics for organising software development” or some combination.

When I have a couple more chapters of volume 2 in place I’ll make it available on LeanPub. Until then you can register your interest in volume 2 right there.

In the meantime please read “Bugs - Management Strategies” and let me have your feedback. At this point I’m really posting it to get some feedback.

And if you haven’t already bought and read Xanpan volume 1: Team Centric Agile Software Development please do today!

(And if you prefer the a hard copy then get Xanpan at Lulu rather than LeanPub.)

Sunday, August 03, 2014

Introducing the Agile Basics video series

In the last year I’ve had a lot of people ask whether I do online training, and I’ve had several of the partner organizations I work with suggest I should do more video training courses. I’ve even heard stories that some people can make good money doing this.

My immediate reaction is doubt. Doubts because so much of what I do is interactive, exercises, following questions and I don’t know how to translate that into pre-recorded videos or other online material. If my courses were just me talking to the audience then maybe, but thats not what I do in my Agile training courses.

But really: I just don’t know. I don’t know what works and what doesn’t online. I don’t know how to approach videos, how much work is required? How much editing? Should I get a professional involved?

So I decided the best thing to do was to experiment. To find out for myself. O yes I could read a lot about what works and what doesn’t online but until I’ve actually tried its all a bit abstract.

Back in April I posted a “Xanpan Board Tour” video.

And in May ran a webinar with DevelopMentor which was recorded: Agile Basics - 40 minutes plus 20 minutes Q&A.

I learned from both of those, I got more confident. So I can now announce the results of my summer project: The Agile Basics video series.

I took the webinar I did in May, broke it into separate pieces and added some more material. The result is five episodes (quality, iterations, visualise, work in the small and teams) each of which has short video, 10 minutes approximately, plus an introduction and conclusion video - about 4 minutes each.

I hope people will find these useful, its just possible that some people having seen my recordings will decide to hire my services. More likely I imagine people who have been on my courses can use these to revisit some of the topics. After all, YouTube is full of similar “Agile Basics” videos.

But the person who has got most out of this is: Me.

I’ve learned a lot more.

I’ve learned that videos require work. Just like working in another medium - specifically writing - they require preparation, they require time to do the work and they require time to edit and change the work. If I am going to continue working in video then I need to practice these skills and learn more. And just perhaps I need to start working with more experiences, even professional, people.

Anyway, if anyone is interested the videos are available to watch for free either from the Software Strategy website or directly on YouTube.

And if you have a view on whether I should work more in video, or whether these videos have value, or suggestions for how to work better then please, as always, let me know. Getting feedback is hard!