Raising the Urgency Level

I just started using Agile methods in my job of running a software development team. We started our first sprint (iteration) Monday. We are not "both feet in" and only a few days have elapsed, but I already see a difference in the team's sense of urgency and energy level. We are using Rally, an Agile project management tool, to help us run the project. Our first iteration size is 2 weeks. The team was already a reasonably high-productivity team since, in general, everyone on the team is committed to getting things done the right way. What was missing was a little more structure and focus.

We met Monday morning to agree on the list of Stories (collections of tasks) for the iteration and make general estimates of the size of each. By the end of the day most team members had broken down the stories into multiple tasks with concrete estimates in hours for each one. Rally rolls up all hours estimated in tasks into the Story level and provides various views including full iteration and team member allocation. We met the next morning to make any adjustments, agree that the amount of work to accomplish in the 2 weeks seems to fit and clarify any other concepts that were fuzzy.

The team is new to Agile thinking for the most part. As manager of the team I mostly cover the role of ScrumMaster (to use a Scrum term). Scrum is a specific methodology of Agile. When I say that we are not "all in" I mean that we do not do everything recommended in the Agile literature. For example, we use email for daily status instead of daily face-to-face standups. This was a practice already in place when I arrived on the scene late last year. It seems to work well, and we have tweaked it a bit and critiqued it recently to try to make it better.

I subscribe to the method of gradually going Agile. I believe that if you have a team that is already flexible and productive, moving to Agile is a natural evolution. Not being burdened with a heavy Waterfall culture is a real benefit. A small-company environment where there is already fundamental trust and a little bit of development anarchy is much more of a blank slate in which to imprint a particular process, and Agile methods are a natural step.

There is a lot of information that preaches that Agile will fail unless undertaken under the watchful care of expert consultants and training programs. A lot of this information is produced by companies who make their living creating Agile development tools. I am not heeding that advice, and instead trusting that I know what I am doing from reading and leveraging over 25 years of experience developing and managing software teams in a variety of business circumstances and processes.

I may continue to post as the experience unfolds to record the pros, cons and results of this experiment.