Go Lean, Go Agile: Are We There Yet? (GHC12)

The concept of agile development has always fascinated me, particularly because I haven't had the opportunity yet to work on an agile team. (This despite having done five 4-month co-op terms during my undergrad.)  So, the panel presentation on lean and agile development at GHC12 was definitely on my list.

The panellists included Mario Moreira (an Agile and Configuration Management industry expert), Rae Wang (Senior Program Manager at Microsoft currently working in Exchange Online), Jill Wetzler (lead software developer and scrum master at salesforce.com), and Janet Swedal (Senior Director in the Technology organization for Thomson Reuters).  Their experience and insight was amazing.

The big theme for the talk was the challenges of adopting agile in your team.  Sometimes teams really have no choice but to go agile given the frequency of releases to customers and opportunities for feedback.  But it's not easy to implement the change; it requires an all-in buy-in from team members to the executives, for example.

The speakers explained some of the benefits of going agile: agile development encourages incremental / iterative development, adaptive planning, rapid and flexible response to change, etc… The collaboration and communication the methodology encourages is seen by some as the number one benefit.  In fact, research has shown that the communication differences between men and women all but disappear in agile teams.

An interesting issue brought up through audience questioning was that of technical debt. How do you ensure that bugs are fixed and code gets refactored when needed?  The speakers suggest taking a methodological approach: have a refactoring strategy at the beginning of a project, and turn this work into a technical story.  Refactoring and bug fixing can also be part of the 'done' criteria of a particular story.  You can also take an entire sprint to work on bugs, or rotate resources to fix bugs.  You have to make it a priority before you end up with a mountain of debt.

I know a few people who have worked on agile teams.  I found this presentation very interesting because I could see why some of the problems they were complaining about might be showing up.  For instance, one team didn't appear to be taking technical debt seriously enough.  I also wondered if all the teams I know about were actually well suited to being agile (another common thread of discussion in the presentation).  It seems that the way they divide work might be contributing to lower quality output for the sake of being agile, and it's not clear whether they work in a particularly iterative way.

But all this is mostly speculation, since I am not entirely familiar with the methodology yet.  When I get a chance, I look forward to reading up more on agile, and potentially trying to use it in my own thesis work as well as any team projects I am involved with in the future.