Wednesday, October 26, 2005

Retrospectives and group development

It surprised me the difference a retrospective made. I didn't feel comfortable that we were skipping them, even thought the project was happily adapting on the fly. Retrospectives had been tried on a previous project and had not gone well. So, after 4 months of development we finally did our first retrospective. The project was in excellent shape, so it was a good opportunity. I was really amazed at the positive effect it had. What was most interesting to me was the effect the event had on the group -- we really started to gel as a team.

From 5 Stages of Group Development:

forming -> storming: risk conflict. 'To grow from this stage to the next, each member must relinquish the comfort of non-threatening topics and risk the possibility of conflict.'

storming -> norming: listen. 'The most important trait in helping groups to move on to the next stage seems to be the ability to listen.'

norming -> performing...'The Performing stage is not reached by all groups. If group members are able to evolve to stage four, their capacity, range, and depth of personal relations expand to true interdependence.'

Friday, October 14, 2005

middle-toy-sprint

Three thoughts keep circling in my mind lately, interweaving like a Celtic design: Stuck in the middle; "If it's not deployed, it's just a toy."; Everything is done in a sprint.

I generally find the middle part of any project really boring. I naturally love initiation. I have really learned to love completion. But the middle always sucks. Agile goes a long way to eliminating this nasty middleness. I think an ideal agile project would be completely devoid of this evil plateau of boredom.

For me, completion means software deployed in production being 'used' by users (maybe not in anger but worked with from a meaningful perspective). No toys. Initiation involves reviewing, planning, discussing. Not looking too far into the future and not predictive. Put these together and there's no need for middle.

I like the idea of absolutely everything being completed in a sprint. This seems like the right way to do things. Maybe 30 days is too long but if *everything* has to be completed then maybe not. It's a really long time to wait for feedback, but a nice tangible duration for project governance, planning (not predictive) and reporting. The people who think about money and value, love monthly reports. It's how they run their business. It's how they measure their success, and how they extrapolate their likely annual performance.

🐌 From Codex CLI to OpenAI API: Building a Smarter AI Worker in 24 Hours

From Codex CLI to OpenAI API: Building a Smarter AI Worker in 24 Hours How throttling led to a complete rewrite, cost optimization, and a mo...