Wednesday, May 27, 2009

Chocoholic agile adoption strategy - cont'd

After adopting the chocolate scale the team I wrote about has started using the scale as punishment for arriving late at stand up. The first person late must bring the smallest chocolate on the scale (furry friend), the second brings the next larger (chunky) and so on. The punishment resets after the 1kg block has been bought and consumed.

After a few days of non-belief and some small chocolate bars bought the team is now up to the 500gm block for the next late arrival, and has been for a week.

Sunday, May 24, 2009

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.

Thursday, May 21, 2009

Chocoholic agile adoption strategy

I have been working with a team that had a go at relative estimation of their work rather than absolute or duration based estimation. We had some difficulties that I may cover in another post - when I get my act together - but the most enlightening part of the process for me was coming up with a scale they were willing to adopt.

The team members were more comfortable with duration based estimates for their work, but it was hoped to move everyone away from this to a scale that didn't carry any commitment baggage. During the discussion on estimation this came up
"If I am doing this work then it will take a day, if someone else does the work it will take longer"
 this  gave us a basis  to talk about using a different scale that does translate between people and tasks.

Story points didn't mean anything to the team as they are not working on user stories. I flippantly suggested Gummi bears, and this was quickly changed by the team into chocolate. The chocolate scale - based on Cadbury's chocolate blocks - has been adopted.

From smallest to largest:
  • Furry Friends
  • Chunky
  • Half block
  • Family block
  • Half slab
  • Slab
Potential problems with the chocolate scale
How do you calculate velocity? Is it 5 furry friends and chunky? What does this mean? The team lead is looking at using the net weights of these blocks as a numerical measure, we'll see how it goes.

What about inconsistency across teams because of different scales? In the longer term I think this would be a big issue, currently there are only two teams using relative estimates (this team and one developer working solo) so it's not an issue now. At present this is traded off against having the team start to think about their work in a different way. Eventually it may be required to standardise for communication and metrics,  the risk of this approach is to give the team control of something and then take it away.


What did this achieve?
The team now has a scale that is their own, I think ownership is important when you are asked to change. It might be flippant, but it is relative and there can be no confusion as to whether this is a commitment or an estimate. (Though I'd love to hear the usual please reduce your estimates conversation "4 family blocks and a chunky, come on that's way too big, surely it's only 3 blocks and a furry friend".)

The team have also estimated 2 weeks of work using this scale. Previously the estimation process stalled now using their own scale it was estimated very quickly.


Monday, May 4, 2009

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


Tuesday, April 14, 2009

Some observations on my boys

I have two boys aged 5 & 3.  I have no idea how my gender survives beyond this age range, here's why:

No distance is too short that I can't cover it at full speed.

I like to carry out conversation at ear splitting volume levels.

Anything you ask me to do is, at best, a mere suggestion (unless preceded by "I've told you x times already").

"yeah, she's crying" is empathy.

My selective memory is photographic "awwwww I never get to stay up".

The direction I am running is not the direction I am looking.

I am in constant denial "I'm not a little boy, I'm a big boy.  He's a little boy" .... "No I'm not. Muuuuuuuuuuuuum!".



Are defects the original user stories?

Just asking, and yes the defect comes after you've written something and someone somewhere found out it was not working as expected, but they feel similar to me.  Well at least similar in the context of "We have to have a requirements document signed off by everyone up to the CEO before we can even begin to consider to think about starting some kind of technical specification for the solution, so we could never use stories."

I would guess you already have defects, and when you are decide to fix these there isn't a document that bundles them together in some way (why would you try to do this, most defects would be independent, not all, but most).  There wouldn't be a sign off process, there is nothing to sign off.  The person doing the fix would need to spend time talking with the people who found the defect, and others to work out how to fix it and what the fix will look like - hopefully.

The defects would be - to a greater extent - recorded from the perspective of someone outside the system, rather than a technical task.  Of course there would be some prioritisation on what to fix first, because some defects have a greater impact/value than others.

Defects come with test criteria as standard.

It all feels very story like to me.  Surely if you can work with defects, then it shouldn't be too much of a leap to work with stories.  Maybe.

Friday, April 3, 2009

HBR bloggers wake up; find themselves in 1950s Japan

Managing Resources in an Uncertain World

From a blog called "The Big Shift".
We're moving from a world of push to a world of pull. Push programs operate on one key assumption - that it is possible to forecast future demand. When demand can be forecast, we can efficiently push resources to where they will be needed when they will be needed. But what happens when our forecasting ability diminishes--as it surely has in these big shifting times? Push programs become bottlenecks preventing effective responses to unanticipated changes in demand. In the business world, the result is often large accumulations of inventories.
I hope this isn't new to the authors.  It's probably new to some of the readers.
We only need to look at our dismal record in forecasting business cycles, financial risk, and earnings projections of individual firms from quarter to quarter to see that forecasting is no longer working as well as it once did.
When did the forecasting work?

Saturday, March 14, 2009

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 (Agile Software Development Series) 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.

Tuesday, March 10, 2009

Something you can talk about at dinner

Lying in the shade, drying off after swimming. My two boys jump on my back and proceed to blow loud, and long raspberries. There is the occasional pause for laughter if one of them lets out a particularly good sound.

My eldest takes a breather to tell me;

"Dad, you can talk about this at dinner"

Rasing boys

I was putting on a "rashie" as I was about to go for a swim and my eldest boy comes out with
"Dad your tummy is very big"

Fair enough, I do support the Australian reputation as the fattest nation and I do it well.

"yes Mate, it's too big" I reply.

"no Dad, it's way way way way waaaaaaaaay too big"

Tuesday, February 24, 2009

Chick Corea Five Peace Band - amazing


"Will Kenny Garrett's sax live?"  was what I kept thinking during his first solo after the interval.  It was an amazing performance. Mr Garrett took the sax places it really shouldn't go, and was lucky to make it back from.  I'm sure watching Pete Townsend smash up a telecaster was great, but Garrett did it with no percussion required.

The Five Peace Band concert was in the Concert Hall, in the Sydney Opera House.  (Both named in the traditional "name it what it is" Australian way.) We had seats a few rows back staring at Chick Corea, and (to our pleasant surprise) with a clear view of Brian Blade, the drummer. Listening to five musicians who use all elements of music in their playing is great in the concert hall as the sound is so good.  There's no fancy light show or pyrotechnics, it's just the music, and the music was brilliant.

The concert was only seven tunes, each one packed with a density of virtuosity that almost hurt. I don't know the full set list, but they did a blues "New Blues Old Bruise", a weird assed seven final sections Chick Corea thing"Hymn to Andromeda", something from Milestones, and encored with "In a silent way".  All very tasty.  Each player given space to solo, with the rest of the band following their lead; louder, quieter, pushing the beat, laying back, repeating phrases, all brilliant playing.  Then for fun Chick, John and Kenny switched to 4s, ie four bar solos in turn, utter show offs.

Kenny Garrett was the highlight.  Amazing sax work.  Brian Blade and Christian McBride were the surprises.  Blade looked to me like a happy idiot who was allowed to play on the drums, constantly smiling.  His fills were amazingly tight, and just when I thought he would never settle into a groove he pulled one out and sat on it for ages. 

McBride is a great bassist.  Used upright and electric as appropriate.  His "bring the house down" solo was on the upright, and again the sound quality was excellent, we didn't miss a note.

John McLaughlin said that he and Chick Corea have been collaborating for 4o years, which is a healthy amount of time to be working with someone - even on and off.  (I did think there are people in my industry who haven't collaborated for 10 minutes.) It's great to see such excellent musicians working together rather than trying to out do each other.  There was no mystical connection between them due to the time they had been together, but they listened to what each other was doing and played off that.

We didn't all rise when the jazz fusion nobility entered, maybe we should have.   We did when they left.

Saturday, February 14, 2009

Behind Closed Doors: working with people

Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers) Behind Closed Doors: Secrets of Great Management by Johanna Rothman


My review


rating: 4 of 5 stars
A good book with clear ideas that are well presented.



The over all human-focus to the techniques is excellent and very relevant for managing in a collaborative workplace. There are techniques for coaching, delegating, prioritising and planning, giving feedback, facilitation and oodles of others. The descriptions of the techniques are short but the brevity of lessons does not reflect a lack of usefulness, rather a deep understanding and distillation of the essentials.



The book has a story as well as factual advice. Having the story can give the reader a greater understanding of the application of the techniques, as well as taking the lessons out the fact/instructional education mindset and making the lessons more humanly applicable - it is a book about dealing with other humans. Unfortunately the dialogue is contrived (ok, as it's fictional it must be), and Sam is a some kind of omniscient super-manager who always has the right answer, rather than a real person dealing with the complexity of dealing with people. It was ok, but not great.



Having the Techniques section at the end is fantastic, this shows great respect for the people who will use this book saving them from trawling through the pages looking for these handy tidbits.



Despite the the story line I think it's well worth the read, and I should have pulled it off the shelf much earlier than I did.








View all my reviews.

Scrum Chef

Similarities of Iron Chef (Japan) and Scrum:

ScrumIron Chef
Time boxing60 minute battle
Sprint themeTheme ingredient
Single Product ownerChairman Kaga
Sprint planningMenu planning (esp Michiba)
Daily ScrumRegular getting together of chefs with Iron chef/challenger
Sprint reviewTasting and judgement
Sprint retrospective - - -
Self organised teamsIron Chef/Challenger with a team of trusted chefs carry out the work


OK, there are quite a few differences too.


Wednesday, January 14, 2009

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 (2nd Edition) 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.

Goal based design (with bad photos)

I don't get excited about car parks ("parking lots" for any non-Australian, or "core porks" for any South Africans) , if I had to list my top five car parks I'd be hard pressed to get beyond the first, and that's only because I now have one.  I drove into a car park a few weeks ago and was greeted by a big sign informing me how many spaces they had for my car. Blah, seen it before.

This sign was curiously different, rather than "We have 786 spaces where you aren't", it looked like the information might change. 

One of my daughters asked "What are those lights for?" and before you could see "geek car park love in" all was revealed.


It's a wonderful arrangement, when the space is empty the light is green (see above).  When the space is occupied (by a car or silly people), the light is red (below).  So when I drive around the level I can see where to aim my car without the hassle of driving up and down trying my luck.

        

If you deserve a special space, you get a blue light (no disco, sorry). 
What struck me was that someone thought about what you want from using a car park - a space as fast as possible and or as convenient as possible - and came up with a nice way to help the driver achieve that goal.  Having been back on a wet day with the car park near full, it was fantastic, child yells out "there's a green light" and off we go to the empty space. There was only a short drag race with another car heading for the spot, but my van had the momentum, they backed off and we won, woohoo.

Monday, January 12, 2009

Christmas weirdness

My mother bought this tin of biscuits for my family because she thought "you might like the picture on the lid". Strange idea in itself, but biscuits are biscuits and I'm not going to say no.



Bothering to read the side of the tin to see just how messed up the ingredients are I noticed that the "Photograph is a serving suggestion only". This may be fine if you're Bertie Wooster, but I had trouble getting all this arrange just to eat some shortbread.



After I got over the locomotive weirdness I noticed the extra-sureal bonus. "Biscuits not at actual size". How does that work? How are the biscuits in the tin not at actual size? Is this why I sometimes didn't feel sated after just one?