Agile Dysfunction Series Part 2: Sticking to Your Role

By · January 21, 2013 · Filed in Agile Scrum Coaching

A basic tenet of forming an Agile team is that it should be comprised of a variety of individuals representing a variety of skill sets.  The term we use is cross-functional.  It is expected that one or more team members will possess skills to elicit and explore the nuances of a User Story when it is under development – Business Analysis skills if you will. The ability to “look deeper” and engage the Product Owner, business users and subject matter experts is crucial to unearthing the elements that will meet user expectations.  Very likely these discoveries will have to be documented – perhaps as decision logs, functional requirements, support documentation or user documentation.

Likewise, there should be team members who understand what is required to ensure the quality of what is being developed.  This extends beyond simple construction and execution of Test Cases.  It is supplying the things that will support the team in producing a potentially shippable product at the end of each iteration.  Beyond functional testing this set of actions could include exploratory testing, usability testing, static code analysis even indicative performance testing – all done to ensure that the team is building the right thing in the right way.

Of course the team will need developers.  Those individuals who actually construct the software with care and precision, ensuring that developed code meets the emerging requirements and passes the necessary tests. As with the other skills, these team members may consider themselves “craftspeople” – producing the highest quality solutions that are high performing and easily maintained.

When the team is high functioning it will exhibit an attitude resembling the three musketeers – “All for one and one for all!”

It’s Not My Job

Sadly, many teams do not achieve this level of performance.  They likely benefit greatly by working closely together – ideally being co-located.  Misunderstandings are resolved quickly. Unknowns are explored and the information passed along without delay or formality. Ambiguities are not allowed to persist. The team operates much better through collaboration and interaction, rather than using lengthy documents or formal reviews to exchange ideas and information.  However, if the team has not yet begun “swarming” it is operating sub-optimally.

Though teams soon see the enormous benefits of working closely together, it is many times difficult for them  to break out of a narrow focus on their own roles. For example, those with development skills see themselves as the coders.  They may not see the need to attend the requirements clarification session being conducted with subject matter experts.  “That’s a requirements meeting – the BA’s will do that and tell us what to build” is a common refrain of those who see themselves as professional developers.  In a similar manner, team members with quality assurance skills often ask “What will I do while the requirements are being firmed up?” or “How will I do my job before the coding is complete?”.  The questions indicate that the team members are continuing to think in a role-based manner.  Optimally, we want the team to think in a skill-based manner.  Team members will recognize that while they are best suited to certain tasks it does not preclude them from tackling a wider variety of tasks in order to work as a team and get the total amount of work completed.

Musketeer Attitude

In his excellent book on Essential Scrum, Kenneth Rubin describes what he calls T-shaped skills. “T-shaped skills mean that a team member has deep skills in their preferred functional area, discipline, or specialty. For example, Sue is a great user-experience (UX) designer—that is her specialty and where she prefers to do work. Sue, however, can also work outside of her core specialty area, doing some testing and some documentation. She isn’t as good a tester or documenter as those who specialize in those areas, but she can help out with testing or documentation if that’s where the team is experiencing a bottleneck and needs to swarm people to get the job done. In this respect, Sue has broad skills that allow her to work outside her core area.

This skill set profile also helps to shape people’s thinking.  The important thing is not to achieve personal optimization but rather to see  the team is successful.  We are after high-performing teams not necessarily high-performing individuals.  The goal is to deliver a potentially shippable product increment at the end of each iteration.  This is usually best accomplished when team members “swarm” to problem areas to see that they are addressed and overall progress is continued.

As Rubin goes on to say, “Managers should focus on forming teams that have the best set of T-shaped skills that are possible with available personnel. However, it might not be possible to get exactly the desired team skill set from the get-go, so the desired skill set could evolve over time as the needs of the product development effort evolve. Therefore, it is critical to have an environment where people are constantly learning and adding to their skill sets, whether those include domain knowledge, technical knowledge, thinking skills, or other capabilities. Management needs to support team members with time to learn and experiment.”

Focus on the Right Things

When team members focus on their own personal productivity the team can descend into a mini-waterfall approach.  This is certainly sub-optimal.  The desire is to have teams focused on the true goal – delivering product that meets or exceeds user expectations.  This is best accomplished when all members of the team are able to step in to get the job done, rather than take comfort that they performed their role sufficiently and that any shortfall is “not their fault”.  As expected, this can represent a huge shift in thinking for many people and  organizations.  In particular, management may need to reconsider how individuals are assessed for their performance reviews.  Many times it has been wishful thinking that by making each individual an expert and rewarding high performance in their narrow skill area then the final product would emerge in a timely, cost-effective manner to meet all the users’ expectations. An Agile approach is to focus on results.

To those who may be interested in further discussion on this may I suggest reading The Goal by Dr. Eliyahu M. Goldratt.  It is an excellent treatise on the Theory of Constraints which supports the efficacy of swarming behaviour for problems and bottlenecks.

Rod Bray
Partner – Web Financial Solutions
(v) 519 636-1558
Creating high performance software delivery teams

Web Financial Solutions provides expert Software Development Life Cycle process improvement.

The services we offer include:

For more information about our services you can fill out our online contact form and someone will follow up with you shortly. You can also call John 416-505-4756