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.
Tuesday, November 11, 2008
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
Subscribe to:
Posts (Atom)