Team Workflow

• 1: Definition of Done
• 2: Limiting Work in Progress
• 3: Retrospectives
• 4: Unplanned Work
• 5: Visualizing Workflow
• 6: Source Management
• 7: Code Review
• 8: Source Ownership

1 - Definition of Done

Is it DONE, DONE DONE, or is it DONE DONE DONE?

All teams need a Definition of Done. The Definition of Done is an agreement made between the team that a unit of work isn’t complete without meeting certain conditions.

Recommended Practices

We use the Definition of Done most commonly for user stories. The team and product owner must agree that the story has met all criteria for it to be considered done.

A definition of done can include anything a team cares about, but must include these criteria:

• All tests passed
• All acceptance criteria have been met
• Code reviewed by team member and merged to trunk
• Demoed to team/stakeholders as close to prod as possible
• All code associated with the acceptance criteria deployed to production

Once your team has identified all criteria that a unit of work needs to be considered done, you must hold yourself accountable to your Definition of Done.

Value

As a development team, we want to understand our team’s definition of done, so that we can ensure a unit of work is meeting the criteria acceptable for it to be delivered to our customers.

Acceptance Criteria

• Identify what your team cares about as a Definition of Done.
• Use your Definition of Done as a tool to ensure quality stories are being released into production.
• Revisit and evaluate your Definition of Done.

2 - Limiting Work in Progress

Why Limit WIP?

Work in Progress is defined as work that has started but is not yet finished. Limiting WIP helps teams reduce context switching, find workflow issues, and keep teams focused on collaboration and finishing work.

How do we limit WIP?

• Start with one lane on your board.
• Set your WIP limit to N+2 (“N” being the number of people contributing to that lane)
• Continue setting WIP lower.
• Once the WIP limit is reached, no more cards can enter that lane until one exits.

Capacity Utilization

There is a direct correlation between WIP and capacity utilization. Attempting to load people and resources to 100% capacity utilization creates wait times. Unpredictable events equal variability, which equals capacity overload. The more individuals and resources used, the higher the cost and risk.

In order to lessen work in progress, be aggressive in prioritization, push back when necessary, and set hard WIP limits. Select a WIP limit that is doable but challenges you to say no some of the time.

Conflicting Priorities

When we start a new task before finishing an older task, our work in progress goes up and things take longer. Business value that could have been realized sooner gets delayed because of too much WIP.

Be wary of falling back into the old habit of starting everything because of the pressure to say yes to everything.

Look at priority ways of working:

• Assigned priority
• Cost of delay
• First-in, first-out

Tips

Swarming Stories

Having more than one person work on a task at the same time avoids situations where team understanding is mostly limited to a subset of what’s being built. With multiple people involved early, there is less chance that rework will be needed later.

By having more than one developer working on a task, you are getting a real-time code review.

Story assignment

Visually distinguish important information.

• Who’s working on what?
• Has this work been in progress for too long?
• Is this work blocked from progressing?
• Have we reached our WIP limit?

References

Making Work Visible - Dominica DeGrandis

3 - Retrospectives

Retrospectives are critical for teams that are serious about continuous improvement. They allow the team an opportunity to take a moment to inspect and adapt how they work. The importance of this cannot be overstated. Entropy is always at work, so we must choose to change so that change doesn’t choose us.

Recommended Practices

Successful Retrospectives

A successful retrospective has five parts:

1. Go over the mission of the team and the purpose of retrospective.
2. The team owns where they are right now using Key Performance Indicators (KPIs) they’ve agreed on as a team.
3. The team identifies whether experiments they are running are working or not.
   1. If an experiment is working, the team works to standardize the changes as part of daily work.
   2. If an experiment is not working, the team either adjusts the experiment based on feedback or abandons the experiment to try something else.
   3. Both are totally acceptable and expected results. In either case, the learnings should be shared publicly so that anyone in the organization can benefit from them.
4. The team determines whether they are working towards the right goal and whether the experiments they are working on are moving them towards it.
   1. If answer to either of the questions is “No.” then the team adjusts as necessary.
5. Open and honest conversation about wins and opportunities throughout.

Example Retro Outline

• Go over the team’s mission statement and the purpose of retrospective (2 min)
• Go over the team’s Key Performance Indicators and make sure everyone knows where we are (5-10 min)
• Go over what experiments the team decided to run and what we expected to happen (5 minutes)
• What did we learn this week? (10-15 minutes)
  • Should we modify any team documents? (2 minutes)
• What went well this week? (5-10 minutes)
• What sinks our battleship? (5-10 minutes)
• Are we working towards the right things? What are we going to try this week? How will we measure it? (10-15 minutes)

Organizing Retros

There are some important things to consider when scheduling a retrospective.

1. Ensure Psychological Safety
   1. If the team feels like they can’t speak openly on honestly, they won’t.
   2. Any issues with psychological safety must be addressed before any real progress can be made.
2. Make them Regular
   1. Agree to a time, day, frequency as a team to meet.
3. Include everyone responsible for delivery
   1. Ideally this will include business colleagues (PO), operations, testing, and developers involved in the process.
   2. If there are more than 10-12 people in the meeting, your team is probably too big.
4. Co-location concerns
   1. If the team is split across timezones, then accommodations should be made so that the team can effectively communicate.
   2. If the time separation is extreme (i.e. India/US), then in may be better to have each hemisphere retro separately and compare notes asynchronously.
   3. Schedule meetings to be inclusive of the most remote. Don’t schedule rooms with bad audio/no video if there are remote participants. Have it via a remote meeting solution (Zoom, etc.)

Tips

• Create cards on whatever board you are using to track your work for action items that come out of retrospective
• Treating team improvement as a deliverable will help the team treat them more seriously.
• Do not work on more than a few actions/experiments at a time
• If the retrospective has remote attendees, ask that everyone turn on their cameras so that the team can look everyone in the eyes.
• Outcome over output: If the format of retro isn’t helping you improve, change it or seek help on how to make it better. The teams that cancel retro are almost always the teams that need it most.

Known Impediments

“Typical” Retrospectives

Normally, a scrum-like retro involves 3 questions about the previous iteration:

• What went well?
• What could we improve?
• What are some actions we can take?

This is pretty open ended format that is very simple to go over in a training class. The challenge is the nuance of facilitating the format.

While it can be effective, what we have found is that this particular format can actually stunt the improvement of many teams when used incorrectly. And since the format is so open ended, that’s extremely easy to do.

Retrospectives that follow the above format are something that many teams struggle with. They can…

• Feel Ineffective, where the same issues crop up again and again without resolution.
• End with a million action items that never get done or tracked.
• “Improve” things that don’t actually move the needle on team productivity or happiness
• End up as a gripe session where there are no actionable improvements identified.

This is such a waste of time. I'd rather be coding...

It can be extremely frustrating to team members when it feels like retrospectives are just another meeting that they have to go to. If that ever becomes the case, that should signal a huge red flag! Something is wrong!

Psychological Safety

If the team feels like they are going to be judged, punished, or generally negatively affected by participating in retrospective, then they are going to keep their opinions to themselves. Without the safety to have their voices heard or take moderate, hypothesis driven, risk, the team will not improve as fast as they can (if at all).

However, if leadership feels like they are being disrespected, they aren’t being listened to/considered, or feel like they are going to be negatively impacted by the outcomes of the team they are more likely to restrain a team from their full potential.

It’s a delicate balancing act that takes trust, respect, and empathy from all sides to come to win-win solutions.

4 - Unplanned Work

Unplanned work is any interruption that prevents us from finishing something as planned. There are times when unplanned work is necessary and understandable, but you should be wary of increased risk, uncertainty, and reduced predictability.

Cost of Delay

Work that has not been prioritized is work that has not been planned. When there are competing features, requests, support tickets, etc., it can be difficult to prioritize what should come first.

Most of the time, teams prioritize based on what the customer wants, what the stakeholders want, etc.

Cost of Delay makes it easier to decide priorities based on value and urgency. How much money are we costing (or saving) the organization if Feature A is delivered over Feature B?

Capacity Planning

The most common pitfall that keeps teams from delivering work is unrealistic capacity planning.

Teams that plan for 100% of their capacity are unable to fit unknowns into their cadence, whether that be unplanned work, spikes, or continuous experimentation and learning.

Planned capacity should fall between 60% and 80% of a team’s max capacity.

Tips

• Plan for unplanned work. Pay attention to the patterns that present themselves, and analyze what kind of unplanned work is making it to your team’s backlog.
• Make work visible, planned and unplanned, and categorize unplanned work based on value and urgency.

5 - Visualizing Workflow

Making work visible to ourselves, as well as our stakeholders is imperative in our workflow management process. People are visual beings. Workflows give everyone a sense of ownership and accountability.

Make use of a Kanban board

Kanban boards help you to make work and problems visible and improve workflow efficiency.

Kanban boards are a recommended practice for all agile development methods. Kanban signals your availability to do work. When an individual pulls something from the backlog into progress, they are committing to being available to do the work the card represents.

With Kanban boards, your team knows who’s working on what, what the status of that work is, and how long that work has been in progress.

Building a Kanban Board

To make a Kanban board you need to create lanes on your board that represent your team’s workflow. Adding work in progress (WIP) limits to swim-lanes will enhance the visibility of your team’s workflow.

The team only works on cards that are in the “Ready to Start” lane and team members always pick from the top. No “Cherry Picking”.

The following is a good starting point for most teams.

• Backlog
• Ready to Start
• Development
• Ready to Review
• Blocked
• Done

Tips

Track everything:

• Stories, tasks, spikes, etc.
• Improvement items
• Training development
• Extra meetings

Work is work, and without visibility to all of the team’s work it’s impossible to identify and reduce the waste created by unexpected work.

Bring visibility to dependencies across teams, to help people anticipate what’s headed their way, and prevent delays from unknowns and invisible work.

References

Making Work Visible - Dominica DeGrandis

6 - Source Management

Use Trunk Based Development

• All branches originate from the trunk
• All branches merge into the trunk
• Branches, if used, are very short-lived
  • The smaller the PR, the easier it is to identify issues. The smaller the change, the less risk associated with that change.
• The trunk can always be built and deployed without breaking production.
  • When needed, use techniques such as Branch by Abstraction or feature flags to ensure backward compatibility.
• The change includes all appropriate automated tests to validate that the change is deliverable.
  • Unit tests
  • Functional test
  • Contract tests
  • etc.

Branching vs. Forking

Use the right pattern for the right reason. Branches are the primary flow for CI and are critical for allowing the team to have visibility to work in progress that the team is responsible for completing. Forks are how proposed, unplanned changes are made from outside the team to ensure quality control and to reduce confusion from unexpected branches.

• Use forks for:
  • Contribution from a contributor outside the team to ensure proper quality controls are followed and to prevent cluttering up the team’s repository with external contributions that may be abandoned.
• Use branches for:
  • All internal work to keep that work visible to the team.

Tips

• Story Slicing helps break development work into more easily consumable, testable chunks.
• You don’t have to wait for a story/feature to be complete as long as you have tested that won’t break production.
• Pull requests should be small and should be prioritized over starting any new development.

Common Issues

Trunk-based development and continuous integration often take workflow adjustments on the team. The main reasons teams struggle with CI are:

• Test architecture
• Work that is too big and/or lacks proper refinement
• Issues with source code ownership (one repo owned by more than one team)
• Workflow management within the team

References

• Trunk Based Development.
• Branching by Abstraction.
• Feature Flags/Toggles.

FAQ

• Pre-requisites for TBD
• Benefits of using TBD
• Releasing From Trunk
• Handling Infrequent Releases
• Handling Bug Fixes
• Handling Incomplete Code/Features
• Validating Release Quality
• Trunk Based Development- You’re doing it wrong

7 - Code Review

Recommended Practices

• Small changes allow for faster code review and enhance the feedback loops.
• Everyone on the team is capable of performing code review.
• Code reviews are the second highest priority for a team behind blocked issues and ahead of WIP.

Tips

• Automate coding standards instead of reviewing for them.
• Focus the review on the tests and code readability. The tests should meet the acceptance criteria agreed upon by the team.
• Keep pull requests small. Look into Work Decomposition for guidance.
• Use synchronous code review to remove communication delays.
• As the person being reviewed, remember the 10 Commandments of Code Review
  • Thou shalt not take it personally
  • Thou shalt not marry thy code
  • Thou shalt consider all feedback
  • Thou shalt articulate thy rationale
  • Thou shalt be willing to compromise
  • Thou shalt contribute to others’ code reviews
  • Thou shalt treat submitters how thou would like to be treated
  • Thou shalt not be intimidated by the number of comments
  • Thou shalt not repeat the same mistakes
  • Thou shalt embrace the nits

References

• The 10 Commandments of Navigating Code Reviews

8 - Source Ownership

Delivery and quality are significantly impacted by teams sharing ownership of the source code. This adds process overhead to ensure everyone knows what’s happening in the code and dilutes quality responsibility.

Recommended Practices

• Utilize automated pipelines to help validate that the product remains releasable before and after any code is merged to the trunk.
• Limit ownership of a repository to a single “Two Pizza Team” that decides what code to merge.
• Give all developers on the team access to merge code to the trunk. Give read access to everyone else.
• Use an innersourcing policy so that people outside of the team know how to contribute to your product.

Tips

• Teams looking to create an InnerSourcing policy can start by applying their Definition of Done to any external contributions.
• No contributions will bypass the team’s quality process.
• Automated pipelines validate that PRs from internal and external contributors conform to quality standards.
• All team members have access to merge to the trunk.
• InnerSourcing and/or external contributions fork the repository they do not branch.
• Teams no larger than 10 people, including all roles.

References

• See the CD Common Problems page to learn about team structure problems and many others to avoid in your journey.