Successful agile teams are cross-functional and self-organized. In this blog, I will focus on how to form and sustain cross-functional teams. There are two requirements for a team to be cross-functional:
- Different functions or skills need to work together effectively, i.e., people with different skills — feature analysis, software architecture and design, code development, testing, technical writing, user experience design — all need to work together effectively.
- The team needs to have all skills needed to produce working software at the end of each sprint.
For an agile team to be effective, team members need to jell together as a cohesive unit. This requires that the same team members work together over a sequence of sprints at least for a release cycle. Ideally, team members should be dedicated to a single team and not be assigned to multiple teams or projects. This encourages their full commitment to the success of one team or one project without being pulled in different directions competing for their attention, and without wasting their productivity caused by dreadful context switches. For example, an agile team may have a software architect, two software developers, two testers, one user experience person, one technical writer, and of course, a ScrumMaster and a product owner for all sprints of a release cycle. However, this ideal team composition remains an unfulfilled dream for teams in many organizations.
Here is a typical scenario that is quite common in my experience. An agile team has:
- One software architect in a “consulting role” serving in the same role on three other projects at the same time. As a consultant, he only does “high-level” architecture and design work on paper, and explains it to software developers on the team who are responsible for implementation.
- Two software developers: Developer 1 is a Java programmer and is dedicated full-time to the team, and Developer 2 who is a database expert programmer is assigned to work on two projects concurrently, as her expertise is in demand on both projects, and no one else is available with that expertise the current time.
- Three testers each assigned 1/3 of time on the team, and each working on three projects concurrently. Each has special expertise that others do not have. For example, tester 1 is an expert in acceptance test automation, tester 2 is an expert in load and performance testing, and tester 3 is an expert in usability testing. Each tester’s expertise is narrow and deep, and each tester tests little outside his/her expertise. Testers with special expertise get assigned to multiple concurrent projects because only they can do the job in their area of expertise.
- A technical writer on the team who is also doing similar work on four projects concurrently. Everyone laments at the critical shortage of technical writers. She always complains about being called late in a sprint cycle and never finding enough time to do all her work in a sprint. She needs at least one more sprints to complete all the work – do screen captures, write on-line help, get it tested by testers, and fix any issues reported. As a result, her work lags behind that of the rest of the team by at least one sprint timebox.
In this example, the team apparently has (at least on paper) all the skills needed to deliver working software at the end of each sprint. However, as the team has experienced quite often, its members are multiplexing on multiple projects. As one project starts falling behind, members of that project are called and expected to put extra time and effort on that late project, which now starts having a snowball effect on other projects that they are working on concurrently. So those other projects (which were running on schedule so far) start experiencing delays as the multiplexed members cannot spend necessary time to do the work.
The Master-of-One-Jack-of-Two skill profile requires each member to be an expert in at least one area or skill (Master of One area) and to have working knowledge to get work done in two other areas or skills (Jack of Two areas). For example, for the team described above, it could and should attempt to have:
- One software architect in the primary role of architecture and design which is his area of mastery, but he also enthusiastically roles up his sleeves to do software code development. He has preserved at least “Jack-level” working knowledge in code development. Coding is not below his dignity although his business card proudly displays “Software Architect” or “Enterprise Architect” or some such inflated title. He continues to believe in the Agile Manifesto principle of “Working software is the primary measure of progress”.
- Two software developers: Developer 1 has Java programming as his primary expertise (Master of One area) and is dedicated full-time to the team; he also has working-level knowledge of database programming and can do usability testing (Jack of Two areas). Developer 2 is a database expert programmer (Master of One area) and is assigned to work on two projects concurrently, as her expertise is in demand on both projects. She is a “Jack” in automated acceptance testing area.
- Two testers: Tester 1 is an expert in automated acceptance testing (Master of One area) and has working knowledge of load testing and automated regression testing (Jack of Two areas). Tester2 is an expert in usability testing (Master of One area) and has working knowledge of performance testing and automated acceptance testing (Jack of Two areas). Both testers are dedicated to the team for all sprints in a release cycle.
- A technical writer on the team who is doing similar work on three projects. She is supplemented with technical writing help by all other team members (a pleasant surprise for her). Other members give her at least an outline of on-line help related to all features. She needs to add some details, appropriate screenshots, and fix any issues in on-line help found by testers. She is not as overloaded and stretched and stressed out as she used to be earlier. From time to time she does some amount of usability testing (Jack in that area). She is also brought into a sprint cycle fairly early.
With the new skill profile (Master-of-One-Jack-of-Two) of its team members, the team experiences major improvements in its ability to deliver a larger number of working features by end of each sprint. First, the degree of multiplexing on multiple projects has reduced (although may not completely eliminated as some people may still be multiplexing). The cross-functional expertise has gone up as each member has working knowledge besides his/her primary expertise, i.e., he/she is Master of one and Jack of one or two other areas. Note that I am not calling for “Jack of All and Master of None” skill profile as it will not work well. The Agile Manifesto explicitly emphasizes “Give continuous attention to technical excellence”, which is what masters in different areas are expected to do. At the same time, Masters can also help Jacks to improve their proficiency in Master’s area of expertise; at the very least, Jacks can get a good deal of work done (although not at the Master-level productivity) so the team can make timely progress on working software (many working features) by end of each sprint. Also Jacks will experience their proficiency and productivity going up sprint by sprint in their secondary areas of expertise. Such a team has less dependence on masters in different areas who are often in short supply, become bottlenecks, and have reduced commitments to any team as they end up getting multiplexed on multiple teams.
The Master-of One-Jack-of-None skill profile discourages cross-functional team formation. The masters invariably get assigned to a number of multiplexed projects, as only they can do the job in their area of mastery; there are no Jacks available to do the work. So masters tend to become ever so narrower-and-deeper experts, and get multiplexed on more and more projects. There is an unhealthy positive feedback loop that plays out between the Master-of-One-Jack-of-None skill profile and Rampant multiplexing of members across multiple projects. These two factors reinforce each other in an unhealthy way at the expense of cross-functional team behavior which is essential for agile teams to succeed.
I see the following root causes for the unhealthy and mutually reinforcing factors of “Master-of-One-Jack-of-None” and “Rampant Multiplexing”:
- Departmental silos organized by narrow functional areas, such as Java Development Group, Load/Performance Testing Group, User Experience Group, Database Programming Group, Technical Writing Group. These silos often fiercely defend their own territories, and discourage (at least do nothing to encourage) its members from acquiring Jack-level expertise in other areas.
- Most members view and associate themselves only with their primary area of expertise. They want to be expert in a narrow area, and may not want to devote time and effort to learn any other areas. They want to be and often incentivized to become Master of only one area, and Jack of none.
- Executives and senior managers may not take explicit steps (such as performance evaluation and salary appraisal) to encourage cross-functional expertise, and nurture the Master-of-One-Jack-of-Two skill profile.
- Project managers want to maximize resource utilization by putting each member on multiple projects (rampant multiplexing) so they are kept busy 100% of their time. Any slack in resource utilization is unthinkable to them.
Agile teams should do retrospectives to find out areas of mastery of individual members, and areas of deficiencies in their skill sets that cause problems in producing working software every sprint. Those are the areas which are good candidates for team members to learn and develop at least Jack-level expertise. If managers focus on maximizing a team’s ability to deliver working software (maximizing the high-value working features delivered) in every sprint instead of obsessing over resource utilization, cross-functional teams will be encouraged, and the Master-of-one-Jack-of-Two skill profile pattern will take hold and will become a cherished norm – a part of organizational DNA.
If you are a member of an agile development team, how is your skill profile? Are you a Master-of-One-Jack-of-Two? What about the skill profile of your agile team members? I would love to hear from you – either here or by e-mail (Satish.Thatte@VersionOne.com) or hit me on twitter (@smthatte).