A friend of mine is part of a business that wants to use Agile and he was asking me how to introduce agile to a team that has never used it before.

Even before asking, he’s already well on his way because his team wants to drive it as a business process not just for development (win #1), has a committed product owner (win #2) and likes the Agile Manifesto (win #3).

My advice surprised him because it was pretty simple and did not include ANY REQUIRED MEETINGS.  Here’s what I suggested:

1. Have the product owner create a 1 page advertisement for the product that you are working on.
2. Create a prioritized feature list (1 to N, no ties) that covers immediate and longer term items.
3. Meet (ok, that’s a meeting) regularly to argue about the priority list as a team. I omitted that these would be sprints or iteration – the team will figure that out itself.

That’s it.  I also strongly recommend including retrospectives but I always recommend retros and he knows that part of the team building subterfuge that is Agile.

His primary question after this was how to schedule and estimate work.  My suggestion was to use a date driven release plan because it’s easiest to estimate billing if you use a calendar – cost = time * rate.   To make that work, you must give frequent demos to the customer so they are on board with the deliverables.    That’s the “easy” way.

If you want to predict when features will complete then use “story point” estimates.  Basically, each feature is estimated on an exponential scale (1,2, 4, 8, etc).  Big scary features will get big scary estimates.  When you are closer to starting, then you can decompose the big scary estimate into smaller units.  Ideally, you can decouple the work so that parts of the larger feature get done earlier and proven in the market.  It all ties back into your ranked list.

Splitting large features into smaller component may create a very useful interweaving where high value parts of features get done quickly where “bonus” components never get done.  Of course, this will drive engineers crazy because the don’t get to add those extras that create bloatware.

Overall, the goal of Agile is to create product the sells.  Now, that’s not too hard to understand is it?