agile-wanderer
Agile Wanderer
Musings on Agile tech management
Copyright © 2021 All Rights Reserved.
10 posts
Don't wanna be here? Send us removal request.
Last Seen Blogs
sporadicsportscowboygarden
Untitled
melocky
Melocky
anianurst
anianurst
atikahsudi
『OldStoryau』
yeonnung
눙
Text
The Road Manager
Previous: The Chapter
Some projects require tighter cross-team collaboration. Projects that require cross-tribe collaboration are especially painful to manage in environments where autonomy is the norm. For those cases, some level of Agile project management is required beyond what squads and tribes normally do. For this purpose, the Road Manager role was introduced.
The Road Manager is a temporary role that is taken on throughout a project's lifecycle. It is usually a secondary role for an AC (TPM), CL (EM), or senior IC, but it’s not limited to them. Road Managers work closely with the project’s business owner, usually a senior product manager and stakeholders.
An RM’s responsibility includes:
To define the scope of the delivery: Definition of done and description of the problem. Business value it provides and how it’s linked to our vision/goals. Estimated delivery time.
Plan and execute the delivery: Work with teams to break down the work. Coordinate the delivery with the business owner and the stakeholders.
Make the business owner aware: of any problems or blockers, of any changes in scope and progress, and if any help or support is needed.
0 notes
Text
The Chapter
Previous: Tribe Leadership
Up until now, we’ve discussed squads and tribes. Although they have funny names, they are common in most organizations and are usually named "teams" and "groups," respectively. Chapters exist to reduce the costs of trying to maintain squad autonomy through ruthlessly reorganizing. While this instability is good for optimizing your organization to match your mission, it is not so good for people’s individual career growth and happiness. To optimize for career growth and happiness, it is often preferable to maintain a long-term relationship with a manager, preferably one who understands your tech area of expertise (e.g., backend, machine-learning, iOS, etc.). This is difficult to do if squads keep changing and are cross-functional. Squad members would need to continuously change managers as they reorganize. This is both unhealthy for squad members' career growth and also adds friction when reorganizing. This added friction would cause reorgs to happen less often than needed. Additionally, it is unlikely that a squad lead is an expert in every tech area that the squad has. This limits their ability to support everyone in the squad.
Chapters solve both problems by maintaining a long-term relationship with a manager (Chapter Lead) who is an expert in your domain and does not change when you move squads. Chapters have a homogeneous skill set, if possible, and contain between 5 and 15 engineers. So, chapters help improve org flexibility by making it easier to restructure squads. It ensures your manager has the same skill set and gives you access to a group of other engineers in the same domain. It means that the Chapter Lead wears two hats: first as a people manager and second as a member of a squad leadership group. A chapter is like a support group. However, it is not a way to support or own systems, nor is it a place to do product development work.
Next: The Road Manager
This article is part of the Squad Model in Practice series.
0 notes
Text
Squad Model in Practice - Tribe Leadership
Previous: The Tribe
A tribe is a collection of squads with the same domain and a clear overall mission. They provide a complete containment of the reporting structure for all (or most) functions. This means that each function represented in the tribe reports to a leader who's part of tribe leadership.
Tribe leadership is made up of tech, product, and design leads. They are sometimes referred to as the Tribe Trio. They are supported by an Agile Coach Manager who reports to the Tech Tribe Lead. Most everyone in the tribe should report up through tribe leadership. Chapter Leads report to the Tech Tribe Lead, Product Managers report to the Product Tribe Lead, and designers report to the Design Tribe Lead.
Product Tribe Lead (Product Director): Owns the product vision for the tribe. Maintains the product roadmap for the tribe. Ensures the tribe is setting the right priorities and defines the right KPIs. Works with squad Product Managers to break down the vision based on the squads' missions.
Tech Tribe Lead (Engineering Director): Owns the technology and the people. Works with Chapter Leads to make sound technical decisions and ensure that the tribe delivers on its goals. Responsible for maintaining a healthy culture where people are motivated and are working well together.
Design Tribe Lead (Design Director): Owns the design. Ensures that the tribe is making sound design decisions. Works with designers to ensure the tribe delivers a consistent design language across our products.
Agile Coach Manager (TPM Manager): Owns the process. Advises Tribe Trio on how to organize. Works with Agile Coaches to ensure squads are using the best processes to achieve their goals.
Next: The Chapter
This article is part of the Squad Model in Practice series.
0 notes
Text
Squad Model in Practice - The Tribe
Previous: Squad Leadership
When a few squads need to work together on a joint mission, they form a Tribe. Tribes are self-contained. They own a mission and all the people and systems to accomplish it. Tribes usually have between 40 and 80 members.
Squad flexibility is one of the main strengths of the Squad Model. This flexibility allows us to use the organizational structure to avoid complex project management practices. However, figuring out a structure that keeps squads small while ensuring that we stay focused on the most critical business goals requires dedicated attention. This is where tribes come in.
A tribe is a collection of squads with the same domain and a clear overall mission. They provide a complete containment of the reporting structure for all (or most) functions, usually: tech, product, design, and operations. Squads and chapters are fully contained within tribes, meaning that no squad or chapter crosses tribe boundaries.
Providing the tribe with organizational autonomy means that tribe leadership can look at the overall mission and devise the best squad structure required to accomplish it without needing to build consensus through the entire organization.
Next: Tribe Leadership
This article is part of the Squad Model in Practice series.
0 notes
Text
Squad Model in Practice - Squad Leadership
Previous: The Squad
Each squad has a squad leadership group. However, few people on the squad report directly to the people in squad leadership. The goal is to avoid positional leadership that derives from one's formal authority in the organization but instead relies on informational, expert, or connective leadership. The objective of the squad leadership group is to ensure that the squad has all the conditions needed to succeed rather than to direct the squad and tell them what to do. Several roles are represented in squad leadership. They are:
Product Owner (aka Product Manager): Owns the product. Maintains the roadmap and the backlog. Ensures the squad is setting the right priorities and defines the right KPIs.
Chapter Lead (aka Engineering Manager): Owns the technology and the people. Ensures the squad is making sound technical decisions. Ensures people are happy and are working well together.
Agile Coach (aka Technical Project Manager): Owns the process. Ensures the squad is using the right process. Tracks and reports progress. Ensures that the squad is healthy.
Due to the nature of the matrix organization, most of the engineers on the squad may not report to the Chapter Lead (EM). This means that often more than one Chapter Lead will work with a given squad. However, each squad should have one primary Chapter Lead. While other Chapter Leads might phase in and out as needed, the primary Chapter Lead will continue to engage with the squad throughout.
Squad leadership will likely meet once a week, maintain their own backlog of tasks and topics that they want to address, and influence the squad's structure, process, and priorities. They will often represent the squad in tribe-level activities. For example, a Chapter Lead might petition for the needed headcount for the squad and work with recruiters to ensure that the right people join. The Product Owner would negotiate priorities at the tribe level and above when the squad needs to commit to larger projects. The Agile Coach would work with other coaches and tribe leadership when adopting new tribe-wide or company-wide processes and policies.
Next: Squad Lifecycle
This article is part of the Squad Model in Practice series.
0 notes
Text
Squad Model in Practice - The Squad
Previous: Prerequisites
Cross-team dependencies are complex and challenging to manage. Large projects with cross-team dependencies and complex project management processes have high failure rates. The best way to avoid them is by doing work in autonomous teams called “squads.” Squads are the primary building block of the squad model and hence its name.
When approaching a new project, we try to create an organization made up of squads that would optimize autonomy, reduce dependencies, and allow each squad to work as independently as possible. To do that, we need squads that have:
A clear mission: so they are not slowed down by having to continuously validate their decisions. This can be a good starting point for structuring deliverables (e.g., using OKRs).
Cross-functional: so everyone they need to accomplish their mission is in one team.
Small (5-10 people): so that everyone on the team knows what everyone else is doing and they don’t need to use complex project management processes to manage their work.
This is based on the assumption that our organizational culture is mature enough so that a two-pizza team (5-10 people) knows who to work together effectively (see Prerequisites article for more info).
Figuring out the org structure upfront means we need to tackle some hard decisions like architecture and product ownership early on. However, we can often make these over time; as the organization grows, the product matures, and the architecture develops.
Next: Squad Leadership
This article is part of the Squad Model in Practice series.
0 notes
Text
Squad Model in Practice - Prerequisites
Previous: Org Structure
The squad model is built on top of a set of Agile practices and principles. It is challenging to adopt an add-on to Agile if there is resistance to Agile practices and a lack of acceptance of its principles. On the other hand, if your organization already has practices like daily standups, work visualization, WIP limits, sprint planning, and retrospectives, you are on the right track. You don’t have to have all of these, but a good majority will make everything that comes next easier.
The basic assumption of the squad model is that you can take a group of about 10 people and give them a clear mission, and they will be able to self-organize and accomplish their goal. The hidden assumption is that they are all coming into a team with a similar understanding of what being self-organized means. If one person thinks we need a Microsoft Project Gantt chart that goes out 6 months while another person thinks we can just plan one week out with stickies, they will have a tough time working together. They will likely spend less time on accomplishing the mission and more time fighting each other. This means that you have to hire the right people with the right background in Agile, train the organization if needed, and define Agile practices as a significant part of your org culture.
On the tech side, it helps if there’s some level of standardization regarding how code is written and delivered to production. Having a robust CI/CD pipeline that can deliver code to production safely and consistently means squads don’t need to solve this again and again. It is challenging to have a good CI/CD pipeline without high-quality automated testing and high test coverage. Having an easy-to-use and reliable A/B testing framework means that you can deliver code to production while controlling who gets new features and measuring their efficacy. Mandatory code reviews and a strict code style with automated enforcement encourage shared code ownership and make moving between teams easier, which adds fluidity to your org structure.
Next: The Squad
This article is part of the Squad Model in Practice series
0 notes
Text
Squad Model in Practice - Org Overview
Previous: Introduction
The squad model structure has a number of elements with confusing names. Some are more important than others.
Squads are the central unit of the squad model. If you are trying to accomplish something and wonder what organization element you should use, 9 out of 10 times, the answer is “a squad” or “several squads.”
Tribes give squads more structure and help to align squads on a larger mission or domain.
Chapters are less important than squads and tribes. They exist to address a deficiency in the squad/tribe structure by creating a long-lasting relationship with a manager -- a Chapter Lead.
Guilds are also mentioned in various descriptions of the squad model; however, they are a very minor part of the model, and we will be ignoring them for simplicity. They are simply a group of people with a common interest that infrequently meet, like a club. Some examples are Backend Guild, Electronics Guild, or Whisky Guild. The guild is run by a Guild Master, which is a revolving role. Anyone can join any guild.
There are also a number of roles essential to the squad model. Some have similar names to similar roles in other organizational structures, some are new, and some mean slightly different things:
Product Owner (PO), sometimes called Product Manager (PM), owns the product, the mission, and the priorities.
Chapter Lead (CL), sometimes called Engineering Manager (EM), owns the technology and the people.
Agile Coach (AC), sometimes called a Technical Project Manager (TPM), owns the process.
Next: Prerequisites
This article is part of the Squad Model in Practice series
0 notes
Text
Squad Model in Practice - Introduction
The primary motivation behind the squad model is to increase velocity. So why would organizing your company into squads and chapters increase velocity? The reason goes as follows:
The main obstacles to moving fast are not knowing what you need to do next or getting blocked from doing it.
The solution is to give teams a clear mission or goal to achieve with clear KPIs and autonomy to localize decision-making so that they can move forward with little or no dependencies.
Squads are precisely that. They are an autonomous, cross-functional team with a clear mission and everything they need to achieve it.
The main problem with this approach is that clear goals are a moving target, and so are managing dependencies. What you think you know today is likely to change over time, affecting your mission and dependencies.
So it stands to reason that your org structure should stay fluid and change accordingly. Discover a new mission? Create a squad to focus on it. Discover a new dependency? Reorganize to eliminate it.
This is fine for moving fast but creates a few problems. First, if we keep moving people around, they will likely burn out, and secondly, they will have a hard time building their careers if we do not support them.
This is where chapters come in. Chapters are more stable than squads since they are skill-based, not mission-based. They provide employees with the support of a manager (Chapter Lead) with whom they can have a stable relationship while moving from squad to squad.
Next: Org Overview
This article is part of the Squad Model in Practice series
0 notes
Text
How to Run a Kanban Driven Recurring Meeting
You have a recurring weekly or biweekly meeting. It’s not your main team meeting (e.g., sprint planning). Maybe it’s a meeting with your cross-functional peers (e.g., engineering managers, product managers, designers, etc.). Maybe it’s a meeting with your peer management group. Maybe it’s a meeting with your stakeholders. You want the group to generate topics for discussion, prioritize items, create and track action items, and not waste people’s time. You can set up a kanban board that will make this task easier to manage.
Set Up a Kanban Board for the Meeting
You can set up a Kanban board using any number of free or paid services. Some popular options include Trello, Asana, Monday, or even Quip – it really doesn’t matter. The board has two areas: a discussion area and a delivery area.
Discussion Area
The discussion area helps drive the discussion during your meeting. At a minimum, it should have an intake column and a discussion column. The intake column, usually called something like “Inbox,” is where new items get added. The barrier to entry for this column should be very low, and all team members should be encouraged to add items there at any time, both as the meeting starts and between meetings, so nothing gets left behind. Items can include topics to discuss, tasks, or anything else. It is better to add an item and quickly discard it rather than to forget something. The discussion area should also have a “Discussion” column. This is where items to be discussed are moved, prioritized, and discussed one by one. Discussion can be open or more structured and time-boxed, for example, by using Lean Coffee. Additional columns can be added to categorize items for cases where subgroups with different interests share the board or if the flow to prioritize and discuss is more complex.
Delivery Area
The delivery area is where we drive execution for tasks that need to be tracked and monitored. A minimal setup should include a “Not Started,” “In Progress,” and “Done” columns. Depending on your system, you can mark items as blocked on the card itself or have a “Blocked” column. Items that are identifying as tasks in “Inbox” should be moved to “Not Started.”
Step by Step
Step 1: Set-up a Kanban Board
Create a Kanban board using your tool of choice.
Create an intake column (e.g., “Inbox”). The barrier to entry for this column should be very low, and all team members should be encouraged to add items there. Items can include topics to discuss, tasks, or anything else.
Create a discussion column (e.g., “To Discuss”). This column will contain all items to discuss in the meeting in priority order. It can also contain some “Standing Agenda” items that should be discussed in every meeting. Those should be tagged appropriately.
Create flow columns. These are a set of columns describing how you’d like to drive work through the team. For example, a typical setup includes: “To Do” → “In Progress” → “Done.”
Step 2: Add Items to the Intake Column ("Inbox")
This can be done by anyone at any time. Optionally, the item's creator should be assigned as the owner to make it easier to ask them to give context during the meeting.
Step 3: Nominate a Product Owner
This role has the final say regarding priorities and what makes it out of "Inbox" and what makes it into "To Do."
Of course, they should rely on an active discussion in the team and build consensus before making decisions. If the Kanban app you selected has a voting feature, you can use that as well.
The Product Owner may or may not facilitate the meeting as well. It might make sense to nominate a separate facilitator to reduce cognitive load for the PO.
Step 4: Have a Recurring Meeting
Review the "Inbox" column (5 minutes)
Each person who added an item to the "Inbox" column should introduce it in a few sentences.
They should also say if this is a discussion item or a task.
As items are introduced, move them out of the "Inbox" column and into either the "To Discuss" column or the "To Do" column depending on whether they are a topic or task, respectively.
The PO determines the priority order of items in the "To Discuss" column, and/or participants vote on items.
Walk the board (10 minutes)
Starting from right to left, review items on the board. Owners communicate status.
"Blocked": How can the team help unblock as quickly as possible?
"In Progress": What's left to do? How can the team help move this to "Done"?
"To Do": Can we move anything new to "In Progress"? If yes, assign an owner.
Discussion (remaining time)
The remaining time should be spent discussing items in order of priority in the discussion column.
The goal is to communicate information or determine if we need to create new tasks for the "To Do" column.
If the discussion is taking too long, consider using Lean Coffee to keep things moving.
Summary
Using a kanban board to run your recurring meetings is an excellent way to combine idea generation, drive the conversation, and track progress using one convenient process. It is also a great way to introduce your team to Agile methodologies without a significant upfront cost and disrupting other existing processes.
0 notes