Frank Carver's Punch Barrel

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 low tech really better?.

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 it is “obvious” that a general solution will be better.

Mark Needham has written some of his thoughts on this topic.

YAGNI: Some thoughts at Mark Needham

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 of time for seems to have completely lost it in an article at IBM developerworks. In this article he goes to some lengths to justify measuring teams on “acceleration” (in effect, measuring the proportional increase in story points processed per iteration) and thereby assessing their value. While this may have some merit, the article insists on contrasting it against other methods of attempting to measure actual productivity.

Unfortunately such a comparison does not make sense.

• A high-accelaration team may be worse over time than a low-acceleration team, if their starting productivity is less.
• A high-accelaration team may be worse over time than a low-acceleration team, if their maximum productivity is less.
• Ambler’s analysis assumes that the entire surrounding process is constant, including task estimation. This is very unlikely

Fundamentally Acceleration and speed are quite different things. I can wait at the lights on my pushbike and burn off nearby cars, because of my higher acceleration, but fifty feet later they will overtake me and carry much more stuff a much further distance.

Jason Yip from Thoughtworks has a nice summary of points to remember when organising or managing stand-up meetings.

You’d think with all my video game experience that I’d be more prepared for this: A quick summary of how I like do stand-ups

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.

Coping with difficult times is a topic of the moment. Jared from Agile Artisans writes about optimising a team.

Agile Artisans::home.

An interesting collection of articles. I have read a small number of them, but I’m looking forward to enjoying (or at least complaining about) the rest.

My 10 Favorites Agile Project Management Articles | From the Editor of Methods & Tools.

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 using this uncertainty rather than fearing it.

InfoQ: Presentation: Embrace Uncertainty by Jeff Patton

Agile development, Lego, and video – what a combination! A cute series of short stop-motion videos explaining agile techniques.

Agile Advocate’s videos on Vimeo.

Update: the figures in these videos are, of course PlayMobil, not Lego. That’ll teach me to blog in a hurry

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.

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, planning and development to begin.

Mark Needham has been considering similar issues, but rather than using the technique to clarify requirements so a pice of work can enter the development process, he looks at how to decide when to remove it.

Agile: When is a story done? at Mark Needham

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. Marc McNeill has an interesting article (with slides!) about how he deals with this kind of issue in product workshops.

What is the story? | dancingmango

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 » Improvements to the usual stand up meetings

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 contract. In these cases, estimating, developing, and delivering the story can provoke problems, risk, and conflict.

One such case is when a story is too large for comfortable estimation. Commonly this arises when a story is driven by a desire for a feature or sweeping change – something easy to give a name to, but complex in its detail. We have faced at least one of these most iterations.

Bill de hÓra discusses some approaches to tackling such large stories in a recent blog post:

Bill de hÓra: Managing large stories on agile projects

In our team we typically tackle the problem slightly differently. The items on our progress wall are represented by brown A5 envelopes, each with summary information (title, id, estimate) written in large, friendly letters on the outside, and an accumulation of detail (notes, time spent, diagrams, etc.) inside. To stop the contents falling out, the envelopes are all placed on the wall with the opening on the side.

Why do I mention this? We use a quick of this to deal with large stories. A story too large to estimate and develop on its own is represented by an envelope with the opening at the bottom. This implies that such stories can not accumulate detail of their own, but only reference other stories. We split the large customer story into several internal stories, estimate, annotate an develop them independently, but do not consider the main story complete until all the component stories are also complete. To show the relationship we write the ids of the component stories on the outside of the “vertical” envelope.

This approach seems to work. Stakeholders still have visibility of the status of the large story, and the development team is free to implement the component stories in parallel or in sequence, in whatever order is most effective and efficient.

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 as if a team needs more testers. Sometimes it seems as if a team should reduce or dispense with testers altogether. Sometimes it seems as if roles and responsibilities should change completely.

I wish I knew an answer to this, but at least it is encouraging that others are also considering and writing about these issues.

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

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 a particularly common problem where a time-to-market or delivery deadline requirement conflicts with the choice of features and even with the choice of production process.

This is an interesting idea. It’s common for agile techniques to be defined by their benefits to the business, but there is often a benefit to the development of the individual people involved in the agile process, too.

InfoQ: How Agile Benefits the Individual

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 points – the issue of the education system not actually covering the attitudes and skills necessary for software development, even in supposedly appropriate courses is one I have ranted about many times.

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 perceived idea that if only we had more stakeholders in the room, we could get more answers more quickly, so more people are invited. And so it gets worse.

Chris Johnston » Of kickoffs and walk throughs

Is this a general curse of agile processes, or is it a particular anti-pattern or failure mode which can be avoided?

There are a lot of things to like about the Lean movement and the Toyota production system, but I worry that blanket application of their principles to software development may be misguided. Just as with other metaphors used to build a mental model, the metaphor of software development as a factory has big holes in it.

This becomes particularly apparent when considering the concept of defects. In a factory the job is to produce output in large quantities, all of which is consistent with an initial design. From this premise it is easy to understand that any difference from the initial archetype is a defect, which means that the factory process is not working correctly and needs to be fixed.

In software development, the job is not to produce multiple identical things, but to produce new things which did not exist before. From this premise it follows that there is no definitive archetype against which to measure differences. Sure, producing identical copies of software for sale or distribution is like a factory, but typically that process is almost trivial, requiring not much more than a “copy” command.

When developing software we sometimes find ourselves in the uncomfortable situation of not knowing whether something is a defect or not. All we know is that it is different from some expectation, but any particular difference may be a defect or it may be an improvement.

Testing: What is a defect? at Mark Needham

In an agile process, what is a defect?

Can anyone point me at any resources on Toyota’s approach to product development, rather than the familiar material on their approach to factory production?