Information Radiators: Is low tech really better?

We currenty use a wall, covered with brown envelopes, for story and task tracking. It has its advantages but prople, particularly people not based in this office, often ask for something else.  Chris Sims at InfoQ has a useful summary of the pros and cons of high-tech and low-tech “information radiators” InfoQ: Information Radiators: Is …

Continue reading ‘Information Radiators: Is low tech really better?’ »

YAGNI: Some thoughts

YAGNI – it’s a neat term for a valuable technique. Ignoring an unknown future to concentrate on a known present. That does not mean that it’s application is obvious, though. I often find myself in “discussions” with architects and designers who recoil at the idea of building something specific to one customer or situation, when …

Continue reading ‘YAGNI: Some thoughts’ »

Has Scott Ambler lost the plot on measuring agile performance?

I know this article was written back in October, but I can’t believe that nobody has pointed out its flaws. No Scott, measuring “acceleration” is not the same as measuring delivery of value! IBM developerWorks : Blogs : Agility@Scale: Strategies for Scaling Agile Software Development Scott Ambler, an author who I generally have a lot …

Continue reading ‘Has Scott Ambler lost the plot on measuring agile performance?’ »

Agile Risk Management

There are lots of approaches to estimation for agile projects, but not all of them include estimation of risk. Some approaches deliberately ignore risk, preferring to work from hindsight and averages. For the others, a consideration of levels of risk for each estimated story or task seems a good idea. InfoQ: Agile Risk Management.

Embrace Uncertainty

In the current economic and work climate, it sometimes seems as if uncertainty is “flavour of the month”. In reality it’s been there all along, particularly in the field of software where the whole point is that choosing software over hardware is supposed to make change easier. Jeff Patton has put together a presentation about …

Continue reading ‘Embrace Uncertainty’ »

Pair programming is just like flying a plane

Flying is scary enough even without software development analogies! However, there is something to be learned about the practice of pair programming from studying problems with two-pilot aircraft – especially the kinds of problems which led to crashes. Sarah Taraporewalla’s Technical Ramblings » Pair programming is just like flying a plane.

Agile: When is a story done?

Anyone who has worked with me in the past will probably recognize my standard response to vague or unclear requirements – “how will I know when I’m done?”. I use it so much becuase the simple trick of changing viewpoint to view work in terms of acceptance criteria is key to enabling sensible discussion, estimation, …

Continue reading ‘Agile: When is a story done?’ »

A structured way to work with user stories

For someone steeped in the traditional idea of requirements and features, working with agile user stories is often hard to handle. I have invested a lot of time over recent months attempting to build a good understanding of what a user story is, and how it differs from a feature, a change or a requirement. …

Continue reading ‘A structured way to work with user stories’ »

High-energy stand-up meetings

For a variety of reasons, this morning’s stand-up meeting was a bit of a lifeless affair. I can recall times in the (relatively recent) past when such meetings were an invigorating start to the day. Sarah Taraporewalla has some suggestions for adding a bit of energy to morning stand-up meetings. Sarah Taraporewalla’s Technical Ramblings » …

Continue reading ‘High-energy stand-up meetings’ »

Managing large stories on agile projects, our approach

In theory, an agile story is a simple and obvious thing with many purposes. A description of some desired usage; a token for discussion; a prompt for acceptance tests; a grain around which to gather more detail. In practice, a story can sometimes be more like a traditional feature requirement, or more like a delivery …

Continue reading ‘Managing large stories on agile projects, our approach’ »

The Correct Ratio of Agile Testers to Developers? It Depends.

A hot topic in software development circles at the moment is the interaction and demarcation between “developers” and “testers”. Development uses an agile approach but it’s sometimes hard to see how this sits with the testing folks, particularly as most stories seem to move snappily through development then pile up in testing. Sometimes it seems …

Continue reading ‘The Correct Ratio of Agile Testers to Developers? It Depends.’ »

“Correct” Requirements

I have been working in an “agile” manner for years but I’m still surprised by how much education is needed, and this is especially apparent in the area of requirements. Matthew from Creative Chaos has a rant on this subject: Creative Chaos: “Correct” Requirements To his list I would add “requirements never conflict”. This is …

Continue reading ‘“Correct” Requirements’ »

Smart = Agile++ ?

Despite some concerns for the direction of the term, I consider myself an “agile” software developer. Recently Ivar Jacobson presented a conference session during which he discussed the idea of “smart” as some sort of successor to agile. Smart = Agile++ by Ivar Jacobson From the above summary there seem to have been some good …

Continue reading ‘Smart = Agile++ ?’ »

Agile process drowns in meetings: kickoffs and walk throughs

I have noticed this phenomenon during our “planning poker” estimation meetings, and to some extent in retrospectives and other meetings about iterations, planning and progress. Each time a meeting is held, the number of attendees increases slightly, and the meeting (sometimes imperceptibly, but the cumulative effect is there) slows down. This slowdown leads to a …

Continue reading ‘Agile process drowns in meetings: kickoffs and walk throughs’ »