What makes a self-organizing team??

Capt Scrubhead, t’Unicorn, Rock Pig and 7 fingers in a lock

Self Organising Teams? I get a lot of push back on this – Especially when doing mingle implementations – People inevitably start down the “Access control” route!

“So I should make it so only QA’s can move a card to done! Right?”

Wrong! I think so anyway – Its true that the QA should be the only person actually exercising this change but don’t restrict it because you then create critical dependencies on someone in that group!

“But” they say, “If I don’t then ANYONE can do it!” – Correct – But how dumb would you have to be??

On most cars anyone inside the car can pull the handbrake! They don’t however because its stupid!

The idea that one of your team members will go into a mingle instance and maliciously alter your cards is the same as a passenger pulling the handbrake – If that is happening you have MUCH bigger problems than access control J

So why start a post about self-organizing teams with a rant about access control? Easy – If you force people into roles they will only do that role!

As an example I went on a canal boating holiday across the Pennines (A mountain range in the UK) last week – For anyone who has driven a boat on a canal (and particular one that goes over a mountain range) there are a LOT of locks – These things have loads of moving parts and take about 10 minutes each to cycle.

The tasks required are

  • Drain the lock if it’s full
  • Close sluice gates
  • Open the lower lock doors
  • Get boat in and stopped
  • Close lower lock doors
  • Open top sluice gates
  • Flood lock without destroying the boat
  • Open top doors
  • Get boat out of lock
  • Close top sluice gates
  • Close top lock doors
  • Go to next lock 

There is quite a lot to do – Now we had a particular lock we needed to get to by a time and that was all the “team” knew – We had 3 windlass handles – some ropes – a British waterways key and not enough time.

Now considering this was all for a mate’s birthday no one really wanted to turn around and give everyone jobs – it was a pretty free flowing affair

So here is what happened next

We had established a common goal – Get the boat to the controlled lock at the summit by 1 pm for our appointment passing through 10 locks and a few miles of canal en route. We all believed it was possible.

A couple of the guys grabbed some lock handles and hopped off the boat

At the first lock we were delayed to drain it – The ground crew discussed this while the lock cycled and dispatched one of the three with handles off up the canal to see if the next lock needed drained (Retrospective?)

They finished cycling the lock

When we got to the next one there was a brief delay as the doors opened and the lock crew again discussed how this one had gone – Again the forward lock guy headed off up the canal – I had inherited holding the rope to stop the boat from getting smashed – One of our team had taken over driving duties and the most hung over of us put the kettle on and kept the various team members fed on Tea / beer / etc.

When we got to the next one the lock had been prepped so well by the guy before all we needed to do was close the doors and start the water coming in – the lock crew had another brief retrospective and dispatched another of their crew up the lock to pass the revisions on to the forward lock hand with the British waterways key and from then on we were like a perfectly oiled machine cranking through the locks just about as fast as was conceivably possible. “Rock Pig” and “Capt Scrubhead” were plying everyone with tea, Biscuits, Beer, etc the team wanted for nothing in the performing of their primary duties and we were unstoppable

We didn’t make the appointment – Our initial estimate of 10 minutes / lock was out by about 5 minutes, which meant we were 20 minutes late (Yes I know the sums don’t add up but the other 30 minutes seemed to have been clawed back by sheer bloody mindedness of the team)

The team concerned had very rapidly worked out the most efficient way to achieve the goal in question Of their own volition– They self organized into the leanest lock crew you have ever seen.

At one of the last locks we caught another boat – I was driving by this point and the guy on the other boat asked me “So who is the skipper?” – I thought for a moment and realized we didn’t have one. No one was “in control” – everyone was executing towards a common goal to the very best of their abilities and communicating with every other team member – we didn’t need one! So I said what anyone would have

“Me” I replied J

The primary components that drove this brilliant self organization were:

The team were free to adjust anything they could control and discussed how to be more efficient at each lock
They all took it upon them selves as a personal challenge to achieve the impossible – It was the team Vs. the canal and they wanted to win!
Any and all needs they had regarding food / water – etc. were delivered quickly and efficiently by the tea and biscuits crew meaning they had little or no distractions from their primary task.

The end result of this particular adventure is that no one could have organized it any better – We all knew where we were and where we wanted to be and set about as a team finding the most efficient way of achieving this goal. I believe it was General George Patton who said “Tell a man what you want him to do and he will oblige, Tell him the goal you wish to achieve and he will astound you with his ingenuity” All to often we tell teams what we want them to do rather than the goal we want to get to – I think the latter is the best way to build a high performing agile team. 

SA and Wangler discussing finer points of Lock Etiquette with an anorak


Dave “t’Unicorn” - Forward lock and Crank Yanker 0
Chris “SA” Crank Yanker 1
Luke “Wangler” Crank Yanker 2
Richie “Capt. Massive” Persuader of stubborn Objects / Crank Yanker as required
Mick “Capt. Cutthroat” Caressing of Diesel – Running into things.
Yours truly “7 fingers” ropes and general dogs body
Lisa “Capt. Scrubhead” Provisions / Biscuits
Abigail “Rock Pig / Galley Slave ” Tea and general hung over duties.
Pete “Peg No Leg” anything a man with a genuinely broken leg was up to (Chucking ropes being one)

November 1 2012

Lean Processing of Plutonium 238

Reduced Cycle time, reduced inventory and continuous flow in the production Plutonium 238.

I’m an avid reader of New Scientist and this made me smile(You will need to create a user account on New Scientist to read the article).

Basically NASA is going to run out of Pu 238 within 10 years, which they need to power deep space craft like voyager, Cassini etc.


Because Pu 238 traditionally has been a by-product of making weapons grade fissile materials, which we don’t do any more. 


(Reproduced from Page 6 of http://www.nasa.gov/pdf/636900main_Howe_Presentation.pdf)

The options open to NASA are an entirely new energy source (Unlikely in the time they have) Better solar (Bearing in mind a probe that generates its required power via a 1 m2 solar array in earth orbit would require a 2000 m2 solar array by the time it gets to Pluto!) or restart Pu 238 production.

Traditionally this is done by “soaking” a big lump of Np 237 (Neptunium) in a reactor kicking out a bunch of Neutrons that bombard the 237 turning it into 238.

This takes a BIG reactor about 6 to 12 months to perform (Think Big set up costs – Huge reactor cores, All the Big Infrastructure projects of the 60’s USA)

Or there is this proposal (The report the graph above is from) which on Page 13 describes creating the plutonium in a small university sized reactor core using small pellets of Neptunium – Basically reducing Cycle time, reducing inventory and using continuous flow in the production Plutonium 238 to increase delivery and lower costs.

In some ways could be considered a lean processing of Np 237 to Pu 238.

Why bother?

Well when NASA were buying Pu 238 from the Russians the market rate was about $12m / Kilo (Gold / Kg is approx . 51,000 USD making Pu 238 about 244 times as valuable as gold.) 


August 14 2012

Why is defining a minimally marketable feature set so tough?

So I wrote a game for a course I also wrote called “Agile fundamentals for product owners”, the course is a heavily cut down version of more in depth technical versions Thoughtworks offer but the point of the game is to pit two teams against each other for transportation contracts. The winning team each round is the one that gets their solution to market fastest. OK so a little contrived but a few interesting things happen when you play the game.

1. The players start aggressively discounting features that aren’t essential – They suddenly really “get” the concept of a minimally marketable feature set.

2. When you ask them if they do this in their existing projects they unanimously say “no”.

3. the drive to do this comes from the fact they can see the other team approaching the same problem.

Which got me to wondering why they find this so hard in their actual business? The only real difference is they can’t see the other team they are competing with, but you can bet your bottom dollar they are out there somewhere.

Your only saving grace is the other team can’t see you either!

The reality of this situation is still the competitor who gets to market faster usually wins! Be it through understanding clearly what their minimally marketable feature set is or a good Continuous Delivery (CD) pipeline or ever through sheer bloody mindedness, I’d suggest Minimally marketable feature sets is probably the most important. If you couple that with a CD pipeline you are now in a very powerful position! – You now have the ability to repeatedly get changes into production that solves the problem faster than anyone else (or at absolute worst the same speed).

The winner in this situation is the team that really understand what their minimally marketable feature set is.

Do you?


August 3 2012

The devil of regression testing


"No sympathy for the devil; keep that in mind. Buy the ticket, take the ride...and if it occasionally gets a little heavier than what you had in mind, well...maybe chalk it off to forced conscious expansion"

 Hunter S. Thompson (Fear and Loathing in Las Vegas)

On our mailing list where we discuss all sorts of important development issues and organise pub trips, a mate of mine came up with an interesting problem to do with testing - It went a bit like this ..

“I've just been talking to someone who I has attempted agile without any QA or automated tests at all. Unsurprisingly they've seen an increase in regression issues and are now looking to retrofit done automated testing.”

As the resident tester it got me thinking. What is the cost of regression testing in an agile project ? - well the cost in my opinion is actually 0, zip, nadda, snake eyes !!

Right about now everyone who has faced the cost of regression testing is thinking I am smoking crack? or maybe hill billy drunk on the 4th of july? - I’m not and here is why.

Lets say you have a project you estimated at 30 points - whatever - you figure as you are going along you can do roughly 5 points a week including getting it manually QA’d in a test environment and showed with great fan fare to your product owner  - Happy days!! - you will be out of there cashing the check in 6 weeks... 

or will you.. 

What was your ACTUAL velocity??

Easy I hear you all say - 5 points!! 

The problem is, it wasn’t really - The 5 points a week was stuffed with tech debit, Now I’m not talking the stupid tech debit i’ve cited before where you just sweep all the hard stuff into the tech debit backlog to temporarily inflate your velocity (and we all know how thats going to end) I’m talking about serious tech debit that wont bite you for a month or so. The question is actually what did you DO for that 5 points? 

Write code that solved the problem?

Or write code that solved the problem with unit tests, integration tests, platform tests, automated UI tests that prove every build and deployment you haven’t broken anything??

In most cases its the former  - And here is where logically (though not financially I’m sorry to say) it doesn’t cost. What is actually happening is your velocity gets corrected. You weren’t doing 5 points, you were actually doing maybe 3 but incurring the tech debit of poorly tested code allowed the team to inflate their velocity to an unrealistic 5. The over all correction theoretically will be 4 weeks in this case - but anyone who has tried to go back and retrofit tests to poorly tested code will know its harder than writing them at the time. so in this case it will take longer. 

I guess if you can guarantee some other poor stooge will have to deal with it later you *could* give them crappily tested code to work with but once the smell has pervaded the building you wont be working back there any time soon and your rep wont be the greatest.


July 5 2011
Older Posts