Photo by Eldar Nazarov on Unsplash

Team Working Agreement for a Team Transitioning to Scrumban

This post describes the transitional steps that a team I was working with took to move from Scrum/XP to Kanban/XP/Scrum. I am calling this approach Scrumban because this particular team retained some (but not all) of the Scrum “events,” while introducing elements of Kanban, and continued with technical practices that we already had in place.

Scrumban

Before I get to the structure of the Team Working Agreement, let me add a bit of additional context about the team:

• The team focused on a mixture of technical functions, including work that streamlined the deployment of code, Test Automation, and Production Support.
• The “Product Owner” of the team was a Development Manager, who sometimes picked up cards on the board. The way in which his role most closely resembled that of a typical Product Owner was in how he helped ensure the “Prioritized Backlog” and “Ready” columns on the board were populated with a sufficient number of cards to consume team capacity over a single iteration. As the reader might guess based on what I have just described, the two Scrum events that we chose to drop first were Sprint Planning and Backlog Refinement, given that in our new model plannign conversations happened on an ad hoc (and ongoing) basis.
• We were using Trello to radiate information that we also had on a physical board.

Team Working Agreement

Note that I have omitted certain aspects of the TWA so as not to expose internal business practices or names of individuals:

Communication. We use the following tools:

• <Collaboration tool name> for day-to-day communication.
• <Conferencing tool name> For most team meetings.
• Physical board and Trello to visualize our work (see below for more information about physical board usage).
• <Issue tracking tool name> to track issues.

Transparency. We give feedback, we receive feedback, and we act on feedback.

Impediments. We solve roadblocks within the team. If the impediment can’t be solved within the team, it goes to the Scrum Master (who gets additional help if needed).

Code check-ins.

• For core product lines, commit on dev, release on a feature branch as applicable. Commit against the <tool name> issue. Follow the standard <tool name> workflow.
• For all other product lines, commit referencing an issue in <tool name> if applicable and create a pull request.

Flow.

• We prefer completion of existing work to starting of new work
• We seek to work on only one thing at a time (if something is blocked, it is okay to pick up a second item)
• We have instituted WIP limits. The WIP limit represents the maximum number of work items that can be in process at any given time. .
• New items can be added to the Prioritized Backlog column at any time
• The backlog must be regularly (but minimally) re-sorted
• Progress updates during daily standups are based on cumulative flow (where what matters is where things are in the workflow, e.g., in progress, done)

Board usage (Physical board/Trello board).

Columns (all columns are labeled the same on the physical board as they are in Trello, unless noted otherwise):

• Prioritized Backlog. Placing a card in the Prioritized Backlog column means that the work item is well-enough understood to be prioritized, and likely will be worked on within the next one to three iterations. [Editorial note: “days” or “weeks” could easily be substituted for iterations.]
• Ready. Placing a card in the Ready column means: 1) The card is considered a high-priority work item (the only work items that are higher in priority are in one of the columns to the right of the Ready column); 2) Enough is known about the card that work on it can begin without further team conversation
• Hot (Fast Lane). A card goes in the Fast Lane if that work item demands immediate attention (which in practice means it automatically becomes the highest priority thing to work on).
• Blocked. Placing a card in the Blocked column means that work cannot continue on that work item until an impediment is removed. When it becomes unblocked, it can either be moved back to an In Progress state, or back to the Prioritized Backlog or Ready column, depending on its current priority. Note that for work items where work has not yet started, the Blocked column should NOT be used. Such work items should not be moved to “Ready” until whatever blocking issues that exist have been removed.
• Ready for Tech Review. When a work item is considered ready for verification, a second team member acts as the verifier (using the same model as is used for verification of <tool name> tickets).
• Done. A work item moves to Done when the verifier is satisfied that the work item is complete.

Colors/labels. On the physical cards, we’ll draw a dot that signifies both the type of work, and the person who is typically going to do the work (note that the corresponding Trello cards will be labeled with the same color), where:

• Orange label/dot = Hot (Fast Lane)
• Green label/dot = Test Automation
• Red label/dot = DevOps/Builds/Environments
• Black label/dot = Production Support