Frank Carver's Punch Barrel

This is an absolutely fascinating article for anyone interested in business process and improvement. Read it and you’ll see what I mean!

Evolving Excellence: JKE Day 2: Saishunkan Cosmetics – Customer Care Trumps a Factory

InfoQ have published an article which offers a compelling argument that common corporate performance reviews are fundamentally broken, and should be abandoned. While I largely agree with this premise, I don’t see a great deal of improvement in the proposed solutions.

Perhaps it reflects differences in the kinds of places we have worked, but for me an effective performance review should concentrate on a holistic view of how the individual has contributed to the success of the organization. I am worried that neither of the two proposals encourages “thinking outside the box” and doing whatever is most effective for the business. Instead, they concentrate on reinforcing existing decisions such as pigeon-holing staff into “team members” and “managers”.

InfoQ: Performance Reviews Banished

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

We have some pretty lively iteration retrospectives as part of our process, but so far they have almost exclusively focussed on the issues affecting the process. Sarah Taraporewalla wonders if such discussions should also cover thoughts about the code base and the changes made to it.

Sarah Taraporewalla’s Technical Ramblings » Retrospectives for the code base

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?

A short (and pretty old in internet terms) but solid article which, among other things, contains the key phrase:

The purpose is not to meet…it is to improve.

Learning about Lean

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

Joel Spolsky has written another article for Inc magazine, this time about the way that incentive schemes and commissions always end up backfiring.

Worth a read, and applicable to any process, not just sales. As I pointed out in a recent post, assessing a development team on lines of code, or number of bugs or any other deceptively simple measure fails because of the same problems.

For me, the solution is the same. Give everyone enough information and authority to improve the whole system, not just maximise local perks.

How Hard Could It Be?: Sins of Commissions, Marketing and Advertising Article – Inc. Article

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?

This slightly provocative post examines the role of QA (a.k.a testing) in various view of a project lifecycle and considers how we might react to a QA team which reported no bugs.

Ryan Greenhall: What is The Role of QA?

Steve Freeman has put together one of the most thought-provoking software development articles I have read in a long time – based on application of ideas from a New Scientist article.

Husbanding willpower | Steve Freeman

It must be that end-to-end software production process is on my mind. I keep spotting interesting articles about the topic. Here’s one from Digital Dim Sum which delves into the way that requirements find their way into development, contrasting a “push” of requirements with a “pull” of information..

Don’t push requirements – pull information | Digital Dim Sum

My favourite process at the moment is a more “pull”-centred process than many I have seen. Anyone is free to write and contribute “user stories” at any time. From time to time ones which seem valuable are pulled into a “planning poker” game for estimation. Before each iteration of work, a mixed group of stakeholders gets together to pull a fixed amount of development effort from the pool of available estimated stories into the next iteration schedule. Developers then pull stories from those scheduled for the iteration, work on them and place them in a pool of implemented stories. When the integration test team are ready, they pull a build containing stories implemented so far and test it. Meanwhile the customer deployment team may pull and deploy any tested build at any time.

As an abstract process this seems streamlined but there may, of course, be practical issues.

A slightly lightweight article, but the idea is sound. To really make software development processes which work, we need to recognize and pick apart failures as well as celebrate successes. It can be politically tough, though, to stand up and admit failure without trying to spin the blame.

InfoQ: Failures in Agile Develoment

Following a mildly rambling discussion this morning, I was intrigued to see the following article which talks about the problems of losing impetus for change after a few bad practices are removed and a few benefits are seen.

How far should we be pushing for real end-to-end agility?

The Agile Manager: Agile Made Us Better, but We Signed Up for Great

As an agile practitioner and consultant I have been participating in daily stand-up meetings for years now, with generally good results. Occasionally such meetings hit some speed-bumps (for example, one problem seems to be that the group of participants can become a bit too large, but splitting the group does not seem useful either). Such meetings are obviously personal and vary between teams and situations, but it was good to read an article (and comments) about effective stand-up meetings.

InfoQ: What Makes a Good Stand Up Meeting?

Jez Humble from Thoughtworks writes about the problems of deployment and the advantages of automating the process. Oh, and he also pushes their new deployment automation product

Deployment Pipelines: Revolutionizing Release Management