Agile Roles and Responsibilities
Photo by MAGIS 2011
I feel like I keep witnessing conversations related to Agile roles and responsibilities, and I can't help but wonder where these conversations come from. Each time the conversation takes place, a lot of job titles are thrown around, and it sounds like each one needs to be represented on the development team. A tech lead to do X, developers to do Y, a QA lead to do Z, testers to do W, 3 different UX people to do P-Q-R, and a business analyst to do S. It's as if each role is assigned to a widget rather than a person because the expectation of each role is to take certain inputs, do some work, and produce certain outputs--stay within the boundaries of your role, and you'll be fine.
Teams become bloated with the large number of people assigned to them because these teams are assembled like machines that need a given set of people-widgets in order to deliver working software, and large teams are less effective. It reminds me of a team building exercise my fraternity chapter did during a retreat where we divided into groups, and each group was responsible for acting out a machine; each person had to make some kind movement and a noise or sound effect as part of the machine. It's a fun exercise, but teams are not like machines because people are not fungible parts.
The truth is that individuals need one-on-one coaching on how to contribute to teams instead of a blanket prescription on how to do their job on the team. Different people have different strengths, even when they do similar kinds of work, and that's good because teams have different needs. It is important that the team share a compelling work goal, and its members are mutually accountable for achieving the goal so team members will be motivated to work together. More and more, HR is being affected by Agile software development, and HR is becoming more agile as a result.
