Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News T-shaped Hybrids in the Multi-disciplinary Team

T-shaped Hybrids in the Multi-disciplinary Team

This item in japanese

Franco Martinig, editor of Methods & Tools software development magazine, Scrum co-creator Ken Schwaber and other commentators have recently written and presented on the value of the multi-faceted developer, also known as the T-shaped specialist.  This commentary is not isolated and illustrates how the multi-faceted specialist is increasingly recognised as a critical component of any empowered team.

Martinig recently wrote about what he calls “Renaissance-style Software Development.”   He writes about the benefits of the cross-functional “T-shaped” developer, able to wear multiple hats and contribute to analysis, testing and customer interaction.

Schwaber has also blogged a recent piece in which he states that the collective experience and periphery skills of each team member can play a critical role in the problem solving process:

Every person on the team has skills and experience that they contribute, turning the requirements into the best possible increment possible for them. One never knows when an insight, a memory, a skill rarely used will come into play. That is the beauty of Scrum teams, the growing synergy of the unanticipated.

John San Giovani, the founder of Zumobi, recently presented a TED talk, entitled “The Artist-Geek Hybrid.”  He tells us how Zumobi seeks to recruit individuals with a broader range of experiences and “bring the right brain to the party.”  He describes how unique solutions can arise from the “wildcards” which lay at the intersection between an individual's differing interests and experiences.  Technology artist and head of ThoughtWorks’ Hardware Hack Lab, Andrew McWIlliams, reports on this presentation and adds that there is also value in the super-set of a team's wildcards:

There isn't just value in the wildcards that come from the intersection between disciplines. There is also power in multiple perspectives, and multiple approaches.

Simply placing a cross-functional group together is not always sufficient stimulus for bringing out the inner-T. Both Martinig and Schwaber discuss how, within traditional organisation structures, job-titles can create absolute boundaries of responsibility. Martinig explains that labels such as “programmers, software testers, DBA and business analyst” can result in inhibiting individuals from collaborating outside the sphere of their domain. Martinig writes:

Large software development organizations have often chosen to have a tayloristic approach where people are separated according to their expertise: programmers, software testers, DBA, business analysts. This separation in silos had also an implied “hierarchy” in the mind of developers.

Becoming a participating T-shaped team member is a conscious step. Augusto Evangelisti, principle agile test engineer at Paddy Power PLC, has blogged a primer for T-shaping any tester into an all-rounder able to contribute to the development and analytical strengths of a team. He writes an account targeted at the tester, reluctant to step outside of his role. He suggests using downtime to actively collaborate with BA's and developers, by proactively learning and offering help.

In an interview with GitHub's Tim Berglund's about his QCon keynote “First Kill All The Product Owners,” he describes his belief that the product-owner role should be shared across a strong cross-functional team. Berglund describes a scenario where “all of the people responsible for building a thing, (are) being all of the people responsible for defining the product.” He explains that empowering teams through the entire life-cycle of their product, encourages them to become passionate about the domain and take greater ownership of their products.

Evangelisti sums up the benefits of becoming T-shaped:

So stop being a boring I-shaped specialist that is going to be out of a job soon and become a T shaped Agile Tester (or team member), you will be more valuable to the team, more employable and best of all never stuck on your own testing (activities) like crazy because your colleagues don’t know how to help you! Welcome to the world of cross functional agile teams where there are no roles but activities!

Rate this Article