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.