Friday, August 26, 2005

What makes a great leader?

The Yipster's got me thinking about this with his post on project culture. I immediately thought of Level 5 leadership.

I think Jason’s blog entry follows on from a comment and a discussion, on the fact that managers do better than developers at the XP game. This came from Mike Lee who has recently run about 10 XP games for one of our clients, as a part of a company wide introduction to agile.

Why? Maybe because managers are better at self-organisation. The crux here I think, is that good managers are also good team members. This draws me back to Jim Collins’s research, that truly great leaders have the ability to work at all 5 of levels of his pyramid, and that skipping levels is something that needs to be made up later.

Thursday, August 25, 2005

Iteration Slop: trailer-hitched QA

We got talking about this at lunch today. Unfortunately I have not done an agile project that didn't suffer from this... from Michael Feathers IterationSlop:

"The worst form of iteration slop is what I call trailer-hitched QA. When your team does trailer-hitched QA the developers work until the last possible moment within the iteration and when the iteration ends, they hand off to the QA team. The QA team gets the "final" build and they work with it for a while, running more automated and manual tests. Often this takes close to the length of an iteration. At the end of the process, QA gives their approval and the development team looks back at them, in the distance, and says 'Great! We really did finish that work!'"

How common is this? Post me some numbers if you have a chance, % projects that you have been on where trailer-hitched QA was standard. At the moment I am 100% for two agile projects -- both were trailer-hitched (one successfully completed, the other looks good at the moment, although the QA is well behind).

Wednesday, August 24, 2005

Why does agile "feel" good?

Working on agile projects feels really good. Delivering regularly, writing lots of tests, integrating hourly, interacting with the customer. These are all truly gratifying activities from both professional and personal perspectives. But there's something more to this. Just standing in a agile project space, looking at the walls feels really good. Why? After think about this for a while I have finally formed a theory. To be honest my subconscious has been throwing me plenty of clues, I just haven't known what to make of them.

At school from age four to twelve, everything we did went up on the wall. The pictures we drew, projects we took part in, the words we need to learn. Everything important got stuck up one way or another. Regularly we refreshed the walls with new, important information. The wall was a source of learning, activity and history.

For weeks now, my mind has been flooded with images of childhood information radiators. I can clearly see the birds nest on the nature table, my paintings over the door, the index cards of "big words" on the wall. These images remind me of happy, productive times where learning was spontaneous - you just looked at the wall for information.

Further than happy childhood memories though, people have been drawing on walls since the dawn of time. Agile project spaces "feel" good because this is how we have presented, communicated and retained crucial information for eons. If it's important draw it on the wall and share it with other people.

(You can also send it "straight to the pool room" if it’s truly significant: The Castle :-)

Wednesday, August 17, 2005

The more you flow, the faster you go

I've just started working on an agile project with Darren Cotterill, in Sydney. Ben Hogan and Jason Yip have already blogged about it, so I thought I would chip in with my two cents.

The project is really quite agile but "officially" it's a waterfall project. We're considering hanging up a picture of a waterfall, just so we can point and say "look, there's the waterfall". Really there isn’t a splash of waterfall in the vicinity.

We're a small team: 3 devs, a BA, a PM, and a tester. We have an enviable collection of whiteboards and wall space. Everything we’re doing is represented on a wall or a board. The PM is open and creates some awesome burn charts. The BA is ex-techy and writes exceptional stories. The customer is relaxed and good fun. We just write tests, write code and crack silly techy jokes.

It’s clear to me that there is something special about this team. We have only been together a few weeks, and already we’re already working very well together. Some teams I have been apart of, never achieved this level of cooperation and collaboration, even after months together.

The key element within this team is flow. The flow of requirements through development into test is smooth and quicker than expected. The flow of verbal communication is instantaneous and creates an informative environment. The flow of good humour keeps us all amused. All of this creates a well functioning team but the real key is the true flow that emanates from each individual. Each member of the team is truly enjoying their work. Everyone is contributing, and every contribution is highly valued. This creates an exceptional flow of positive energy that propagates continuously. This energy motivates us to go faster, and to reach for that almost impossible end date. Well, that and the promise of “all you can drink” beer when we make over to the finish line :-)

🐌 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...