I just read that my buddy Tim Gifford will be presenting at the next Iowa .NET User Group meeting on December 6th. His presentation will be over Agile Project experiences, and the way he plans to present it sounds pretty cool.

Check out his post for details and, if you’re in the Des Moines are, hopefully you can make it.

A comic about Scrum? What a great idea! It combines the humor of all the wrong ways Scrum is used with the insightful commentary and explanation by the author on why the concept satired by the comic is wrong, and how to do it right.

For those of you unfamiliar with Scrum, you may not immediately respect the irony that the two main characters are a Chickin and a Pig. Maybe this will help.

Regardless, this web site is for Agilist/Scrum folks the way the Daily WTF is for IT people in general.

I recently started a new project, developing a fairly simple data-driven web application. The project itself consisted of a handful of Use Cases, a couple web forms and a domain model containing less than a dozen domain concepts.

While it was my first time working with version 2.0 of ASP.NET, I was also trying out two new metrics, which a friend suggested: A Burndown Chart and a Velocity Chart. I’d also chosen 1-week iterations to give me the best feedback on my progress, as my initial estimate put the project at 6-8 weeks.

For my first iteration, I selected a small, core piece of functionality to implement. I knew in the back of my mind that I’d be writing some architectural-centric code for my different tiers, as well as setting up my web project and database permissions.

TMI? Keep reading – I do have a point coming up.

So how did I perform? Well, I was able to set up my web project; my database users and roles were created; and I had a good portion of my UI and business tier implemented. But, according to my metrics, I had done absolutely nothing. Why is that? First, I was only measuring the points of my chosen Use Cases. Second, I can only account for points if I have 100% completed the feature, period. No if’s, and’s or but’s.

So, how do I account for all of the work I’ve done so that my business users and management don’t think I’ve done nothing the whole iteration? I asked my friend, who suggested I implement a zeroeth iteration. That’s right – Iteration 0.

Once I stopped laughing, realizing that he was totally serious, I considered it and figured that it made a lot of sense. The first iteration of a project is partly a “Setup” iteration. While I’m not implementing anything of value for the business, I am working on tasks necessary to complete future iterations.

So, if you’re starting out a project and trying an iterative approach, keep in mind the mighty Iteration Zero. It could save your life, or at least some explanation time to your boss and/or business users.

From the title, it would sound like this post would represent a complete counterpoint to the basis of this blog. But I assure you, this is not the case.

Instead, I want to point your attention to an article from Siddharta Govindaraj. The article talks about five common issues that new adopters of agile may face when transitioning to an agile process, and what to do to avoid these dangers, including the need to actually understand agile before using it.

Agile and Iterative Development, by Craig Larman, is a book I recommend to managers, project leaders, and software developers who want to know more about agile. The book is clear and concise in its descriptions and provides many useful tips along the way to understanding agile.

A retrospective is the process of looking back on a previous activity to analyze and learn from it, so as to improve upon it the next time around.

This is not specifically an agile idea, but it is a great item to append at the tail end of an iteration to provide valuable feedback for the next iteration.

Once again, an agile practice stems from a common-sense idea that people just don’t think of.

I got an e-mail from a co-worker at work today with a link to an article by Martin Fowler. It’s a pretty interesting topic, though nothing earth-shattering.

As are a lot of agile ideas, this one discusses yet another common-sense topic about the relationship between developers and the business. Because business clients don’t always know what they want, and probably don’t know what is possible technologically to streamline their process, it’s important that developers take an active interest in the business process and domain that they are developing for.

Take a look at the article. It provides a lot of good points.