Roles in an Agile Team
I got an email today pointing out an article on Dr. Dobbs that discusses the change in mindset required to be part of an agile team as well as the roles on the team. This got me thinking about the changes I've made in how I think about software in order to become an effective contributor on agile teams. Some of these changes in how I think were hard. Some were simple.
Get Rid of Titles
If there are developers, testers, architects, project managers, deployment engineers, and technical writers in the team room, you will not be as effective as you could be. If in the team room, everyone is a team member, the entire team can benefit from sharing the effort. Don’t accept excuses to avoid work: “But I can’t write tests, I’m a developer.” Of course, everyone comes into the team room with their own area of expertise and experiences, and you can leverage these. Of course, your team still needs to fit into the larger organization, so outside of the team room, you may have to keep the titles, but if your entire team can make this shift in thinking you will be amazed by the results.
Share the Wealth
When you have folks pairing both for development and testing, there will be a lot of knowledge transfer. I started my last big project with very limited testing experience, but I now can work as a competent tester. I never tried to become a test engineer, it just happened over time as I helped the testers with automation, brainstormed test cases, and wrote unit tests. A few of the testers I worked with went from a moderate skill level in coding and design to strong coding skills. It did take a while. It was occasionally frustrating for everyone involved. It required a concerted effort to mentor each other, but the net result was that anyone on the team could code, test, troubleshoot, or fix any part of the system. If there is an area that you are the only expert in, teach at least one other person about the area, so they can be competent and do their job. If you are working with an expert in another area, ask questions. Learn and teach each other.
Commitment to Quality
Everyone on the team needs to feel 100% responsible for the quality of the project. I know this is "typical" hollow advice. A lot of companies and teams say very loudly that they are committed to quality. However, if there was a horrible showstopper bug discovered by a customer on your project two weeks after release, would your immediate reaction be to cover your tail and blame someone else? Would the team focus on dodging blame or fixing the problem? If the immediate answer is not fixing the problem, you may have a challenge on your hands.
If everyone is truly focused on delivering value to the customer, then quality follows.
Roll up your Sleeves
If you see that something needs to get done, do it. If there is a task that no one else wants to do, do it. Lead by example. When the whole team does this, it is amazing how much can get done.
Agree to Disagree
Sometimes, we ran into situations where not everyone was on the same page. At first, we would try to fight things out. Over time, we learned that that got us nowhere fast. Instead, we learned that if we disagreed, sometimes it was best to make a decision and have everyone commit to it, even if they disagreed. While not easy, this proved successful for us. Of course, this requires an atmosphere of trust and respect to work effectively, which does take time to develop.
These attitude adjustments (and others) came about gradually over time. They did not happen overnight. However, as a result of these attitude adjustments, everyone became a better contributor. I was amazed by some of the changes and the results.
Comments
- Anonymous
May 24, 2006
刚才在MSDN Blog上看到一位仁兄Michael Puleio写的关于Agile Development的文章，颇有见地。与MS2的同学“奇文共欣赏，疑义相与析”
在MS2的项目团队里，很多时候大家也是以Agile面貌工作的。令我感触最深的两点是Share... - Anonymous
May 24, 2006
hey, Michael, I guess you don't have any idea of Chinese, hah, feel easy, I just recommended your post to the intern students in MSR Asia - Anonymous
May 30, 2006
The points you've made apply to almost every team I've worked on, Agile or not.
Agreeing to Disagree is a tough topic. Knowing when to stop convincing others that we are right and trust someone else's solution, takes a leap of faith and respect that usually takes much time to earn. Easier said than done, but necessary none-the-less. - Anonymous
June 07, 2006
http://aaronfeng.blogspot.com/2006/06/agile-transition.html - Anonymous
June 13, 2006
The agile team I'm working on has a different approach to knowledge sharing. From one iteration to the next, if there's something you've worked on a lot in one iteration, you're banned from working on it in the next. Obviously, you end up pairing with the person working on that piece in the following iteration, but it really fights the tendency for people to specialize. - Anonymous
June 13, 2006
Jason, that sounds like a pretty good way to ensure that no one gets "siloed" into only working on one part of the system. - Anonymous
February 17, 2008
Favorites Build Providers for Windows Forms Curso del.icio.us-adev Dr. Dobbs Web 2.0 and the Engineering