Here are the various elements of the Tribes-Squads-Chapter Matrix delivery model for Agile Delivery. This model can be adapted to most Agile models for software delivery and has been extensively used in both the lean methodologies of Scrum and Kanban.
The Building Blocks
|
The Building Blocks Of Tribes-Squad-Chapter Matrix Model |
Program: A Program is a collection of Tribes / Squads organized around the same purpose. The Program enables and supports a collection of tribes in achieving their goals.
PMO & Agile Coach: The PMO & Agile Coach team facilitates the feature planning, estimation, tracking, dependencies, risk/issues, and reporting of the delivery progress.
Tribe: A Tribe is a collection of squads with a Tribe Leader, organized around the same business goal. They work on the product backlog.
Squad or Scrum Teams: A Squad is a high-performing delivery team consisting of a set of people who provide executive power. They work on the sprint backlog.
Chapter or Capability: A Chapter is the ‘hierarchical’ line to Squad members, in which personal development and craftsmanship are organized. They are formal “communities” of people with the same job role/expertise deciding on how things need to be done (often within a Platform), regarding their area of expertise.
Guild or Cohort: This is an informal organization that represents a group of people that come together for a specific purpose or shared interest. They can be from different chapters, different squads, or even from different tribes. They open channels for adopting new innovations, building new capabilities, sharing knowledge, exploring tools, etc...
Shared Services: Specialists assigned from their respective areas from other parts of the business or external vendor that provides support to accelerate squads' development progress. You can read ore about it in another blog on Shared Factory Services.
DevSecOps Toolchain: This is a set of technical practices. It provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a system. You can read more about it in another blog on DevOps In A 21st Century Enterprise IT Estate.
Defining Various Roles We Need In This Model
Program Management: Represents the internal voice of the customer and works with customers and Product Owners to understand and communicate their needs, define system features, and participate in validating results. They are responsible for the program backlog and overall governance.
Solution Architect: These are typically natural leaders that have extensive technical experience across platforms, systems, and modules. And even though cross-functional sub-teams often rely on solution architects to get direction in complex integration scenarios, the teams themselves still retain the responsibility of moving all their user stories and tasks forward.
Release Train Engineer: A servant leader and the chief Scrum Master for the train. The RTE facilitates optimizing the flow of value by ensuring the ART events and artifacts function correctly, including the Program Kanban, Inspect & Adapt (I&A) workshop, ART Sync, and PI Planning.
Business Process Owner: A small group of stakeholders who have the business and technical responsibility for fitness for use, governance, and return on investment (ROI) for a Solution developed by an ART. They are primary stakeholders in the ART and actively participate in ART events.
Product Owners: Is content authority for the team backlog and responsible for defining stories and prioritizing the backlog. Product owners are typically key business leaders who can make critical decisions about the need and importance of features within a particular release. They also help with the prioritization of user stories.
Scrum Master: A servant leader and Agile team coach that helps the team to remove impediments, facilitates team events, and fosters an environment for high-performing teams. They ensure the use of Agile practices within teams. They are the Project Managers.
Agile or Scrum Team: They are cross-functional groups of individuals who can define, build, test, and deploy an increment of value. The same team works on requirement gathering, configuration, development, documentation, training, testing, etc. We typically build several such cross-functional sub-teams, each focused on a small number of features. The main objective is to build teams that are as self-sufficient as possible and that rarely need to step outside of their own team to accomplish a task.
----..oo0OXO0oo..----
No comments:
Post a Comment