{"id":3016,"date":"2022-11-21T17:35:43","date_gmt":"2022-11-21T17:35:43","guid":{"rendered":"https:\/\/www.smharter.com\/blog\/?p=3016"},"modified":"2023-03-19T13:50:42","modified_gmt":"2023-03-19T13:50:42","slug":"transcending-agile-cross-team-collaboration-with-shared-work","status":"publish","type":"post","link":"https:\/\/www.smharter.com\/blog\/2022\/11\/21\/transcending-agile-cross-team-collaboration-with-shared-work\/","title":{"rendered":"Transcending Agile cross-team collaboration with Shared work (3-part)"},"content":{"rendered":"\n
\"\"<\/figure><\/div>\n\n\n\n
PART ONE<\/strong><\/pre>\n\n\n\n
<\/p>\n\n\n\n
See also the previous post describing how to make Agile cross-team collaboration frictionless and enjoyable or in one word effective: Agile Cross-Team Collaboration How-Tos<\/a>.<\/p>\n\n\n\n
Acknowledgements<\/strong><\/h1>\n\n\n\n
My gratitude goes to Bas Vodde (co-author of Scaling Lean & Agile Development<\/em> and Practices for Scaling Lean & Agile Development<\/em>, and co-creator of LeSS<\/em>) for engaging in a long and detailed conversation on this topic.<\/p>\n\n\n\n
What is Shared work<\/strong><\/h1>\n\n\n\n
Before Agile went mainstream and the focus on Agile technical practices declined, shared work was widespread and very successful. It was adopted commonly by Agile practitioners where the work involved multiple teams.<\/p>\n\n\n\n
Chet Hendrickson (co-author of Extreme Programming Installed) points out that:<\/p>\n\n\n\n
Since Agile is simple, a scaled version of Agile should also be that simple, or even simpler. Otherwise, it will no longer be Agile <\/em>~ Excerpt from The Nature of Software Development, by Ron Jeffries, 2015<\/p>\n\n\n\n
The shared work approach, up until now, seems to be the best incarnation of Chet  Hendrickson’s statement. What shared work is then?<\/p>\n\n\n\n

Shared work can be summed up in two points:<\/span><\/p>\n\n\n\n
1) Limiting the number of cross-team dependencies by having each team work across all components and disciplines (analysis, programming, testing, …) Therefore each team has all the necessary knowledge and skills to complete an end-to-end customer-centric feature.<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
2) Transcending any remaining cross-team dependencies by adopting a shared product code ownership where all the teams can work on any part of the product codebase.<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
Knowledge silos Vs. generalising specialists<\/strong><\/h4>\n\n\n\n
On the opposite side of the shared work spectrum, many organisations end up with knowledge silos. They are created, for example, when an individual or a team picks up a novel problem\/task, and afterwards all the other similar problems\/tasks get assigned to them because they already know how to handle that work. Managers may let this happen because they believe in the efficiencies of specialisation, and a team may let this happen because individual team members may enjoy the feeling of becoming indispensable while others may enjoy remaining inside their comfort zone. <\/p>\n\n\n\n
Each knowledge silo tho’ comes with hidden costs such as the creation of a single point of failure and tight constraints on workload distribution and more in general on work prioritisation and planning. To the point that some organisations end up with more managers handling the constraints than those doing the work. In other organisations, the work becomes blocked or delayed most of the time, and people end up multitasking to the point of minimising their productivity.<\/p>\n\n\n\n
Since the beginning, Agile has embodied a major departure from this way of thinking about specialisation. It introduced the concept of generalising specialists, also known as T-shaped professionals that add to the depth of their specialisation the breadth of generalist knowledge in areas mostly adjacent to their specialisation.
The Extreme in Extreme Programming (XP) is meant as pushing the boundaries of one practice to the extreme, to find where it stops being effective, discovering most of the time that is far beyond where we thought it would be. Pushing the generalising specialists to the extreme showed that, in combination with Pairing and Mobbing AKA Ensemble, teams and team members can acquire more knowledge, become proficient in a broader set of skills, and be effective in many more areas far beyond where we would normally have believed.<\/p>\n\n\n\n
With shared work, learning happens whenever the knowledge or skills needed to complete an end-to-end customer-centric feature are missing, the level of generalisation is lacking, or one specialisation is missing. Learning happens by pairing or mobbing with teammates, doing the work with other teams, or hiring a new team member. The specialists in the team are encouraged to pair and mentor instead of working in isolation. Teams are encouraged to seek opportunities to work together. Most professionals, after having tried this form of continuous social learning-by-doing on-the-job, its effectiveness and its value, usually don’t want to go back.<\/p>\n\n\n\n
Teams participating in Shared work<\/strong><\/h4>\n\n\n\n
In conclusion, teams adopting shared work, in addition to being capable of completing an end-to-end customer-centric feature autonomously, usually are:<\/p>\n\n\n\n