Embedded Files
Each change drawn from a Transformation Backlog should be applied to a narrowly targeted part of the organization. A good agile pattern or practice can support many change items in the backlog, and each change item can implement several good patterns and practices. Furthermore, the same pattern or practice may be applied, at different times, to different organizational areas. For example, the orchestration of releases might be coached to certain groups prior to others. By limiting the scope of change, regardless of how many good practices are being leveraged, to carefully selected organizational elements we can transform the enterprise in a managed and controlled fashion.
It is important to think of these organizational elements as “Delivery Teams”. Each part of an organization that is undergoing agile transition should make a contribution to the delivery of value in some way. As such, Delivery Teams might exist at operational, project, program, or portfolio levels. In fact any stakeholder who is responsible for planning or facilitating the delivery of a product or service should be regarded as a member of a Delivery Team. These teams can include people we might typically think of as “managers” as well as analysts, developers and engineers. We therefore need to include those with strategic management responsibilities – such as deciding what projects or programs to deliver – as well as teams with entirely technical remits.
How do we transform a “change target” into an actual Delivery Team, which can become self-managing? The answer lies in the establishment of cadence and the empirical adoption of changes that appeal to good agile patterns and practices. It is cadence that allows stakeholders to systemically participate in agile improvement. By improving their delivery of value to a regular beat, and by successfully applying the associated patterns of change, stakeholders become first-class citizens in their own agile transformation. Once cadence is established, we can then begin to refer to these participants, seriously and credibly, as “Delivery Teams”.
In an agile way of working, Delivery Teams are encouraged to be self-organizing, and so their membership may initially be fluid before they stabilize. Each team should be able to complete its work in a timely fashion, and to a known and acceptable level of quality. This implies incorporating the required skills and resources into the team.
Examples of agile Delivery Teams include:
Scrum Teams, often with a focus on project work
Kanban Teams, often with a focus on “business as usual” work
Scrumban Teams, exhibiting hybrid Scrum-Kanban characteristics
DevOps Teams, with responsibilities that span product development and operational support
Note: Delivery Teams should be co-located in order to maximize collaborative efficiency. This does not preclude the use of offshore team members, as long as each Delivery Team is co-located either wholly onshore or wholly offshore. Each product or service may therefore be developed by one or more Delivery Teams in different locations. A complex product or service ought to be represented by a team of experts who can assist Delivery Teams in creating integrated increments of release quality. They effectively provide assurance for the integrated product. This Product Assurance Team should include the Product Owner, subject matter experts, and those who represent organizational engineering standards such as architects. A schematic of an example onshore-offshore team structure is available here (PDF).
Synonyms: Development Teams, DevOps Teams
Page updated
Google Sites
Report abuse