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.
4 comments:
This is interesting. It makes me wonder Agile might look like if applied to CS research teams. It might be the wrong fit for some areas (like theory) but if you're doing systems research following an agile model might make it easier to get stuff done. Of course the ideas of stories and use cases would have to be changed to make sense in a research context but it would still be an interesting project.
I imagine applying *any* software engineering methodologies to research teams would be good, but I do think agile would work really well in a lot of cases! I'm hoping to have a chance to try it out (maybe even for myself). Have to read up on it more first, though.
I'd be interesting in joining you in that experiment. I'm going to be doing a significant amount of actual development in the foreseeable future and might be able to rope in some fellow PhD students. let me know if you're interested in doing something together.
Probably not quite yet (I have a lot of up front work to do before I get to my big development project), but keep me posted!
Post a Comment
Comments are moderated - please be patient while I approve yours.
Note: Only a member of this blog may post a comment.