I recently enjoyed reading In Good Company. The book is addressed to a general business audience, but I found it very relevant to agile software development (particularly agile’s emphasis on people and their interactions). I recommend it to anyone interested in that side of agile. From the back of the book: “In Good Company is… Read More

I’ve just watched this on YouTube. For those who don’t know, James Bach specializes in testing, but most of what he says is applicable to agile in general. He covers the “people over tools” point very well. As I’ve written before, the importance of people over tools is incredibly important, but seems to have been… Read More

Something’s bugging me.  I think we’ve lost sight of our priorities in the agile software movement.  We are spending too much time talking about processes and tools, and too little time talking about people and their interactions. Think back to the Agile Manifesto.  At the moment, we seem to have:… Read More

I presented a session at today’s Wellington Agile BarCamp.  The session was called “Crystal Clear: Big Lessons from a Little Process“.  Instead of describing all the details of the process, I outlined four of the most important lessons I have learned from it. Here are some brief notes on the presentation.… Read More

I’m debating an issue with Steve McConnell, over on his blog, and I’d like to hear what others think of the issue. I have a theory that, when multiple suppliers are competing for the same contracts, market forces encourage selection of those suppliers who have under estimated (either knowingly or unknowingly).  It’s some kind of… Read More

Regular feedback is a key element of agile development.  Rapid feedback improves our software.  I suggest it also improves us, the people who write the software. I’ve just read a fascinating article on where talent comes from, over on Freakonomics.com.  It outlines research into the key factors that develop talent.  The key factors are: “setting… Read More

Steve Yegge points out that it’s very hard to do a valid scientific experiment in software development: “You can’t have the same team do the same project twice; a bunch of stuff changes the second time around. You can’t have 2 teams do the same project; it’s too hard to control all the variables, and… Read More

Many agile proponents advocate the “Cancel-After-Any-Phase” approach. Work is prioritised by business value and the customer can halt the project after any phase.  You can fix price or scope, but not both.  Most commonly, the price is fixed and scope is cut if necessary. This approach is a natural fit for most agile processes.  However,… Read More

While scope creep is doing more work than you expected, due to added scope; effort creep is doing more work without added scope.  You’re just taking longer to do the same stuff. Like scope creep, effort creep is inevitable and manageable.  To manage effort creep we need to understand what causes it.  Three major causes… Read More

Principled Negotiation also applies to defining your software development process.  You can’t choose Agile just because you like it.  You have to understand what your customers’ interests are, and you have to seek a process which meets their interests and yours. For instance: if the customer says they want a detailed Gantt chart, that’s a… Read More