Apparently changing the labels for your blog posts makes them pop to the top of the blogs.thoughtworks.com list.
Apologies for the spamming.
Wednesday, November 12, 2008
Tuesday, November 11, 2008
It works, who'd have thought?
Why do a stand up?
Last week I had a call from the lead that is not on same site as the QA ask "can we do a deploy, or will this affect the testing?". It's nice to be asked, and the answer was easy "In the stand up the QA said she was not testing in that environment today..." and just to keep everyone chatting "...give her a call though".
Why demonstrate at the end of the iteration?
Business availability on my current project is not a problem, they're at stand up, they're around the team, they're on the phone, they're there, it's great. Despite this proximity and their close involvement with work as it progresses, at the last demonstration they asked "what are we doing about saving in this app?". Then there was a discussion about what they understood the behaviour should be and why. It was great to have this feedback with entire team there to hear, question and understand their ideas.
Last week I had a call from the lead that is not on same site as the QA ask "can we do a deploy, or will this affect the testing?". It's nice to be asked, and the answer was easy "In the stand up the QA said she was not testing in that environment today..." and just to keep everyone chatting "...give her a call though".
Why demonstrate at the end of the iteration?
Business availability on my current project is not a problem, they're at stand up, they're around the team, they're on the phone, they're there, it's great. Despite this proximity and their close involvement with work as it progresses, at the last demonstration they asked "what are we doing about saving in this app?". Then there was a discussion about what they understood the behaviour should be and why. It was great to have this feedback with entire team there to hear, question and understand their ideas.
Scrum certification test
At the Stockholm Scrum Gathering there was beta of the soon to be used test for CSM certification. It was an online, multiple guess test that covered topics you'd read in the three scrum books, and learn on the course or working on a project using scrum. There were a few questions on the agile manifesto, something I don't remember talking about when I did the CSM course. I thought it was quite good, and many of the questions required some thought, rather than a rote response.
After InfoQ wrote an article* on the test there has been an almighty flap (big enough to penetrate the usual volume of noise) on the Yahoo scrum development group. People firing off their 2c worth (0.5 c Australian) on things like:
The only point from the whole broo-ha-ha worth repeating is from Ron Jeffries:
"How did it suddenly get necessary to do everything right the first time?"
* article in the sense of taking quotes from the Yahoo group and arranging them.
BTW - My mark was 88! Missed the top score by 1. Blast.
After InfoQ wrote an article* on the test there has been an almighty flap (big enough to penetrate the usual volume of noise) on the Yahoo scrum development group. People firing off their 2c worth (0.5 c Australian) on things like:
- Certification means nothing
- The test is ridiculous
- It's testing the wrong stuff
- The CSM is not what people really want
- You could end up learning the wrong thing by taking the test
The only point from the whole broo-ha-ha worth repeating is from Ron Jeffries:
"How did it suddenly get necessary to do everything right the first time?"
* article in the sense of taking quotes from the Yahoo group and arranging them.
BTW - My mark was 88! Missed the top score by 1. Blast.
Sunday, November 9, 2008
washing up
disappointment
Washing up (washing the dishes) after dinner was always a power game when I was a lad. There were three jobs to do for the kids to do, wash, dry, put away, and there was always the shout "I'll put away" because this was particularly cushy. I remember one evening when my brother was on the gravy "putting away" train he declared "I'm leaving after I put that knife away", I seized the opportunity to have my brother trapped in the kitchen for all eternity by putting the knife away myself. I was sure I had delivered a crushing blow, the logic was brilliant, he just walked off, my cries of "but you said 'I'" fell on deaf ears.
After a kitchen re-fit my Dad created a hole big enough for a dishwasher. He ran some tubes into the back of the sink and did some other magic, and stuck a dishwasher into the gap. This was fantastic as we wouldn't be fighting any more about who was doing what job, after dinner would be a time of love and caring, communal, domestic, happiness. The family sat around the table as Dad went through the instructions for the new wondrous device (curiously, reading instructions before use is not something that is genetic). To my horror there was a list of items that couldn't be washed in the machine. To steal from Douglas Adams it's like a video recorder (look it up kids) that would only record some shows and not others. What a waste of money! Piece of junk! It wasn't a dishwasher, it was a (Some)Dish(es)washer. The games continued.
service
My Father-in-law is a very generous man in all manner of ways. But he's not a man of great "practical skill", so we don't ask him about fixing holes in walls and such work, but he is a domestic wonderman. Within minutes of arriving in one of his children's homes he is at the sink, sorting, filling, tidying. When you have one or more pre-schoolers the dishes stack up like a students kitchen. Towers of plastic bowls, with branded cartoon characters and food stuck on with the strength of a mother's character label, it's always too much to comprehend, so you use the least disgusting equipment for the next meal. Having a compus adult waltz in and re-arrange it into an order and clean mass is wonderful, beyond a dream. It seems like an utterly inconsequential act until it is done for you.
joy
All my horde of kids (4, what were we thinking?) have loved to stand on a chair next to me when I am washing up. When they are two or three years old they take great pride in helping, picking the next thing to wash, and dumping it with a splash in the sink (extra points for covering Dad with the spray). It has been a great time to talk with them about everything and nothing, "whose plate was this", "what can you see out the window", "yes, that is water running down the glass, who put it there?", "look at the angles the bubbles intersect at" (closely answered by "Bubbles, yey"). Now my girls are older there is less wonder in helping with this chore but there are still good conversations and occasionally some splashing.
secrets
We occasionally torture our children with domestic work. The brief effort of washing up is met by my eldest with a look of disgust, of course her little sister jumps straight in (what a goody two shoes). After brief lecture on the topic of "you have to do something for your pocket money" there is a pair at the sink. Within a few plates the conversation is flowing, but hushed. Sometimes we hear riotous laughter, sometimes a name is exclaimed. Then whenever the girls are asked what they are talking about, it's always a quick exchange of glances and a reply of "nothing".
Washing up (washing the dishes) after dinner was always a power game when I was a lad. There were three jobs to do for the kids to do, wash, dry, put away, and there was always the shout "I'll put away" because this was particularly cushy. I remember one evening when my brother was on the gravy "putting away" train he declared "I'm leaving after I put that knife away", I seized the opportunity to have my brother trapped in the kitchen for all eternity by putting the knife away myself. I was sure I had delivered a crushing blow, the logic was brilliant, he just walked off, my cries of "but you said 'I'" fell on deaf ears.
After a kitchen re-fit my Dad created a hole big enough for a dishwasher. He ran some tubes into the back of the sink and did some other magic, and stuck a dishwasher into the gap. This was fantastic as we wouldn't be fighting any more about who was doing what job, after dinner would be a time of love and caring, communal, domestic, happiness. The family sat around the table as Dad went through the instructions for the new wondrous device (curiously, reading instructions before use is not something that is genetic). To my horror there was a list of items that couldn't be washed in the machine. To steal from Douglas Adams it's like a video recorder (look it up kids) that would only record some shows and not others. What a waste of money! Piece of junk! It wasn't a dishwasher, it was a (Some)Dish(es)washer. The games continued.
service
My Father-in-law is a very generous man in all manner of ways. But he's not a man of great "practical skill", so we don't ask him about fixing holes in walls and such work, but he is a domestic wonderman. Within minutes of arriving in one of his children's homes he is at the sink, sorting, filling, tidying. When you have one or more pre-schoolers the dishes stack up like a students kitchen. Towers of plastic bowls, with branded cartoon characters and food stuck on with the strength of a mother's character label, it's always too much to comprehend, so you use the least disgusting equipment for the next meal. Having a compus adult waltz in and re-arrange it into an order and clean mass is wonderful, beyond a dream. It seems like an utterly inconsequential act until it is done for you.
joy
All my horde of kids (4, what were we thinking?) have loved to stand on a chair next to me when I am washing up. When they are two or three years old they take great pride in helping, picking the next thing to wash, and dumping it with a splash in the sink (extra points for covering Dad with the spray). It has been a great time to talk with them about everything and nothing, "whose plate was this", "what can you see out the window", "yes, that is water running down the glass, who put it there?", "look at the angles the bubbles intersect at" (closely answered by "Bubbles, yey"). Now my girls are older there is less wonder in helping with this chore but there are still good conversations and occasionally some splashing.
secrets
We occasionally torture our children with domestic work. The brief effort of washing up is met by my eldest with a look of disgust, of course her little sister jumps straight in (what a goody two shoes). After brief lecture on the topic of "you have to do something for your pocket money" there is a pair at the sink. Within a few plates the conversation is flowing, but hushed. Sometimes we hear riotous laughter, sometimes a name is exclaimed. Then whenever the girls are asked what they are talking about, it's always a quick exchange of glances and a reply of "nothing".
Thursday, October 30, 2008
The best things in life are free, but that's for the birds and the bees
Compensation of agile teams (XP teams, scrum teams, what-have-you) is a tricky issue. Ken Schwaber takes a stab at it in "The Enterprise and Scrum" (if you haven't read it, the bad news is the lack of Star Trek references) where he ties parts of compensation to enterprise performance (doesn't even say "warp factor" anywhere) which is nice because you want everyone focused on the enterprise and not their individual role. Mary and Tom Poppendieck have a swing at it in "Implementing Lean Software Development" and make some nice points about promotion, influence and my favourite "Find better motivators than money" - something I particularly support because
1 - I'm not motivated by money (ok I like not being poor, but I prefer books & music to cash though I do like Pink Floyd's Money)
2 - It works with Prof Vroom's expectancy theory, which looks to have some reasonable thinking behind it and how can you doubt someone with onomatopoeia for a surname?
The problem with compensation is - IMHO - organisations couple compensation with organisational structure and motivation/incentive (can you couple three things?). The higher up the structure the more compensation, and the bigger and broader the bonus (eg retention bonuses). When you have a self-organising, cross-functional team the structure is removed. These teams are organised around enterprise/product/project goals so incentive for role based performance fractures the team mindset.
So here is an idea I have been toying with ready to be torn apart by better thinkers.
Salary should be a factor of responsibility and (positive) influence (ok that does mean the higher up you go in the org chart the more salary you should have). Individuals with great deal of organisation experience should have both of these, ie if you can influence how the organisation behaves you should have some overt responsibility for the outcome. This allows for people with different skills and preferences to be adequately payed without giving up their vocational passion to earn more by becoming a manager.
If there must be a bonus give it at the team level, if there are multiple teams give it at the project level. Then have the team decide how to adequately distribute the bonus. Wait, that was too easy, and you can't trust the team to look after that kind of thing - but you can trust them to deliver on a strategic, money making project.
Ok, how about do it like this. If there is monetary bonus it should be associated with the outcome of some work. Some of the benefit the organisation receives from this work should be taken to reward the team. I now depart from K Schwaber's idea in that I think the bonus should distributed dependant on your contribution, and not you seniority. Taking Kerth's Prime Directive (that's a touch treky "remember the prime directive number 2s") everyone has worked to the best of their ability and I think should be rewarded evenly, they are already being payed based on the difference in influence and responsibility so don't double up.
Distribute the bonus based on the number of days/iterations people were working on the project. If you're on the gig from day one, you receive the maximum amount, if you're on it one day it's the minimum. People who work across projects in a kind of consulting role should pick up the dosh from all the projects they touch.
To make this work all projects will have to have explicitly stated value that can be demonstrated, which is surely a good thing. Think of the pleasure of portfolio management.
A side effect would be that everyone wants to be on a small team doing a high value project. Which is ok, because why would you do low/no value projects, and to deal with the need to have longer project have these projects do multiple releases to deliver some return before the end of the project.
No one will want to work in BAU or Support, so get rid of it. "Developers should eat their own dog food" J Sutherland 2008. If you make it/design it/depploy it you're responsible for it. So this should keep people focused on delivery high quality results.
The product owners that regularly return their estimated value would quickly stand out, not just in the finance department, but when teams form everyone will want to work with these people.
There must be significant problems with this agile utopia, but I hate to contradict myself so I'm not going to think about it. I also didn't bother with expectancy theory and trying to work out the motivators for individuals, get over it - I did. There is nothing here about how to hire or review people if this is implemented, sorry about that.
1 - I'm not motivated by money (ok I like not being poor, but I prefer books & music to cash though I do like Pink Floyd's Money)
2 - It works with Prof Vroom's expectancy theory, which looks to have some reasonable thinking behind it and how can you doubt someone with onomatopoeia for a surname?
The problem with compensation is - IMHO - organisations couple compensation with organisational structure and motivation/incentive (can you couple three things?). The higher up the structure the more compensation, and the bigger and broader the bonus (eg retention bonuses). When you have a self-organising, cross-functional team the structure is removed. These teams are organised around enterprise/product/project goals so incentive for role based performance fractures the team mindset.
So here is an idea I have been toying with ready to be torn apart by better thinkers.
Salary should be a factor of responsibility and (positive) influence (ok that does mean the higher up you go in the org chart the more salary you should have). Individuals with great deal of organisation experience should have both of these, ie if you can influence how the organisation behaves you should have some overt responsibility for the outcome. This allows for people with different skills and preferences to be adequately payed without giving up their vocational passion to earn more by becoming a manager.
If there must be a bonus give it at the team level, if there are multiple teams give it at the project level. Then have the team decide how to adequately distribute the bonus. Wait, that was too easy, and you can't trust the team to look after that kind of thing - but you can trust them to deliver on a strategic, money making project.
Ok, how about do it like this. If there is monetary bonus it should be associated with the outcome of some work. Some of the benefit the organisation receives from this work should be taken to reward the team. I now depart from K Schwaber's idea in that I think the bonus should distributed dependant on your contribution, and not you seniority. Taking Kerth's Prime Directive (that's a touch treky "remember the prime directive number 2s") everyone has worked to the best of their ability and I think should be rewarded evenly, they are already being payed based on the difference in influence and responsibility so don't double up.
Distribute the bonus based on the number of days/iterations people were working on the project. If you're on the gig from day one, you receive the maximum amount, if you're on it one day it's the minimum. People who work across projects in a kind of consulting role should pick up the dosh from all the projects they touch.
To make this work all projects will have to have explicitly stated value that can be demonstrated, which is surely a good thing. Think of the pleasure of portfolio management.
A side effect would be that everyone wants to be on a small team doing a high value project. Which is ok, because why would you do low/no value projects, and to deal with the need to have longer project have these projects do multiple releases to deliver some return before the end of the project.
No one will want to work in BAU or Support, so get rid of it. "Developers should eat their own dog food" J Sutherland 2008. If you make it/design it/depploy it you're responsible for it. So this should keep people focused on delivery high quality results.
The product owners that regularly return their estimated value would quickly stand out, not just in the finance department, but when teams form everyone will want to work with these people.
There must be significant problems with this agile utopia, but I hate to contradict myself so I'm not going to think about it. I also didn't bother with expectancy theory and trying to work out the motivators for individuals, get over it - I did. There is nothing here about how to hire or review people if this is implemented, sorry about that.
Monday, October 27, 2008
The big bang smack down
Recently watched a couple of peeps from Salesforce.com give a presentation on their fanfare, reverb for the voice "agile transformation". There were many points to their presentation that made me go "ewww" and "ahhh" but what struck me the hardest was the big bang, all at once approach for the change.
My general opinion is incremental change, prove the new stuff works, and grow teams and projects organically from this. The hassle with this is the still running waterfall projects that will be running when the first agile project is started. No agile project in a normal waterfall shop will start well, it will be a complete disaster, every problem from every project will be exposed in the first few weeks. The project will be red - because project managers can only cope with three colours - and everyone up and down the food chain will hate it. The concurrent waterfall projects will be considered a haven of tranquility and good news, not like that *$#@ing agile project. Any team member who isn't comfortable in the new project will want to run back to the good ol' way and they will have the voice - from experience - to let everyone know how crappy the agile project is.
If you do all projects at once, every person and team, then everyone has a crappy time together. There is no "well running waterfall project" (ohh look at that spec, and that Gantt chart, now that's how you deliver software) to turn back to, to compare to, to contrast with. It's all or nothing. Lance the boil. I like it.
My general opinion is incremental change, prove the new stuff works, and grow teams and projects organically from this. The hassle with this is the still running waterfall projects that will be running when the first agile project is started. No agile project in a normal waterfall shop will start well, it will be a complete disaster, every problem from every project will be exposed in the first few weeks. The project will be red - because project managers can only cope with three colours - and everyone up and down the food chain will hate it. The concurrent waterfall projects will be considered a haven of tranquility and good news, not like that *$#@ing agile project. Any team member who isn't comfortable in the new project will want to run back to the good ol' way and they will have the voice - from experience - to let everyone know how crappy the agile project is.
If you do all projects at once, every person and team, then everyone has a crappy time together. There is no "well running waterfall project" (ohh look at that spec, and that Gantt chart, now that's how you deliver software) to turn back to, to compare to, to contrast with. It's all or nothing. Lance the boil. I like it.
Wednesday, October 15, 2008
Sydney Scrum User Group
Come and talk things Scrum.
This is an attempt to kick off the Sydney Scrum group.
Where: ThoughtWorks Level 8, 51 Pitt St Sydney
When: Wednesday 5 November 2008 - from 6pm
What: The Stockholm Syndrome - what happened at the Scrum Gathering in Stockholm
Contact: Lachlan
This is an attempt to kick off the Sydney Scrum group.
Where: ThoughtWorks Level 8, 51 Pitt St Sydney
When: Wednesday 5 November 2008 - from 6pm
What: The Stockholm Syndrome - what happened at the Scrum Gathering in Stockholm
Contact: Lachlan
Monday, September 15, 2008
Pre-school education, you can't beat it
Number One Son holding up a bowl full of steaming pasta "Dad, can you cool this down?"
"Just leave it mate," then I get clever "thermodynamics is on your side"
"I know..."
"Just leave it mate," then I get clever "thermodynamics is on your side"
"I know..."
Thursday, September 11, 2008
They're not people
My first wife was extracting children from the car at school today when she said "Come on people, out of the car".
The response from the eldest boy was "Mum, children aren't people"
The response from the eldest boy was "Mum, children aren't people"
Tuesday, September 9, 2008
Panic
I was content in the knowledge that my sweet biscuit craving was to be immediately satisfied. I opened the fridge then searched around for the packet to find there were no Monte Carlo's in the fridge - simply the only place to keep them. OMG!"Where are the Monte Carlo's?" I cry out. "Your children have eaten them" replies the echo.
Those meddling kids, always one step ahead of me.
In desperation - with my coffee going cold - I turn to the pantry - where the emergency supply is kept behind a glass sheet. There were no Monte Carlo's in the pantry. Even after I lifted some things up I could find none.
"Hey! There are no Monte Carlo's in the pantry", "That's right".
But there are venetians.
Ahhhhhhhhhhhhh
Sunday, August 31, 2008
Apple store in Sydney - revisited
When I went to the Sydney apple store to buy a nano for my sprightly 74 year old mother I was impressed with how things worked.
As there is no counter I had to find a suitably uniformed person to ask about the desired toy. This guy disappeared and returned with a lovely silver nano still in it's clear plastic shell. Then I asked "where do I pay for this". The transaction was handled on the spot, excellent, and the tax invoice emailed to me, double plus excellent.
My only complaint. The man in blue needed to go and get a paper receipt for me to sign.
As there is no counter I had to find a suitably uniformed person to ask about the desired toy. This guy disappeared and returned with a lovely silver nano still in it's clear plastic shell. Then I asked "where do I pay for this". The transaction was handled on the spot, excellent, and the tax invoice emailed to me, double plus excellent.
My only complaint. The man in blue needed to go and get a paper receipt for me to sign.
Sunday, August 17, 2008
"The race of his/her/their life." Yet another phrase that must die
Maybe if the losers were going to be sacrificed to the gods of Olympia, then I think it would be ok to describe it as "the race of their/his/her life", though perhaps the "race for their lives".
Wednesday, August 6, 2008
Probably bad advice
My youngest has just moved from a cot into a "big bed". Out of all the kids this has been the easiest transition. In the previous three attempts there are have been weeks of putting the child back in bed until you want to use super glue to keep them there.
This guy has had a couple of nights mucking about in his room, but not coming out to say "Hi" every few minutes. It's been great.
The nicest part of the whole experience is that we haven't had to use our tried and proven child torture method Removing the soft toy. We have given all our kids a few soft toy things to sleep with each night (ducks, bears, pigs, penguins) and the kids have become attached to these toys. It's very cute and very practical. After you've put them back to bed for the second time you can say
Ok, it's probably torture, but water-boarding is ok, so I can sleep well at night. It's certainly easier than having to sit outside the bedroom door and hold it shut (true story, not mine).
This guy has had a couple of nights mucking about in his room, but not coming out to say "Hi" every few minutes. It's been great.
The nicest part of the whole experience is that we haven't had to use our tried and proven child torture method Removing the soft toy. We have given all our kids a few soft toy things to sleep with each night (ducks, bears, pigs, penguins) and the kids have become attached to these toys. It's very cute and very practical. After you've put them back to bed for the second time you can say
"If you get out of bed again I'll take ".
We've usually started with a less significant toy and on a few occasions worked up to the final, favourite, night companion - that will only happen once, then they learn.Ok, it's probably torture, but water-boarding is ok, so I can sleep well at night. It's certainly easier than having to sit outside the bedroom door and hold it shut (true story, not mine).
Sunday, August 3, 2008
When you're certain you're right
On a cold winter morning (ok, it doesn't get that cold in Sydney) my eldest son son is sitting on the couch in pyjamas. We had this exchange...
My eldest son: I'm sooooo coooold, can someone get me blanket
His wise father: How about you get dressed and put a jumper and shoes on
My eldest son: That won't help meeeeeee
My eldest son: I'm sooooo coooold, can someone get me blanket
His wise father: How about you get dressed and put a jumper and shoes on
My eldest son: That won't help meeeeeee
Monday, July 28, 2008
"In the spirit of agile..." yet another phrase that must die
Changing your mind any time you want to, for no good reason, is not "in the spirit of agile".
Wednesday, July 9, 2008
If I could have a personal soundtrack
The kind that plays when I am doing stuff, something appropriate to my mood or action I would want to Nik Bartsch to write it. Stoa is an amazing piece of work, wonderfully indescribable. It sounds spontaneous, like some of the best small group jazz, but must be insanely well rehearsed. It feels like some of Reich or Glass's minimalist work with a less rigid frame, no phasing and more emotion.
I found Bartsch's description of "Zen Funk" confusing when I listened to Stoa. Having now spent up big on the Ronin canon I can understand the description.
REA certainly has some funky grooves, but not so much Stoa.My label is "Small Group Minimalism". A poor attempt to bring together the
ideas freedom (small group jazz) and constraint (minimalism).
Stoa takes you on a journey through brilliantly described aural landscapes. Each Modul has its own rhythmic and harmonic landmark that is regularly shown, sometimes in the distance or brought quickly into sharp focus. Sometimes built upon with extra timbres or dynamics, sometimes left starkly exposed like a solitary peak.
There is always a sense of motion with this music, fast - slow, staggered - even. The moving is well contrasted with periods of rest. Staring out a train window, as we are flying through stations with this music coming through head phones is an unreal experience taking me out of the carriage through the waiting crowds.
Stoa is both comfort music and music that demands my attention. I can't keep away from it, I listen to it at least once a month. It's musical crack. I find myself trying to tap out the polyrhythms on the mouse when my mind has wandered. It's way too addictive. I just need to stitch some little speakers into my jacket, have the nano buried in the pocket and get some clever-clogs to attach the controls to my heart-rate, blood pressure, and whatever chemical my brain is playing with at the time. easy peasy
The only hassle with this as my personal soundtrack is the deep loathing my wife has of it. Am I willing to pay the price...hmmm.
Modul 33
Sunday, July 6, 2008
Holiday Wall
First attempt at a holiday wall as suggested by DM...crumbs! The kids had fun putting this together. Cutting out the pics from the brochures and sticky these on the wall has increased their interest in the trip to the point that they are starting to pack. On the down side we now have to convince oldest boy that the plane won't be landing in snow in Launceston.
Monday, June 30, 2008
Movie Review - Indiana Jones & the Temple of Doom
Having sat through the new Indiana Jones movie we bought the original three on DVD. After struggling through the Temple of Doom my wife sum the situation up with:
perfect.
"I won't be disappointed if I never see that movie again"
perfect.
Tuesday, June 24, 2008
PowerPoint - Pitching out
"The Cognitive Style of PowerPoint: Pitching Out Corrupts Within" is a fantastic essay that should be read by anyone using a computer. Do it now. Go on. Off with you.
"PowerPoint promotes a cognitive style that disrupts and trivialises evidence"
When I joined TW I was amazed at the number times the peeps (TWers and Clients) referred to PowerPoint. I was particularly surprised by the term "deck", I hadn't heard it before, maybe I had been living in a bunker.
The idea was to produce a deck for this or that and stick it in front of the right people and something would happen. This clashed with two notions of mine:
1 - having spent time in Scrum land PowerPoint is shunned and replaced with showing off working software or having huge bits of paper stuck on walls showing stuff
2 - the agile principle that the most efficient way to communicate is face-to-face
Reading Tufte's essay just made me dislike using PowerPoint that little bit more. The biggest kick was reading about organising tabular data. This opened some old wounds I had received from trying to present this kind of information in my dark and dull past, just as PowerPoint was starting to take over the world. The impact of having to summarise, and dissociate data is beautifully demonstrated demonstrated by Tufte.
PowerPoint is becoming (or has become) ubiquitus as a way to present and organise information. It is part of school curriculum for the students to present a few slides using this tool. As a parent (gotta love that) this is troubling as my kids will not be learning how to organise and present their thoughts, they will learn how to pitch. I guess I had better procure a few copies of the essay to hand over to the teachers.
Tufte refers to PowerPoint as a "Projector Operating System" this change in language changes the way you use PowerPoint. Taking away the idea that the application is about presenting information deals it a blow that it should not recover from.
Friday, June 20, 2008
Apple store in Sydney
People travelled across the world and then queued up to get into this place. Inconceivable.
It's a pretty shop, in a fitted out by Ikea kind of way. The toys are nice, but nothing worth queuing for - and there will be another in a few weeks when the iPhone comes to town.
Do people queue when Walmart opens?
I wonder how the guys at Next Byte feel?
It's a pretty shop, in a fitted out by Ikea kind of way. The toys are nice, but nothing worth queuing for - and there will be another in a few weeks when the iPhone comes to town.
Do people queue when Walmart opens?
I wonder how the guys at Next Byte feel?
Wednesday, June 18, 2008
Sporting Team Analogies
After writing a sporting team analogy I read Peopleware and DeMarco and Lister don't like the analogy as it's all about competition. To be part of the team there is competition within the group to perform, and this will lead to disunity.
But what if the competition is to get into the team, and then you are treated as equals? Would this establish the a sense of eliteness that can help a team gel?
But what if the competition is to get into the team, and then you are treated as equals? Would this establish the a sense of eliteness that can help a team gel?
Sunday, June 15, 2008
Learning - Maturity
Watching two games of netball last weekend I witnessed an example of team maturity.
The first game was children learning their favourite game. Two good teams, but both are still learning how to play the game. Both sides were "teams", people drawn together with a purpose and direction. They worked together to achieve a goal - no pun intended.
The second game was a professional game with highly skilled and trained athletes. These teams are made up of masters of the game, some of the best players in the world were on the court. The rules were the same as the first game and the outcome was just as close (one point) but the execution was different.
The first teams were strongly focused on what they needed to do in their role, where they could go on the court, where their matched opponent was, what ritual in the game was being performed. The children would stop suddenly at the sideline or the line of their zone. They knew if they were Centre there was another Centre to look for, when the ball left their zone they stopped as there was nothing more they could do. They exemplified a strong demarcation in their roles and actions, and this is part of learning about the game. Just like learning a new role, or new job.
The second teams were markedly different. Apart from the skill, the boundaries were constantly being pushed. The ball moved forward, across and back down the court with the one team working as an organism attempting to achieve their purpose. Individual marking was replaced with a zone, if one-on-one marking was required marking your exact opposing player was less relevant, what mattered was that opposition players were all marked. The lines of the court meant Jump! Stretch! as the players played the ball in the air, not touching down out of the court or offside until they had passed. The team worked within the rules but pushed each one.
What am I going on about?
A team that works within its rules and boundaries without pushing these can achieve their goal, but is an immature team or a team that is learning what it can do. A great team is the team that pushes their boundaries to achieve their goals. The focus shifts from individual effort first to team first.
Hardly profound
The first game was children learning their favourite game. Two good teams, but both are still learning how to play the game. Both sides were "teams", people drawn together with a purpose and direction. They worked together to achieve a goal - no pun intended.
The second game was a professional game with highly skilled and trained athletes. These teams are made up of masters of the game, some of the best players in the world were on the court. The rules were the same as the first game and the outcome was just as close (one point) but the execution was different.
The first teams were strongly focused on what they needed to do in their role, where they could go on the court, where their matched opponent was, what ritual in the game was being performed. The children would stop suddenly at the sideline or the line of their zone. They knew if they were Centre there was another Centre to look for, when the ball left their zone they stopped as there was nothing more they could do. They exemplified a strong demarcation in their roles and actions, and this is part of learning about the game. Just like learning a new role, or new job.
The second teams were markedly different. Apart from the skill, the boundaries were constantly being pushed. The ball moved forward, across and back down the court with the one team working as an organism attempting to achieve their purpose. Individual marking was replaced with a zone, if one-on-one marking was required marking your exact opposing player was less relevant, what mattered was that opposition players were all marked. The lines of the court meant Jump! Stretch! as the players played the ball in the air, not touching down out of the court or offside until they had passed. The team worked within the rules but pushed each one.
What am I going on about?
A team that works within its rules and boundaries without pushing these can achieve their goal, but is an immature team or a team that is learning what it can do. A great team is the team that pushes their boundaries to achieve their goals. The focus shifts from individual effort first to team first.
Hardly profound
Frank Woodley is Possessed
Is Frank Woodley the funniest man in Australia? He's a lot easier to find than Rod Quantock so I think he might have to get my vote.
Possessed is a one man show about two people who are having trouble getting out of their current, unpleasent situation. The show had me laughing from the moment Frank came on stage. It has a mix of physical comedy, surealist stupidity,and general Frank Woodleyness - such as regularly breaking the 4th wall to talk directly to the audience, or comment on the show itself.
A great show and easily worth the price of entry.
Possessed is a one man show about two people who are having trouble getting out of their current, unpleasent situation. The show had me laughing from the moment Frank came on stage. It has a mix of physical comedy, surealist stupidity,and general Frank Woodleyness - such as regularly breaking the 4th wall to talk directly to the audience, or comment on the show itself.
A great show and easily worth the price of entry.
Thursday, June 5, 2008
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?
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?
Thursday, May 29, 2008
Some highlights from Waltzing with Bears part 3
The "meat and potatoes" section of the book. Here we're getting into the details of how TDM and TRL recommended we carry out risk management. There's a lot in here, the majority of the book, and I won't be going through all of it - buy the book if you want it all.
Risk management is about learning to live with uncertainty and having some degree of quantification of this uncertainty. Rather than saying "We'll get there some day", say "There is zero percent chance by next month, but 50% in 3 months, 75% in 5 months". (Putting bounds around uncertainty made me think of having clearly defined areas of doubt and uncertainty, Douglas Adams did some serious damage in my formative years.)
"Yesterday's problem is today's risk" but what if I bothered to do a root cause analysis, and solve the problem once and for all. Ahhhh haha, this is IT there's very little chance of that happening, and greater than 75% chance of coming across the same problem again. (Note the great use of the percentage.)
Use the knowledge of projects in your organisation to work out what the risks will be, and what the chance of these risks occurring is, so don't just make up a number like 75% (damn!).
Calculate budget and schedule reserves for the risks in the project. Spend time to examine the risks and how you will deal with them, how you will know you need to deal with them, can you actually deal with them.
Have a formal risk discovery process. Make sure that talking about risk is acceptable, maybe even admirable. Don't do this once, make it a continuous process.
Finally deliver incrementally. WHAT! It was all leading up to this. The best way to keep you risk under control is to do bits of the project, rather than big bang, one pass, all at once delivery.
Risk management is about learning to live with uncertainty and having some degree of quantification of this uncertainty. Rather than saying "We'll get there some day", say "There is zero percent chance by next month, but 50% in 3 months, 75% in 5 months". (Putting bounds around uncertainty made me think of having clearly defined areas of doubt and uncertainty, Douglas Adams did some serious damage in my formative years.)
"Yesterday's problem is today's risk" but what if I bothered to do a root cause analysis, and solve the problem once and for all. Ahhhh haha, this is IT there's very little chance of that happening, and greater than 75% chance of coming across the same problem again. (Note the great use of the percentage.)
Use the knowledge of projects in your organisation to work out what the risks will be, and what the chance of these risks occurring is, so don't just make up a number like 75% (damn!).
Calculate budget and schedule reserves for the risks in the project. Spend time to examine the risks and how you will deal with them, how you will know you need to deal with them, can you actually deal with them.
Have a formal risk discovery process. Make sure that talking about risk is acceptable, maybe even admirable. Don't do this once, make it a continuous process.
Finally deliver incrementally. WHAT! It was all leading up to this. The best way to keep you risk under control is to do bits of the project, rather than big bang, one pass, all at once delivery.
Friday, May 23, 2008
Hiring Pregnant Women
An interesting little conversation starter Hiring Pregnant Women - Christina Bielaszka-DuVernay
Would you hire someone if you knew you had to give them long-term leave soon after starting? There is also the chance that they will not come back to work. What if the child has special needs and the parent never returns? Maybe they will decide that parenting is more important than the success of your company - crazy notion. Some children can really suck the life out of parents with lack of sleep, so even though you have your employee back they are less than effective. The urge to discriminate would be extremely high.
This is particularly relevant in Aus right now as the government is looking into paid maternity, paternity and parental leave. Are we opening the doors to an increase in discrimination, or do we accept that as a potential negative for a stronger positive? Is this a question of values? Do we value parenting higher than paid work?
I would hope we are going to back parenting, but then I am biased.
Unfortunately I suspect most organisations hire with a very short term need. We need this person to start doing this job right now, and we hope there will be more work for them in the future. If this type employer has a pregnant (or likely to soon be up the duff) candidate and they must give this person maternity leave then they are looking at hiring a liability and will reject the candidate. So there are a few perspectives on this the first is that this is discrimination that is not based on poor fit of candidate (as the recruitment process is all about discrimination) and the second is that the candidate is lucky to avoid working for such fools.
Should we help the employer see the light and hire the right people, or just hope they make enough stupid decisions they have to close? Harsh and off topic, kinda.
Would you hire someone if you knew you had to give them long-term leave soon after starting? There is also the chance that they will not come back to work. What if the child has special needs and the parent never returns? Maybe they will decide that parenting is more important than the success of your company - crazy notion. Some children can really suck the life out of parents with lack of sleep, so even though you have your employee back they are less than effective. The urge to discriminate would be extremely high.
This is particularly relevant in Aus right now as the government is looking into paid maternity, paternity and parental leave. Are we opening the doors to an increase in discrimination, or do we accept that as a potential negative for a stronger positive? Is this a question of values? Do we value parenting higher than paid work?
I would hope we are going to back parenting, but then I am biased.
Unfortunately I suspect most organisations hire with a very short term need. We need this person to start doing this job right now, and we hope there will be more work for them in the future. If this type employer has a pregnant (or likely to soon be up the duff) candidate and they must give this person maternity leave then they are looking at hiring a liability and will reject the candidate. So there are a few perspectives on this the first is that this is discrimination that is not based on poor fit of candidate (as the recruitment process is all about discrimination) and the second is that the candidate is lucky to avoid working for such fools.
Should we help the employer see the light and hire the right people, or just hope they make enough stupid decisions they have to close? Harsh and off topic, kinda.
Thursday, May 22, 2008
Getting down in the Dip
Seth Godin - The Dip: A Little Book That Teaches You When to Quit (and When to Stick)
Is there anything to learn in such a short book? Especially when the author repeats himself so many times? It's good to quit, to succeed you need to quit because you can't do everything, people will tell you to never quit, quitting is good, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit. I get it.
I've never been one to listen to advice and I have quit many things, some of which have been significant some of which haven't
1 - Destructive relationships - close and not so close
2 - Studies - there's part of a PhD out there somewhere
3 - Books - what is so good about The World According to Garp.
4 - Games - Rayman Raving Rabbits, total crock.
I'm a quitter, and I do sometimes feel I shouldn't have quit. Sure it would be great to have a PhD, but I'd never use the knowledge, so why bother.
I have previously worked for a company that completely failed to understand when to quit. They stayed with appalling clients, getting paid well below market rate, doing lousy work and losing people because of all this. The strong belief that a customer, any customer must be kept at all costs was and is foolish. For example I asked the directors if they made any money out 3 years with one customer, as it seemed inconceivable and was assured (by one director) that they certainly had. A few days later the MD had done some useful book-keeping and showed me that at best they broke even. So they had a cliff rather than a dip and they should have quit and put their energy into something else.
I guess you can learn something from such a small book. (Or if you prefer, There are significant take aways, structured as learns, from this diminutive publication.)
And now I am quitting.
Is there anything to learn in such a short book? Especially when the author repeats himself so many times? It's good to quit, to succeed you need to quit because you can't do everything, people will tell you to never quit, quitting is good, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit, quit. I get it.
I've never been one to listen to advice and I have quit many things, some of which have been significant some of which haven't
1 - Destructive relationships - close and not so close
2 - Studies - there's part of a PhD out there somewhere
3 - Books - what is so good about The World According to Garp.
4 - Games - Rayman Raving Rabbits, total crock.
I'm a quitter, and I do sometimes feel I shouldn't have quit. Sure it would be great to have a PhD, but I'd never use the knowledge, so why bother.
I have previously worked for a company that completely failed to understand when to quit. They stayed with appalling clients, getting paid well below market rate, doing lousy work and losing people because of all this. The strong belief that a customer, any customer must be kept at all costs was and is foolish. For example I asked the directors if they made any money out 3 years with one customer, as it seemed inconceivable and was assured (by one director) that they certainly had. A few days later the MD had done some useful book-keeping and showed me that at best they broke even. So they had a cliff rather than a dip and they should have quit and put their energy into something else.
I guess you can learn something from such a small book. (Or if you prefer, There are significant take aways, structured as learns, from this diminutive publication.)
And now I am quitting.
Wednesday, May 21, 2008
Commitment test at Zappos
Bill Taylor has posted a neat little article at Discussion Leaders on about
Why Zappos Pays New Employees to Quit—And You Should Too
If you're too lazy to read the whole thing here are some nice bits...
After a week or so in this immersive experience [training], though, it’s time for what Zappos calls “The Offer.” The fast-growing company, which works hard to recruit people to join, says to its newest employees: “If you quit today, we will pay you for the amount of time you’ve worked, plus we will offer you a $1,000 bonus.” Zappos actually bribes its new employees to quit!
Why? Because if you’re willing to take the company up on the offer, you obviously don’t have the sense of commitment they are looking for.
Companies don’t engage emotionally with their customers—people do. If you want to create a memorable company, you have to fill your company with memorable people.
Why Zappos Pays New Employees to Quit—And You Should Too
If you're too lazy to read the whole thing here are some nice bits...
After a week or so in this immersive experience [training], though, it’s time for what Zappos calls “The Offer.” The fast-growing company, which works hard to recruit people to join, says to its newest employees: “If you quit today, we will pay you for the amount of time you’ve worked, plus we will offer you a $1,000 bonus.” Zappos actually bribes its new employees to quit!
Why? Because if you’re willing to take the company up on the offer, you obviously don’t have the sense of commitment they are looking for.
Companies don’t engage emotionally with their customers—people do. If you want to create a memorable company, you have to fill your company with memorable people.
Saturday, May 17, 2008
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>
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>
Thursday, May 15, 2008
Wednesday, May 14, 2008
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:
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
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.
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
Listening
Listening
- Allan Holdsworth - Hard Hat Area
- Allan Holdsworth - All Night Wrong
- Nik Bärtsch's Mobile - AER
- This Sporting Life
Subscribe to:
Posts (Atom)