Scaling Lean & Agile Development by Craig Larman and Bas Vodde

Some time ago at work, our VP at the time ordered everyone to read two books. Everyone was sent their own personal copies. One of them was Scaling Lean & Agile Development by Craig Larman and Bas Vodde.

As the title suggests, this book is about scrum in large projects. This includes large embedded software systems with tens of millions of lines of code, hundreds of programmers in offices worldwide. As a running example the authors often talk about the software that goes into a large sized printer/photocopy machine.

This is a very good book. The authors definitely have the credentials to talk about large scale scrum, having practised it on the big printer projects and other large programs. An important theme is about the scrum teams themselves. The authors emphasize that the individual scrum teams must be physically located together to be a real scrum team and be effective. It's fine to have multiple teams in different sites and time zones, however each individual team must all be together.

There's a 19 page scrum primer at the end of the book. I found this incredibly useful and valuable. To think of the time and money I saw squandered on bringing in dodgy scrum "consultants" / "trainers". We spent three days flipping pennies and other worthless exercises. It would have been 100 times better to have just handed everyone a copy of this book and sent them home for 3 days to read it. Or even half a day to thoroughly read and understand the 19 page primer and we would have had far smoother and more successful scrum adoption.

My biggest regret is at work I've tried to discuss this book and how valuable it is with my coworkers. Alas, it proved to be a one sided conversation as unfortunately few seem to have read it despite my enthusiasm and recommendations.

One thing I've always wondered about the book though. As noted, it was a VP who commissioned a copy for everyone. What did the VP mean by sending everyone a copy. Some possibilities come to mind as to what was the VPs message to the dev teams, in particular the directors, managers and team leads

this is a description of what we are already doing at this time

this is an order to switch the software development to do what is described in the book

the book is suggestions to evaluate what we are currently doing, and move toward the practices described in the book


Alas since the last major reorg I no longer report to that VP so I can only speculate.

A new email world

Back in the late 1990s at PRIOR Data Sciences I went over to the Department of Fisheries and Oceans as a contractor to help out with DFO's Y2K projects.

I was on site at DFO for several months. Each Friday I faxed my timesheet back to the engineering services manager and all was good. With no reason to go to the office which was across the bridge I didn't drop by and log in.

One day after several months away I was in the PRIOR office and logged in. I was amazed that there were over 100 unread email in my inbox during that time. Wow that seemed like a huge number. At that time we didn't have remote desktop, and OWA was just being launched. It took over an hour to wade through the messages.

Fast forward a few years to today. My last day of work for 2012 was Thursday last week. Since then in the following 4 days, only 2 of which were business days, there are now north of 200 unread emails in my inbox. I know this because of BlackBerry.

The 200+ messages are just those that got by the Outlook filters. Back at PRIOR there were no filters, every single email went to my inbox. Today I have dozens of folders and filters and more email gets filtered than gets through to inbox. Still 200 messages in 4 days, a few marked urgent.

It's a different world now. Back at PRIOR there wasn't much point sending an email over the weekend because nobody would see it until Monday. Today it is standard to send emails which expect a response during the evening and on weekends and it's not to get a head start on the next business day. What's the expectation when someone sends an urgent email on a Saturday afternoon? Is it considered bad form to generate urgent emails outside of regular business hours?