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]

One of the first thing I did this morning was to make sure I had registered for the 2008 edition of the Pdc.

Any brits travelling to LA or any alt.net guys want to organize an unconf, let me know.

Now they need to open the registration for TechEd Europe and I'll be booked for the year.

I'm publishing this a bit late, but I took a few days (a whole two of them) without working. How refreshing!

In an effort for a more transparent process, here are a few things I think went well and didn't go too well. If you've been at the talk I would absolutely love your criticism. Practice makes perfection, but before that it makes for nicer presentations and a less worried Sebastien!

Preparation god damn it!

The font-sizes were all wrong in everything but the code-editor, this is quite unacceptable and certainly not like me at all. So be prepared if you install vs 2008 SP1 beta, it will reset all your settings. That explains the lack of proper configuration in visual studio. And of course, a problem never comes alone, vs refuses to start under my Presentation account that is set with ridiculously large DPI setting. But it all comes down to me installing this stuff too late, which left me no time to make sure everything was configured properly. Apologies to the audience, I should have had a VM up-and-ready with all my content. And apologies to myself for installing a beta service pack on my main development machines.

Tools

All the usual presentation tools were not installed on that laptop either, so no ZoomIt and no Keyboard Jedi. Again, with a reinstall of vista a couple of days before, I just didn't have the time to get it right.

One thing I find difficult is choosing a screen mode. When showing code, I want to show you my Visual studio and whatever other programs get spawned by it (ie, firefox, the command prompt) while still seeing them on my screen. For powerpoint, I want to keep presenter-specific stuff from your eyes (a timer, some notes, and in general the whole content of the slide you'll see appearing as I talk).

I need a hybrid between Clone and Span modes. I may have something working, so my next talk will guinea-pig the idea. I'll blog about it after trying it out. :)

Not having slides...

Some people didn't completely see how the asp.net MVC and the REST part of the talk connected together, and maybe I should've introduced that at the beginning on the slides. But if you know me, I don't like slides and will avoid them at all costs.

This is the first talk I give where I put some content on slides, to refresh everyone on MVP and MVC and how the models differ. I like how visual it makes the explanation, but I'd rather manage to do it graphics only, with no text whatsoever. That requires more work, a tiny bit of animation and very good graphics. Nothing that can't be done with enough time for pimping it up.

Body language

I used the MacBook remote to change slides, and the freedom to move around to move slides is next to none. I also find that having the remote to hold from the tips of my fingers helps me avoid leaving my hands hanging. Hold something to keep your hands at chest level, it puts your body language into explanation mode. Relax and put one hand in your pocket and you switch to opinion mode.

Eye contact is the best tool to calm anxiety. You'll always find a couple of people in the audience being very expressive, that lets you judge the rhythm of the presentation. There's nothing worse than an expression-less audience.

Messy content

I'm a bit in-between two waters on this one. The whole point of the talk was to see what toolkits you can use today to do REST applications, but, for various reasons, I fit in there an introduction to asp.net MVC as a first part. That just doesn't flow well, and I think I'll split those two in two different presentations: asp.net MVC introduction (I have some AJAX stuff to make that presentation complete), and REST today, rest tomorrow. They can both stand on their own feet, and it would leave me more time for doing what I prefer doing: talking rather than coding and rushing.

I'm not funny

I tend to make jokes during the talk, they're usually completely spontaneous, but they fall flat every time, except for a few friendly grins from people I've met or talked to before. I shall prepare my jokes in advance and only use them after having tested them. But not on animals.

Speak more slowly

My voice level seems to be alright, but I speak too fast. And I have those pet words that creep in, amongst them "I think" (very annoying one I have a lot of problems getting rid of, even in day-to-day conversation), and Ok (very patronising, hate it, think I managed to mostly kick it off my presentations).

It's quite funny how the brain gives you those little fetish words. I think they creep-in because they trick your brain think there's a rhythm to what you're saying, when simple punctuation and sentences should be enough. It may also be the case that they give your brain enough time to reformulate when you're mid-sentence and unsure about what to say next. Again, preparation is the key.

Have different solutions, not different projects

This one bit me during the presentation. As I prepare the code for all the major steps, I end up with the same project at different stages, and I made the mistake of keeping all the projects in the same solution, often resulting in the wrong code being ran when pressing F5 and the wrong files being shown when I expected to show some code.

From now on, I'll keep all the projects in separate solutions.

Conclusion

I really like giving talks. It is a bit frustrating to come up with new material every time and only use it once, as you don't get the opportunity to retrofit what you learnt from presenting it once. Hopefully that will change as I get new speaking opportunities.