This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Team Workflow

Improving the flow of work on the team.

1 - Code Review

As Wikipedia puts it, “Code review is systematic examination of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills.”

  • 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

  • Automated Code Review processes like linting and static code analysis.
  • Code review that there are tests that meet the acceptance criteria agreed upon by the team.
  • Keep pull requests small. Look in to Work Decomposition for guidance.
  • 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

Value

Acceptance Criteria

  • Automated checks for standards and complexity.
  • Code is reviewed for testing and clarity.
  • Pull requests are small and last no more than a day.
  • CI tests run upon opening and modifying pull requests.

2 - Source Branching

Trunk-based development, is a requirement for Continuous Integration.

  • All changes begin with a branch from trunk and integrate back to the trunk.
    • Branches should live no longer than 24 hours. The smaller the PR, the easier it is to identify issues. The smaller the change, the less risk associated with that change.
    • Pull requests reviewed by a second party are a compliance requirement.
  • Trunk can always be built and deployed without breaking production.
    • When needed, use techniques like the Branch by Abstraction pattern or feature flags to ensure backwards compatibility.
  • All changes to trunk include all appropriate automated tests.
  • Branching vs. Forking: It is important that the right process be use 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.
    • Forks should be used for:
      • Contribution from a contributor outside the team to ensure proper quality controls are followed.
      • Contribution that may be abandoned and that lost work will not impact team goals.
    • Branches should be for:
      • All planned work done inside the team to prevent lost work due to illness or emergency.

Tips

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

Common Issues

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

References

Value

As a team, the use of trunk-based development enhances our ability to deliver small, value adding, functional enhancements to trunk while also decreasing the time it takes to get feedback on our changes.

Acceptance Criteria

  • All Development begins with branching from trunk.
  • The artifact resulting from changes to trunk is running in production.
  • Branches live an average of less than 24 hours.
  • Team members hold each other accountable to the size and frequency of integrations.
  • Repositories only have short-lived branches and trunk.

FAQ

3 - Workflow Process

Workflow management is the process the team uses to move things from “In Progress” to “Done”, as rapidly as possible in value sequence. It’s important for minimizing WIP that the team looks at the backlog as the team’s work and does not pre-assign work to individuals.

Workflow Management Process

In order to streamline business tasks, minimize room for error, and increase overall efficiency, teams need to have the following prerequisites.

Plan Work

Unplanned work is anything coming into the backlog that has not been committed to, or prioritized. This can include feature requests, support tickets, etc.

Common struggles teams face with unplanned work can be:

Do Work

Completed work meets the Definition of Ready when work begins, the Definition of Done when work is delivered, and can be completed in less than two days.

Process smells identified for completing work include:

Improve Work

In order to plan and complete work effectively, there must be an improvement process in place. The improvement process is centered around feedback loops.

Challenges associated with the improvement process:

Measuring Your Workflow

A good measure to implement in your team’s workflow is WIP. Limiting work in progress can help reduce constraints in your workflow.

Development cycle time is a key measure of success when trying to optimize and automate your team’s workflow.

4 - Definition of Done

Is it DONE, is it 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 actually complete without meeting certain conditions.

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.

5 - Feedback Loops

The most important part of the workflow process are feedback loops, and how they affect the speed and quality of value delivery.

The ultimate goal is to deliver quality software to our customers. Instead of speculating how an end-user might consume your teams’ product, feedback loops improve your existing workflow so that you may meet your customer’s needs rapidly and with less waste.

Examples of Critical Feedback Loops

Feedback loops are as follows: You produce something, measure information on that production, and use that information to improve.

  • How well does the team understand the requirements?

    Teams need to work with leadership to flush out requirements. How well those requirements are understood, can be shown by how often developers are requesting additional information, or how often the team is committing code.

  • How fast can the team detect defects?

    Defects are weaknesses in the system. The systematic approach of detecting where defects are occurring, and how far downstream they are, directly affects a team’s Mean Time to Detect.

  • How effective are our tests?

    Testing is one of the most effective feedback loops a team can have in place. Automated tests for example, provide feedback about your system in seconds.

  • How well does what we’re producing, match the users’ actual needs?

    Understanding if we’re meeting the needs of the consumer is critical feedback.

    How fast can we determine that the customer is using the feature, and is happy with it? The longer the duration between the time we’ve started work, to the time we find out information, the more expensive it is.

Tips

  • Use value stream mapping to uncover feedback loops, not just bottlenecks between specific steps.
  • Focus on feedback loops that involve human communication, not just system alerts.
  • Not all feedback loops are positive. Amplify feedback loops that promote positive change.

Value

As a development team, we want to identify and shorten our feedback loops, so that we can analyze and optimize our workflow processes.

6 - 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.

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.

7 - Unplanned Work

Unplanned work is any interruption that prevents one from finishing something or from stopping at a better breaking point. It increases uncertainty in the system, and makes the system less predictable as a result.

There are times when unplanned work is necessary and understandable, but you should be weary 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 priority 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.

Value

As a development team, we want to understand how to plan for unplanned work, so that we can reduce risk and uncertainty for our deliverables.

8 - 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.

Value

As a development team, we want to visualize our workflow, so that we may improve workflow efficiency.

Acceptance Criteria

  • Use a visual board
  • Show any and all work

References

Making Work Visible - Dominica DeGrandis

9 - 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 keeps teams focused on collaboration and finishing work.

How do we limit WIP?

Limiting Work in Progress is an experiment. 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?

Value

As a team, we want to limit our WIP, so that we may deliver the most valuable thing first.

Acceptance Criteria

  • Set a WIP limit within reason and follow it shamelessly.
  • Work on one thing at a time.

References

Making Work Visible - Dominica DeGrandis