Marcato

I’m in the midst of bootstrapping a new Agile team with a client of ours – Kardia Health.  While this is familiar territory and the end game is clear, each time I go through it I am reminded about how monumentally large the small details seem to be.  It’s entirely unlike riding a bike, especially when it involves a new team working on new applications with an entirely new toolset.  It’s more like watching a small child learn how to walk – the brain knows what it wants to do but the body just doesn’t know how to do it yet.

The last few weeks have been frantic with preparation – securing our funding, lining up the team members, working to finalize the services agreement with the offshore provider, trying to get access to our lifecycle management tool of choice (Microsoft’s Team Foundation Server), trying to get a development environment set up so that work can begin soon after the first iteration starts – there seems to be an endless number of things that you want to do before you start so that you can start well.

I’m a big fan of Maslow’s Hierarchy of Needs – situations like this really help to clarify what is most important; there are lots of things that you would like to have in place before you start, but really only a few that MUST be there in order for your iteration to have any semblance to a real Agile iteration.  What are those things?

• At least two other people – a product owner to help you know what is important and another technical team member to teach.
• A duration for your iteration – I’ve already advised that you try two weeks first.
• Stories for your first iteration – some of these can be to establish infrastructure, but make sure the primary effort for the team is to build something of value to the business.
• Story point estimates – the only thing of importance at this stage is to establish a stable estimator; accuracy comes later after two or three sprints.  For now, just focus on getting a consistent team together to do the estimating.  And since most people have difficulty with the idea that these estimates have no standard, feel free to start with the arbitrary standard that a point represents one hour of effort.  With this starting point in mind, we’ve found that powers of 2 (1,2,4,8…128) represent a useful sequence that covers the range.  64 is about the practical high limit, and 128 effectively means “too large to estimate” and needs to be broken down.
• An estimate of capacity for the sprint – again, since you have no real foundation for this, just add up the person-hours available to you – we will have 3 people for 2 weeks, so our initial estimate of velocity for the team will be 240 points.
• A readiness to learn.

Magnolia Gardens and Plantation - Charleston, SC

That should just about do it – the rest is relevant in the long run, but not essential to start.  After all, Agile is about the journey, and as long as you begin by building a culture of learning, then you have the most essential ingredient.  It would be nice to have the stories in a tracking took so that estimation and task breakdown can all be tracked, but there are low budget approaches to these things that work just fine.  It would be great to have a build process linked to a continuous integration tool, but you can get by without that too.  All these things will come in good time, but the most important thing is to just…

…start.