I believe that if you take some good people, keep them happy and give them interesting work, you get good output. So at the start of a retrospective, I've started doing a quick anonymous happiness check, similar to the Retrospective Safety Check.
The How-to
Everyone takes a post-it and writes on how happy they are: 1 to 5. '1' being totally fraked off, '5' suggesting they are having a pretty damn good time (considering its work). The team fold these up and put them in the middle and then we stick them to the whiteboard. There is a quick chance for the team to make any comments and to take a second to reflect before we move on to the rest of the retrospective.
However its a guide to us all in the group to consider how everyone else is feeling, and another dimension to safety, but its as its not about the session, it something the group should continue to think about. Its also something I take away and can help me make choices, particularly if I take samples across a number of Retrospectives.
Current Thoughts
I don't think this will work for every team as the the trust and honesty has be high (sometimes an trust/honest check might be better), but it can be a good feeling or maybe a warning indicator to the team.
Developers only count to three
Monday, 21 January 2008
I have this theory that developers can count accurately up to three. Just like my cousin could, back when he was tiny, we all count 1, 2, 3, more, and lots. That’s it, as good as it gets, so we’d better work with it.
Back a few months ago, a team I was in was having a problem with ‘exploding cards’ – they would be estimated at the IKO[1] to 6 or 7 days, but then when played, sometimes we’d burn double or more days to complete them; however small cards would be estimated pretty accurately.
As an experiment we tried taking any cards that looked like it was going to get an estimate of more than 3 (though a little pre-IKO analysis) and slice it up in to parts. Each part was estimated in the IKO and played as a separate card. It wasn’t the only thing we did to fix the problem, but we don’t get exploding cards any more and I think this went a fair way to fixing it.
Having smaller cards did have some side effects, some of which I’ll write about in a while, perhaps..
Some reasoning?
Mind Hacks (by Tom Stafford & Matt Webb) has some commentary on counting – it says we have two way of counting, yer standard counting – where you check items off one by one, and Subitizing which allows us to almost instantly spot up to 4 items; counting comes in once this quotient is reached. Now Mind Hacks suggests that this is a side effect of the visual processing part of the brain, but it seems to me to hold up for non-visual counting also.
[1] Iteration Kick Off
Back a few months ago, a team I was in was having a problem with ‘exploding cards’ – they would be estimated at the IKO[1] to 6 or 7 days, but then when played, sometimes we’d burn double or more days to complete them; however small cards would be estimated pretty accurately.
As an experiment we tried taking any cards that looked like it was going to get an estimate of more than 3 (though a little pre-IKO analysis) and slice it up in to parts. Each part was estimated in the IKO and played as a separate card. It wasn’t the only thing we did to fix the problem, but we don’t get exploding cards any more and I think this went a fair way to fixing it.
Having smaller cards did have some side effects, some of which I’ll write about in a while, perhaps..
Some reasoning?
Mind Hacks (by Tom Stafford & Matt Webb) has some commentary on counting – it says we have two way of counting, yer standard counting – where you check items off one by one, and Subitizing which allows us to almost instantly spot up to 4 items; counting comes in once this quotient is reached. Now Mind Hacks suggests that this is a side effect of the visual processing part of the brain, but it seems to me to hold up for non-visual counting also.
[1] Iteration Kick Off
Labels:
estimation
Hullo. This is my new Blog. Say hullo blog.
Thursday, 17 January 2008
I’ll be posting my thoughts and experiences as I work in teams on agile projects, and some of the ideas and innovations we try out. If I’m feeling bold I might post some views on how I think teams should be run – mostly to see if I change my mind over time and perhaps to see what other views there are.
Also, over the coming year I will be learning how to be a kayak coach and perhaps a sea kayak expedition leader. I'm hoping my learnings will proove to be applicable to coaching and team leading in general and I'll be posting my findings here.
I'm very happy to get comments and feedback on anything I write, so don't hold back, ya hear.
Also, over the coming year I will be learning how to be a kayak coach and perhaps a sea kayak expedition leader. I'm hoping my learnings will proove to be applicable to coaching and team leading in general and I'll be posting my findings here.
I'm very happy to get comments and feedback on anything I write, so don't hold back, ya hear.
Subscribe to:
Posts
(
Atom
)