Frank Carver’s Punch Barrel

I’d not seen this before, but it certainly has echoes of real life.

The Parable of the Two Programmers

Agile processes are an obvious choice for development work within a business, but have traditionally not sat well when dealing with customers and contracts who like to specify detail, delivery and price before work starts. Negotiators and lawyers have no obvious answers to hand and, rather than take the risky route of creating a new agile contract, usually fall back to the apparent safety net of an implicit waterfall process.

If there were some example “agile” business contracts available, some of the risk for the contract negotiators might be removed.

InfoQ: Working Group Formed to Produce Reusable Agile Contracts

Team composition and team dynamics are fascinating me right now. We are trying to grow an effective development team, and encourage a process where both the team as a whole and the individuals are doing their best for the company, the product, the customers and them selves. Linda Rising has some thoughts about some of the things that can perturb this effort.

InfoQ: Interview: Linda Rising: Prejudices Can Alter Team Work

Looking at the the way collaborative, creative, teams work in fields other than software development can be very useful. There’s an argument that creating a software release is a lot like creating a music album, for example. Chris Johnston has followed this train of thought and asks if we need an analogue to the “producer”.

Chris Johnston » Who plays the role of technial producer on Agile teams?

I started to idly watch this video presentation, but quickly found that it describes a situation eerily close to our own, so I have decided to set some time aside to watch it in proper detail. I hope it pays off!

InfoQ: Planning with a Large Distributed Team

A lot of writings about agile processes seem to assume that everyone comes with all the skills they need, but in the real world people sometimes need to gain new skills which cannot easily be learned “on the job”. Planning ahead enough to ensure team skills are available when needed, and dealing with the impact on development speed of people spending time on training or independent study rather than productive work seem like tricky problems.

Jooli Atkins has written a bit on this topic for the British Computer Society (BCS) Agile Training : Blogs : BCS

I’d be really interested to hear from anyone how they deal with this!

This is a really interesting idea. Games to help learn agile practices and get used to agile ways of working. I wonder if I can find an excuse to play any of these for work …

InfoQ: Agile Games for Learning

Pair programming can be one of the hardest things to get right when attempting Extreme Programming (XP). It’s very common to give it a try and quickly find a whole bunch of problems. Mark Needham has written a thoughtful article full of tips on making pairing work. Well wortha read even if you don’t do it (much) yourself.

Pair Programming: Pair Flow at Mark Needham

We don’t use scrum as such, but we still face the issue of team-member absence during fixed iterations. It’s a tricky one to deal with, especially as absence comes in both predictable and unpredictable forms.

InfoQ has a nice summary of some of these issues and some solutions. There is till no “silver bullet” for this, though. Losing staff will almost always mean losing productivity, which in turn means that iteration (”sprint”) commitments will need to be renegotiated, which works best if stakeholders are informed as soon as possible.

InfoQ: Handling Absence in Scrum Teams

As we attempt to spread agile, continual, iterative, processes throughout the company, there is a growing confusion as to when things are actually ready for release. The old “waterfall” notion of a complex and detailed advance specification, backed up by months of laborious manual testing is no longer applicable.

In most ways this is a very good thing. A whole lot of unnecessary rigidity and busy-work has been removed. However, one aspect we miss is some sort of final “quality gate” to approve a release. We are in danger of ending up either with a queue of potential releases jostling for testing priority, with none of them ever actually being released before they are overtaken by a new candidate, or with untested and potentially broken builds being released to live deployments.

This is obviously also on other people’s minds, too. InfoQ has recently published an article on “The Power of Done” which summarises some attempts to chart an agile course through this dangerous situation.

InfoQ: The Power of Done

The self-organizing, collective responsibility aspect of agile teams is sometimes hard for a hierarchical organization to get to grips with. Sriram Narayan notes a great response to the common question “who do you report to?”

XPloring around: Who do you report to?

Sarah Taraporewalla has written a nice short post which summarizes her thoughts on Agile. And in general I agree with her.

Sarah Taraporewalla’s Technical Ramblings » What is Agile?

We had a small discussion at work a few days ago about the difference between Scrum and Extreme Programming (XP).

My take on the distinction is that Scrum is essentially a management technique, while XP is essentially a development technique. They certainly have a lot of overlap, but the different emphasis leads to some different recommendations. There’s no “40 hour week” in Scrum, for example.

Jason Yip contends that Scrum stops where actual development work starts.

For interest, a while ago I reviewed both the original book on Scrum and a clutch of XP books for the Java Ranch “bunkhouse”.

Another post that resonates with our current working situation.There have been several attempts to make use of offshore software development in our company, and we are involved in one right now. The contrast between our “on-shore” agile, iterative, TDD, frequent check-in process and the approach used by our off-shore partners is very sharp.

InfoQ: Agile and Offshore: Asking for Trouble?