In previous blogs, Dennis van der Salm, senior Pega-architect at BPM Company, looked at different programming styles such as pair-programming and mob programming and at role-based versus skill-based working. In this blog, he looks at the shift from specialist staff to the T-shaped professional and what the benefits are.
At the beginning of my career, I worked in a team where we had a pretty straightforward way of working. I wrote about that in an earlier blog. Product owners wrote user stories, the business analyst examined the details and inventoried the needs and requirements. The user story was then handed over to the rest of the team to gather detailed information. After this fine-tuning, a developer started working on the user story. Once the developer was done, a senior developer from the team did a review of the code. Finally, it was handed over to the tester to see if the solution worked as expected before it was finally put into the production environment by people from management and maintenance. Everyone had their own specialized, defined role. A tester had to test and not develop, and a product owner had to stay away from testing above all else. Only the business analyst had slightly more of a helicopter view of the whole domain in which a team worked.
The move towards T-shaped professionals
In recent years, we have seen a shift towards more T-shaped professionals. T-shaped professionals have a wide range of skills and knowledge, having one specific area of expertise (the vertical bar of the T), but also having a broader set of skills and knowledge (the horizontal bar of the T). Instead of just being a developer, you need to have certain basic knowledge of the role of the business analyst, of the tester, of the product owner. Knowing something about everything creates a better understanding across the team of what one’s own role contributes to the bigger picture. This enables the team to work efficiently in complex, multidisciplinary environments and solve problems that span multiple domains. Unlike specialists, who have in-depth knowledge on one specific topic, T-shaped professionals can switch more easily between different areas of expertise and to work with people with different backgrounds and skills. This leads to more efficient and effective collaboration.
Higher quality solutions
One problem with specialized roles is that when someone is absent, the whole process stalls. For example, developers don’t know what to do because the product owner and business analyst haven’t created enough user stories. By working with T-shaped roles, you avoid this. The DevOps movement in recent years has further encouraged this. My current team includes developers who are also knowledgeable in market research, data analysis, business analysis, testing and maintenance. The improvement is huge and the solutions had a much higher quality.
The benefits of low-code
By working with low-code tools like Pega, developers need to write less code. As a result, they have more time for other activities. Try experimenting with one or two developers on your team. Let them do market research or user interviews, so they can take over tasks from others on the team.
Do you also feel that cross-departmental processes could be more efficient and better, and would you like a quick initial insight into the possibilities? Feel free to contact us!