Agile smell

Anthony talks about a potential agile smell and the concept of self-organizing teams. As with his brother's blog, I still can't figure out how to post a comment so it ends up on my blog. If I was to bother with putting categories on my entries, I'd probably have one specifically for commenting on other posts when I've been too dumb to find the reply or the register button.

Let's first separate Agile (as an enforced, recognized and lucrative book publishing business, as well as quite a bit of ego and a general lack of understanding or intelligence in applying the ideas), agile (as a bunch of methodologies you pick and choose from to try and get as many benefits as you can out from what others have spent years experimenting with, and that we alt.netters would consider the pragmatic choice), post-agile as a poorly worded (imho) variation of pragmatism, and scrum (as one particular self-organizing methodology, one of the most popular but also one of the most badly applied). They each represent different things and different steps you can and should follow in becoming more agile, and everybody should try to get more agile even when not wanting, refusing or considering being past the stage of, Agile.

Back to Anthony's post. He talks about a "conflict" with someone telling him that he should have chosen a story to pick on his own because teams are self-organizing, and Anthony argued that without prioritizations he should ask before committing to the work.

I'm not entirely sure which variance of agile that company is using, but here's what we do here. Stories are written on the wall and are negotiated with the client, and doesn't involve the dev team much at the early stage outside of simple feasibility study (when we're lucky). They get used for us to produce both the scenarios for the tester's acceptance criterias and the product backlog.

The product backlog is the one being prioritised: high-level functionality cards of a couple of days, and the prioritization is done by us from the knowledge we extract painfully from the project managers. Sometimes they even come and do it themselves, but sadly that's as common as a solar eclipse.

From this, we commit at the beginning of the sprint to the amount of work we think we can deliver. After a couple of sprints we know roughly from our estimates how many virtual hours we deliver per sprint, aka how many of the hours we have estimated we manage to deliver. This is usually quite accurate even though the number itself doesn't mean much at all.

The team is self-organizing from that point because the *team* has committed to the *whole* of the sprint backlog. If we had over-committed we would've de-scoped. In that sense, at the stage of a daily stand-up, I'd agree that a team member asking what to do next is usually a practice smell:

• Priorities of tasks mostly don't exist as we're committed to all of them
• The ones that need to be worked on first are based on dependencies rather than priorities. If you ask you probably forgot what depended on what. With short sprints, that's the last thing you would forget when you've spent 3 or 4 hours deciding all of those on the Monday.

We use the wall for roughly clustering tasks that are inter-dependent, and the bottom of the wall for the nice-to-have. When you commit to a task, you commit to the team that you're wishing to do a task, so you probably don't have a reason to ask for permission.

The final thing that I've experimented on my latest project is to decouple the sprint backlog maintenance and the daily stand-up. It's now a real-time wall: you add, remove, complete and reshuffle tasks when you feel like it, the wall is visible and people will see the changes as they happen. The daily is a summary of all those movements: this relieves the pain of updating the wall, makes it more entertaining, and no one asks what to do next because they've either not finished their current task yet or they've already chosen their new one.

Being agile share many of the tenets of alt.net: flexibility, lookout for the best solution, pragmatism. In that respect I'll agree with Anthony that an Agile Anal can be annoying. But on the other hand (and I'll leave that to another post), only the teams that tried and mastered Agile can allow themselves to deviate to agile. If you've not tried hard enough a change in mentality in the way you work, you will fail, and what some would call "adapted agile" I call "bad habits are back".

[Updated: s/Jason/Anthony]