Sometimes, agile development teams must face challenges that require more flexibility and shorter response times than what experts recommend. At the same time, they don’t have all the tools, information and resources they need to get the job done. I believe that in such extreme scenarios, when all odds are against the team, there is a type of team that is more likely to succeed: a team built according to a new T-shaped skills paradigm.
What does ‘T-shaped skills’ mean?
A while ago, I learned about the concept of T-shaped skills as one of the desired development team characteristics; I originally found this concept in the book Essential Scrum by Kenneth Rubin.
In brief: a person with T-shaped skills has the ability to do different jobs but has ‘deep knowledge’ of only a few of them. This is the graphical representation of the concept:
This description applies, for instance, to developers that also know about testing and graphic design. Their deep knowledge is about development but, if needed, they can help the team doing some wireframes or testing. A team comprised of members with this kind of skills is more flexible when facing a bottleneck. When certain team members are too busy, another member with broad knowledge of the tasks they are carrying out can share the load.
Limitations of this Approach
It seems to me that the scope of abilities in the ‘broad’ axis of the ‘T’ is generally understood as limited to the execution of specific tasks of other members of the development team.
The new T
In a way, I was acquainted with the notion of T-shaped skills even before I had read Essential Scrum. The concept is one of those ideas that, when you read about them, you immediately think “I’ve been doing this for years!”, but once you manage to visualize them applied to a theoretical framework, you can use them as useful tools, their effective range is expanded and you think about these concepts in a very different way.
So now, when I recall the way the development teams I was part of dealt with extreme situations, I notice that the key factors that led to success fall somewhat outside the scope of the concepts outlined by Rubin but they could fit there, which is the point of this post.
Individuals and Interactions
In addition to your abilities with some programming language or your capacity to test new features, you need to know and understand the context in which the development team is immersed.
The Agile Manifesto stresses the human aspect over the task-oriented aspect in its first value sentence:
‘Individuals and interactions over processes and tools’
In Peopleware by Tom DeMarco and Tim Lister, the impact of the human aspect on the success of projects is discussed:
“The cause of failure most frequently cited by our survey participants was ‘politics.’ […] Included under ‘politics’ are such unrelated or loosely related things as communication problems, staffing problems, disenchantment with the boss or with the client, lack of motivation, and high turnover. People often use the word politics to describe any aspect of the work that is people-related […]: They constitute the project’s sociology”.
Understanding the organization and its different areas (and even each individual) is a tool to better deal with common goals and interactions. A project with a very tight schedule and poorly defined user stories needs more than the ability to carry out several tasks simultaneously.
The new ‘broad’ axis I propose also covers the ability to understand the needs of other teams, to enable those teams to work better together.
This new approach can enable development teams to boost the efficiency of other teams and simplify the interaction between different areas.
Many examples come to mind: support teams deal with scenarios that are hard to plan in advance, and have to answer according to SLAs policies; so the development team could help greatly by just writing better logs. Professional services teams would benefit enormously from better installation practices or better deployment documentation. The more aligned with product managers or product owners team members are, the less detailed functional specifications needs to be. Development teams can also help sales teams to ensure their sales pitch matches product technical specifications.
It should be noted that not all members of a team should have the same abilities; some could be more dedicated to ‘doing’ and others to ‘understanding’. I believe that expanding the ‘broad’ axis to include the ability to understand outside the needs can make a team more robust, adaptable, and fun to work with.
References
- “T-Shaped Skills And Swarming Make For Flexible Scrum And Agile Teams“. 2017. Scrumexpert.Com. http://www.scrumexpert.com/knowledge/t-shaped-skills-and-swarming-make-for-flexible-scrum-and-agile-teams/.
- “Manifesto For Agile Software Development“. 2017. Agilemanifesto.Org. http://agilemanifesto.org/.
- “Essential Scrum: A Practical Guide to the Most Popular Agile Process” – Kenneth S Rubin, Addison-Wesley, 2012.
- “Peopleware: Productive Projects and Teams (3rd Edition)” – Tom DeMarco and Timothy Lister, , Addison-Wesley, 2013.
