20 min
The Journey To CROSS FUNCTIONAL Development Teams Healthy Software Developer
-
- Technology
Are you looking for a way to get people with different disciplines to work together better when developing software? Today I'd like to talk about the journey to cross functional development teams and some of the considerations on your way to integration.
What Is Cross-Functional Teamwork? Cross-functional teamwork is simply taking people who used to be in separate teams or departments and putting them on the same team. To get there people go through a series of phases or stages.
Phase 1: Ad-Hoc The first phase is what I call “ad-hoc”. Someone at the company has done some work that would typically be thought of as associated with a discipline (Operations, QA, Support, UX as examples), but they don’t think about how all the things associated with that discipline should be handled.
Phase 2: As-A-Service The second phase is “as a service”, or what most people in medium to large companies often experience. This is where there is a dedicated department that does Support, Operations, UX, or QA; as examples. When a product team needs help with one of the skills of these separate teams, they use their expertise as a service. But these teams are still independently managed and measured.
Phase 3: Embedded The third phase is “embedded”, and what most people think of when they hear terms like DevOps, Embedded QA, or Embedded UX as examples.
Folks who were on a separate team are now integrated with the product team itself. They are dedicated to using their skills to achieve a single outcome for the business such as a product or deliverable.
Embedding Sometimes Uses An Office / Center Of Excellence During the embedding phase, it’s common to see companies create a center of excellence, or office, who’s purpose it is to help make sure good practices are followed by those embedded in the teams. A “Project Management Office” is a common example of these. An important consideration is, does the person leading this new office have the skill with coaching, documentation, patience, and establishing measurable outcomes necessary?
Leading Center Of Excellence Requires Additional Skills Also during the embedding phase, it’s important that all of the people working together on a cross functional team now share in the risks and rewards. If we’re going to expect people to work together towards a shared outcome, and not look out only for themselves and do work in silos, we need to spread the results of everyone’s actions across the team members.
Phase 4: Infused / Integrated The final phase of cross-functional development teams is when the skills that used to be primarily sought by a dedicated member of the team around a discipline (again, Operations, QA, UX, Support as examples) are disseminated across team members. This is hugely beneficial since multiple team members can now provide help with more than one discipline, and it avoids bottlenecks due to individuals who are thought of as “the person” for a particular skill being unavailable.
You can also watch this episode on YouTube.
Related resources:
Continuous Delivery - Are You Missing The Big Picture?
Visit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
Are you looking for a way to get people with different disciplines to work together better when developing software? Today I'd like to talk about the journey to cross functional development teams and some of the considerations on your way to integration.
What Is Cross-Functional Teamwork? Cross-functional teamwork is simply taking people who used to be in separate teams or departments and putting them on the same team. To get there people go through a series of phases or stages.
Phase 1: Ad-Hoc The first phase is what I call “ad-hoc”. Someone at the company has done some work that would typically be thought of as associated with a discipline (Operations, QA, Support, UX as examples), but they don’t think about how all the things associated with that discipline should be handled.
Phase 2: As-A-Service The second phase is “as a service”, or what most people in medium to large companies often experience. This is where there is a dedicated department that does Support, Operations, UX, or QA; as examples. When a product team needs help with one of the skills of these separate teams, they use their expertise as a service. But these teams are still independently managed and measured.
Phase 3: Embedded The third phase is “embedded”, and what most people think of when they hear terms like DevOps, Embedded QA, or Embedded UX as examples.
Folks who were on a separate team are now integrated with the product team itself. They are dedicated to using their skills to achieve a single outcome for the business such as a product or deliverable.
Embedding Sometimes Uses An Office / Center Of Excellence During the embedding phase, it’s common to see companies create a center of excellence, or office, who’s purpose it is to help make sure good practices are followed by those embedded in the teams. A “Project Management Office” is a common example of these. An important consideration is, does the person leading this new office have the skill with coaching, documentation, patience, and establishing measurable outcomes necessary?
Leading Center Of Excellence Requires Additional Skills Also during the embedding phase, it’s important that all of the people working together on a cross functional team now share in the risks and rewards. If we’re going to expect people to work together towards a shared outcome, and not look out only for themselves and do work in silos, we need to spread the results of everyone’s actions across the team members.
Phase 4: Infused / Integrated The final phase of cross-functional development teams is when the skills that used to be primarily sought by a dedicated member of the team around a discipline (again, Operations, QA, UX, Support as examples) are disseminated across team members. This is hugely beneficial since multiple team members can now provide help with more than one discipline, and it avoids bottlenecks due to individuals who are thought of as “the person” for a particular skill being unavailable.
You can also watch this episode on YouTube.
Related resources:
Continuous Delivery - Are You Missing The Big Picture?
Visit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
20 min