Agile Adoption (the story so far)

We have been introducing Agile development techniques to our development group over teh last few months. This includes product management, business analysts, QA, and development members.

Adoption I believe has been slow but successful. The main reason for this has been that our existing waterfall-like process really wasn't that bad. We had over the years come up with good documentation that were an appropriate level of process and documentation to be meaningful. I think there is some don't-rock-the-boat mindset, but even those people have been more engaged in this than I would have ever imagined.

So if our process "worked", why even look at agile?

We needed to investigate agile because we needed to be agile. Being a hosted web application, we have chosen the model that we release "small and often". While the level of specification has always been good, our lack of software team management often meant that deadlines were missed or project size mis-estimated. We are looking to add SCRUM techniques and iterations (with deliverables at the end of each iteration) to serve as milestones along the way. We need the agility to deliver larger projects in iterations. We need agility to help us to be able to quickly deliver code if needed. We need to be able to iteratively deliver features, so that we can respond as a team better to changing priorities. Agile will give us that. We have been able to implement a few mid-sized features this way, and it has been successful.

So what have we done so far?

For a given feature, we enlist a feature team that includes product management, development, QA, DBAs who a business analyst "pitches" the feature to. We're assuming that at this point it has been determined that there is a business need for this feature. The feature team meets and fleshes out user stories. These stories are weighed as far as relative complexity, and are broken down into sub-stories until they represent some reasonable set of scope. From the stories, developers create tasks which are grandular enough to put meaningful estimates on.

User stories are also categorized on a MoSCoW scale, meaning Must/Should/Could/Won't. I.e. relative priority. We want to make sure we get all of our "musts" done for a release.

We haven't really calculated developer velocity yet on an individual basis. We are using generic "half day of effort" to be a story point. We hold developer stand up meetings daily, where we should be tracking progress in terms of completed story points which can be tracked on a burndown chart. We haven't implemented this yet.

We have looked at developing personas and are interested in this as a group. We just have not made the time yet to develop meaningful ones. Again, this is a mature web product where we are on fist name basis with some of our key clients. One of our product's strengths is our teams' ability to respond to user enhancement requests. Because we are already intimate with several of our customers, we have not dedicated the time to build personas that represent them. I still believe it is worthwhile because it removes some of the personality of the individuals that we know from the roles that individual plays. Personas don't have to be flat and dull, but they should also not instigate any bad feelings or other baggage around interactions with a specific client individual.

I am encouraged.

I think my organization has adopted well the agile principles we've put forward. We are still amatures and feeling our way through the landscape. Also, we've stopped pushing new agile concepts for the time being as we digest the basics and become more familiar and trusting of them.