Scientific Ink

Tag: Agile/XP

  • Make mistakes faster!

    Stumbling on Happiness

    So, a guiding and very freeing philosophy at my former workplace was “make mistakes faster”.

    It is part of the iterative and incremental philosophy of development. Instead of doing a huge waterfall process where the team works for months building the perfect design, architecture code, whatever, we should work iteratively and incrementally–deliver paper prototypes, functional prototypes, deliver something that can be responded to before the entire thing is built.

    The idea is we’ll make lots of mistakes in our work–so let’s get them out of the way as soon as and as cheaply as possble with quick prototyping, lots of communication, and an attitude of exploration. Let’s invest in small working pieces and get feedback sooner. Essentially, to solve a problem, try the simplest thing that could possibly work before investing in the perfect solution.

    So, I was intrigued to read in Stumbling on Happiness that “make mistakes faster” is scientifically shown to be better for our mental health. It seems that our minds are good at compensating for “sins of transgression” but much less good at compensating for “sins of omission”.

    Indeed, in the long run, people of every age and in every walk of life seem to regret not having done things much more than they regret things they did….The irony is all too clear: Because we do not realize that our psychological immune systems can rationalize an excess of courage more easily than an excess of cowardice, we hedge our bets when we should blunder forward. (p. 179 Stumbling on Happiness)

    So, what is good for our software development projects is good for our brains and well being. Good news! Let’s blunder along now….

  • uninescapable – the uncertainty cost of subcontracting

    Stumbling on Happiness

    So, my most excellent friend Chris has loaned me his copy of Stumbling on Happiness. It is giving me interesting things to think about including this:

    According to the author, there is something called an “inescapability trigger” that brings our “psychological immune system” of denial, looking to the bright side, and generally improving our experience of negative things.

    (more…)

  • IM/Chat Standup

    My goals for standup are:

    • actually communicate
    • get remote folks more familiar with each other (make Chicago and Berlin friends ;))
    • provide a forum so that I can act less as a clearinghouse/sole gate for communicating with remote folks (though I realize this is much of my job and will continue to be a big part)

    We’ve moved to IM/chat standup as a test to solve the fact that remote folks have a very hard time hearing us quiet folks at HQ.

    So far, the two standup addicts (me and talltom) are very chatty and slow, and the two IM pros are quick and to the point. I like the quickness, and to that end will try to type up a quick summary first and paste it in, but I miss something from the less efficient exchange of additional info and personality, so I think I’m going to continue to prattle a bit and encourage others to be a little less efficient if they are so moved.

    Essentially, I think standup is a bit more than a task list–it is some kind of weird vehicle for team. Not only do we get a sense of what the larger group is doing on a task level, but at its best we get a glimmer for how individuals are doing at it. I miss some of the additional information exchange that happens when people go off topic or make a joke. But, I’ve been one of the people “in the room” for the conference call standups, so perhaps IM standup is actually a higher-bandwidth channel for the remote folks….

    At a minimum, at least we’ve coined some new web acronyms: lbcot (let’s be careful out there-thanks to Stephen).

  • Virtual Stand-up: Extending the Circle

    So, a “stand-up” meeting is a communication ritual from Extreme Programming (XP). The developers were sick of long, boring meetings wasting all their time, so someone came up with the idea of ritualizing a quick and productive status meeting. Stand-up has to be short because no one is allowed to sit down.

    I believe in stand-up, it works. While I have perpetuated the stand-up ritual in my new job, extending it to a mixed group of physically present and physically remote folks is challenging. It is harder when some have never participated in a stand-up “in person”. Still, the benefit of this quick check-in with (and I hope for) the remote folks outweighs the awkwardness.

    Here are some general ground rules:

    • Stand-up happens at the appointed time with whomever is present. Currently ours happens at 10:30 AM, Eastern
    • Everyone stands
    • Participants pass a token: only the person holding the token speaks
    • The token-holder(s) should update the team on what has been accomplished since the last stand up, and what is coming this day. In a big or unfamiliar group, the token-holder starts with their own name, “Hi, I’m Joe, and today…” or in a paired environment, “Hi, I’m Joe,” “and I’m Susan, and we’re…“
    • The token-holder can ask the group for help to solve a problem, though things are solved off-line after stand-up with the appropriate folks
    • Stand-up should be called by an inanimate object rather than a person
    • The person at the end has to say “let’s be careful out there” or some variant on that phrase to close the meeting

    Here are some ideas for making stand-ups happen with remote team members

    • Tokens need to be passed “virtually” to and back from conference call participants, with the order called out
    • Remote team members should be responsible for getting their own inanimate objects to remind them (alarm in calendar)

    Rules of thumb for part-time team members

    • Part time folks should attend stand-ups part of the time.

    I’m curious what others who have tried this think needs to be added to our ritual or to this description.

  • Reusable practices?

    Four months ago (March, 2006), I signed on to be Director of Operations at a small web company.

    Tonight, I had dinner with a friend and former colleague. We’re both project managers and we both left an established XP shop in the beginning of this year. We compared notes on what we have tried in our new environments. Interestingly, we’ve been successful with different practices from the same set. She affirmed some of my experiences, and it was especially intriguing to hear where our experience differed. Here’s a little of my side of it. Sorry it is just a big list right now. I will expand certain parts of it sometime later….

    (more…)