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?

poor performance vs. overtasking

Apropos of a recent Dilbert it got me thinking of how certain problems can manifest themselves.

suppose an employee's performance is not up to standard. this would include the following symptoms

• excessive overtime
• missed deadlines
• poor quality of delivered work

on the other hand suppose an employee has been overtasked, assigned more work than there is time to complete. the evidence of overtasking includes

• excessive overtime
• missed deadlines
• poor quality of delivered work

well what else to say? it may not necessarily be 100% of one or the other. also since the symptoms are the same there may be very sharp disagreement between management and the employee what the real problem is.

lol Acer

I noticed a recent comment by Acer about the new Microsoft tablet. I found that amusing about "negative impact" on the Microsoft ecosystem.

Speaking of harming the ecosystem. Back at Core Networks and SupportSoft there used to be some Acer gear around. They were famous for blurry monitors and desktop PCs that failed prematurely. I once told the IT guy to not bring in any more Acer equipment as

Acer = white box clone = junk

Naveen moment

Years ago I read the story of Naveen Jain at InfoSpace. An interesting tale of that time.

This is the sequence I found remarkable from January 2001. On January 10 Jain left InfoSpace. Then this

... word spread that Jain was looking at office space in the same Bellevue building to start his own wireless company. His business concept involved micropayment technology — using a cellphone, for instance, to order and pay for a latte at Starbucks and having it ready when the customer walked in the door.

...

The board decided it had no choice but to ask Jain to return and run InfoSpace as chairman and CEO

I wonder what it would have been like to be an InfoSpace employee at that time. Jain leaves, ok, absorb that. Then, because he has some incredible idea that is so potent they have to bring him back.

So that's what a Naveen moment is. You're going about your business and then some incredible, unbelievable thing comes along and it's true.

It doesn't have to just be business or personnel type stuff. Back at SupportSoft one time there was an issue our server was not processing Inform messages from certain devices. It turns out that the DSL modem was emitting malformed XML, failing to escape an ampersand & character that had been typed into a text field during the config for the sales demo. That of course crashed the XML library we used to parse the Inform.

So we told the vendor what the problem was. Then the Naveen moment: we were asked if we could put in a workaround on our side! How can an XML parser be expected to parse something that isn't XML. Yet after some grumbling we did figure out a workaround. We put a preprocessor in front of the XML library to find the specific issue of unescaped ampersand. sheesh.

You don't want to be at a company that has too many Naveen moments.