Do we really need to sit together?

I think co-location rocks for teams.  The first time I had the pleasure of trying Scrum proper-like I stuck three devs in a broom cupboard to work together, one of them still talks to me (he even uses nice words).  Is co-location really important?  Software development is a social process so people will communicate anyway even if they are close but not co-located, won't they?

In Managing the Design Factory Donald G. Reinertsen has a graph very much like this one.  It shows the probability of technical people communicating weekly by distance.  The original data is from a 1977 publication, so pre-email/SMS/IM/Twitter.

Warning - graph is an approximation of the data. As I don't have the actual data I have reproduced this as best I can.

At a distance of 10 metres the probability of technical people communicating to each other everyday is pretty low.  

If you're working in a serialised process you probably don't care - they don't need to communicate, it's in the spec.  

If you're working with a concurrent or collaborative process then you need the people side by side.

"But we have a stand up/daily scrum, so everyone communicates once a day.  We can skip this co-location bollicks and leave people at their desk."  OK, but are you more more open with someone you know well or someone you don't know well?  Co-location allows people to have the general getting know each other conversations that break down barriers and build relationships allowing for richer communication so they can tackle more important issues (eg What's blocking me). So nerr.

Managing the design factory

I think I picked up "Managing the design factory"  from the references in the Larman & Vodde special. I wish I had read it years ago, so far it's a cracking read.

From the introduction

There are no best practices

...Best practices are only "best" in certain contexts and to achieve certain objectives.

..The great danger in "best practices" is that the practice can get disconnected from its intent and its context and may acquire a ritual significance that is unrelated to its original purpose.

Aaaaaamen brother

Book Review - Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum by Craig Larman

My review

rating: 5 of 5 stars
This is a fantastic book to help with the issues of taking scrum/agile/lean/xp from a small software development team into a much larger scale product development effort. The depth of knowledge and experience of the authors is demonstrated by the fact that they don't give any silver bullets, but describe tools for dealing with complexity of scaling.

The first half of the book on Thinking tools is well considered and useful. Most of it isn't a surprise to me, but the section is well written and distills the fundamentals of systems thinking, lean thinking, queuing theory, false dichotomies and being agile very well. These thinking tools are used to help the reader understand the concepts in the second part of the book on Organisational tools.

Organisational tools is fantastic, covering Feature teams, Teams, Requirement areas, Organisation, and Large-scale Scrum. Using experience and the thinking tools Larman & Vodde describe why you would adopt these tools to help scale. I regularly did the "d'oh, it's so obvious when you put it like that" forehead slap reading this section of the book.

The recommended readings and fantastic reference list at the end will ensure I blow another huge wad on books this year.




View all my reviews.

The inmates are running the asylum, and Mr Cooper needs to whine about it

The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity by Alan Cooper

My review

rating: 3 of 5 stars
If this is meant to be the business case for interaction design, it's a pretty sad business case. The ideas are good, but they way it's put is frustrating.

There's some useful material in this book, but it's hard to dig out in the constant noise of Mr Cooper's whining. You could easily scan the first 120 pages, then read about half of the chapters on persona and goals, and you'd have it.

I am left with the taste of BUFD in my mouth too. That may be a misunderstanding, but it seems that we need to have a big interaction design to get it all right, right from the beginning. This is not something I like the idea of.

Yes, interaction design should be handled by pro's. Thanks Alan.

A book to borrow, quickly scan through, then return.


View all my reviews.

Some highlights from Waltzing with Bears Part 4

We now know all about what, why and how for risk management so it's time to get down and dirty with How Much.

It's about value. This is great, I work for a bunch of people who start to go a little weird if they haven't said "Value" at least three times a day, and there's a good reason for this, apart from them being odd.

You make something, anything, for some value. You put effort in to get something out. The value of a software project needs to be clearly stated, and someone/some people need to be accountable for the delivery of this value. The other side is easy, there is always accountability for cost, schedule, scope, but what about the purpose of the work, who is accountable for that.

When benefit cannot be stated more precisely than "We gotta have it" then the cost specification should be "It's going to be expensive."

Explicitly stated value allows you to prioritise the work, essential if you are to deliver incrementally. Best of all it allows you to stop the work. When the value is lower than the cost to develop, don't do it. So easy, well so easy to write, is very hard to do. People don't like to spend the time to do this kind of work, it's hard and can be confronting. It's out of the ordinary "my business case said we'd get 300 new customers a month, that's value" but "which bit of this project will give you that? Surely some elements do more than others?"

2 points Tom and Tim make on why this is either not going to happen or be very hard
1 - it opens the door for an additional level of accountability
2 - there's no obvious pay back

I would say that one payback is that you can stop the development when what you spend is more than you will get back and if you don't explicitly state value how do you know what risks you can take?

Some highlights from Waltzing with Bears Part 2

Part 2 describes 99% of the software industry in Australia


In "The Case against Risk Management" I particularly enjoyed these little snippets...

"Some organisations are so desperate to believe they are in complete control that if they realise the aren't they settle for the illusion of control. The most common symptom of this is ridiculous precision (a very narrow window of uncertainty) attached to estimates that subsequently turn out to be very inaccurate."

Working in Agile Land we face up to the inaccuracy of our estimations everyday. We avoid trying to make precise estimates as we know this is just an illusion. So we use story points or ideal days or gummi bears or dog sizes. We assume an estimate is well an estimate, and for most people in software this is a strange idea, a confronting idea, even a stupid idea.

The whole section on Risk management in isolation is significant - ok lots the book is significant, maybe not the Library of Congress bits, and the advertising. If you start down this road to finding risks and acknowledging uncertainty but you are working in a land of happiness where uncertainty is not acknowledged you are sunk. "The worst organisations penalise unappealing forecasts, but not unappealing results". A friend working for a rather large telco told me the story of the three program managers, the first two were fired as they said the plan was impossible, the third kept their job because they agreed to the plan. Number three gave Churchillian motivational speech to his team "The schedule is impossible but we are going to stick with it anyway".


The Indy Car analogy is excellent.

"When you challenge your subordinates to pull out the stops and bring the project home on time (even though the schedule is ludicrous ... they will take every chance ignoring every imaginable downside, in order to preserve - at least for the longest time possible - any thin, little chance of winning."

I remember discussing one of the side effects of this behaviour 12 months ago with the director media company. He was (and is) a very savvy guy in all things online, but not really in software development. We talked about how in online news it's great to have stories that have long tails ie people keep coming to read the articles after the initial burst of interest. In software development there is a long tail too, but it's not a nice one. If we have a flurry of activity trying to complete some work to a foolishly short schedule we cut corners - either intentionally or unintentionally - the long term effect is when you come back to that code it takes longer to change, the changes are riskier, and the long tail is what looks to be a small cost but it's one that adds up every time you hit that bit of code. Add to this fun that 40-60% of code is developed after release you have created for yourself a serious problem.

How can we avoid this kind of stupidity? <agile rant goes here>

Some highlights from Waltzing with Bears Part 1

A rip snorting book full of horror stories and help to avoid them. Title of chapter 2 says it all:

RISK MANAGEMENT IS PROJECT MANAGEMENT FOR ADULTS

Other highlights...

Prologue
Ok so I get a project that is going to fail and I have to believe in the schedule, despite the impossibility. When it fails we all go "oh dear, what a shame, but we tried". Using Clifford's argument about the ethics of belief is interesting, you need to have some evidence for your belief. Of course people will believe the crazy schedule anyway, as Cialdini points out in his book on Influence, once you make a public commitment to something you create reasons for that commitment, so this is part of being human. Wow this was going to be highlights and I am babbling.

back to the other chapters

If a project has no risks don't do it

Obviously the authors are nuts. But wait it's Tom DeMarco, he seemed sane before. "Risks and benefits always go hand in hand", phew, that seems more sane. So if I don't take a risk I don't gain anything. The risk elevator is nice analogy, a business that is standing still - ie not taking risks - goes backwards.

"Taking explicit note of bad things that can happen (risks) and planning for them accordingly is a mark of maturity." Where as technical proficiency is not a sign of maturity.

Denver International Airport disaster sounds like a great application of the 5 who's. Ask who five times and you can find the best person to blame.

The case for risk management is well put. The first one sounds wonderfully exciting "Risk management makes aggressive risk-taking possible", gosh. I hope I can remember this and the others next time I need to be "negative" on a project.

In the eyes and ears

Reading

• Waltzing with Bears
• Spook Country
• Collaboration Explained

Listening

• Allan Holdsworth - Hard Hat Area
• Allan Holdsworth - All Night Wrong
• Nik Bärtsch's Mobile - AER
• This Sporting Life