Following from Part 1 of this series, which provided a high-level overview of three common Agile Planning Horizons, this article provides a closer look at the “Flow” Planning Horizon.

Overview: Flow Planning Horizon

Flow is a “just in time” delivery framework where the work is prioritized and visualized on a Kanban board.

The main objective of Flow is THROUGHPUT – the goal is to complete the highest priority work in a continuous flow. This is accomplished by MINIMIZING the work in progress (WIP) so that the team/individual only works on one thing at a time until that work is DONE, then they pull the next highest priority item from the “to-do” stack. Sometimes, work gets blocked waiting for external input or approval – in this case, teams can use a “blocked” column and pull the next highest priority item, but blocked items must be the top priority of any work in flight and be worked as soon as it becomes un-gated.

Because work is continuous flow, it does not need to be estimated. Daily standups are not required but often prove to be beneficial – this type of Flow is often referred to as “Scrum-ban”. Retrospectives are not required, but in practice they should be held at some regular interval (e.g., monthly) to review the team’s performance, throughput, and quality, and to address common impediments that should be resolved within the organization.

Work is visualized on a Kanban board. The Kanban board uses separate columns to identify work to do next, work in progress, and work completed.

• The “To Do” column is a prioritized list of work to be done, where team members pick from the top of the list when taking on new work.
• The “In Progress” column is a list of the work “in-flight” and being delivered at any given moment.
  • The “Done” column represents the list of work completed. In Flow, this can also be two columns – an “In Review” column is often used to show work that is completed but requires review and acceptance in order to be considered “Done”. In this case, there will be a “done” or “accepted” state where the work is catalogued for historical record and measurements of the flow rate / velocity.

The Kanban board – Example:

Source: [https://leanicontechnology.com/what-agile-methodology-is-best-for-your-development-teams-in-2020/]{.ul}

Key elements to visualize:

• Criteria required for any work item to advance to the next workflow state. For example: Items in “to-do” need to meet some definition of “ready to work” (clear requirements, data inputs identified, etc.) Items in “in progress” need to meet some standard definition of done such as dev complete for all acceptance criteria/requirements, test complete, unit test or code coverage requirements complete & documented, etc.
• WIP limits – according to the team standard set and agreed upon, work in flight must remain within this limit to ensure smooth and “ASAP” throughput

Pros and Cons

Pros – Here are the conditions which lend themselves to a Flow-based planning horizon

• The work is routine or repetitive (i.e., the work is well understood, common, frequent)
• Helpdesk or operational support work – teams dedicated to working defects arising from an established production process or product/application
• Work that is not plannable, or doesn’t require a detailed/defined pre-planning process (ad hoc work)
• Work that is simple enough to not require regular and holistic inspect & adapt cycles
• Teams that are not mature in Agile
  • Specialized roles are not required (product owner, scrum master, etc.). However, many organizations find it beneficial to have a role that:
    • Owns prioritization, completeness requirements, and removal of impediments
    • Monitors throughput and delivery results, facilitates continuous improvement
  • Agile ceremonies are not necessarily required (but often beneficial) such as daily standups, backlog grooming, work planning and commitment, demonstrations of functionality
  • Work doesn’t go through a grooming/refinement and estimation process
  • There is no requirement for strict adherence to team size guidelines per Agile Scrum team best practices (typically 3 to 10 individuals)
  • There is no requirement for truly cross-functional capabilities of the team; often Flow teams can be composed of people who are specialized in one or a few types of work; they don’t require a truly cross-functional skill set in the same way that an Agile Scrum team does.
  • There is no time-boxed cadence (though this can be a double-edged sword and lead to bad habits and inefficient processes unless it is managed and worked with discipline)

Cons – Here are the conditions which DO NOT lend themselves to a Flow-based planning horizon

• Work that is unfamiliar to the organization (“build new” versus “known process”)
• Work that is complex; work that has upstream or downstream dependencies that must be coordinated and negotiated (i.e., work that needs to be planned for execution both within and outside of the team)
  • This is especially true for work that is composed of features/epics and strategic initiatives where there are many functional parts that make up a larger whole of value to be delivered
• Work that requires multi-discipline skillsets for delivery of work (e.g., UI work, middleware, database, architectural design, security & compliance scope, etc.)
• Work that requires a high degree of stakeholder, vendor, or other external collaboration and partnership

This series will review the three primary Agile Planning Horizons utilized by organizations for Agile Development, along with general guidelines, pros & cons, and “entry criteria” guidelines that should be considered essential in order to adopt and deliver. For Part 1, we will provide a summary overview of the three most common Agile Planning Horizons. For Parts 2 – 4, we will provide a more in-depth description of each Agile Planning Horizon:​

• Flow / Kanban / “Scrum-ban”​
• Sprinting (classic Scrum)​
• Program Increment (Scaled Agile)

Overview

The term Agile Planning Horizon refers to the Agile Planning process used to identify, prioritize, “queue up”, and deliver work in an Agile organization.​

In general, the “right” Agile Planning Horizon for a team (or a group of teams) will be chosen based on:​

• The nature or type of work being delivered​
  • Rote or repetitive work (Flow)​
  • Complex work involving risks, unknowns, interdependencies or uncertain requirements (Sprint)​
  • Complex work at large scale (Program Increment)​
• The planning timeline – whether and to what extent the work can/should/must be planned in advance​
• The Agile Maturity or Agile Capability of the organization

Summary​

• ​

Flow

• The Agile Framework known as Flow is also commonly referred to as Kanban or “ScrumBan” (where a daily scrum is utilized by the team). This is a “just in time” delivery framework where the highest priority work is identified and delivered in a continuous flow. The main objective of this Framework is THROUGHPUT.​

Flow is best for work that is routine or repetitive; work that is well understood, common, or frequent. It is ideal for Helpdesk or Operational Support work – work that cannot be planned or is ad hoc and doesn’t require detailed pre-planning. Flow is also a good choice for teams or organizations that are not mature in Agile Practices due to a few key factors:​

• There is no requirement for a time-boxed planning and delivery cadence. Work can be introduced and reprioritized at any time​
• There is no requirement for defined, specialized roles (Product Owner, Scrum Master, etc.)​
• There is no requirement for team members to have a cross-functional skill set; if a team has a specialized skill set, they can adopt this lightweight Agile Framework.​

Flow is poorly suited for delivering the work where:​

• The work is unfamiliar to the organization (“building new”)​
• The work is complex, with upstream or downstream dependencies that need to be coordinated and negotiated or agreed to​
• The work requires team members to possess multi-disciplined skill sets (e.g., full stack development)​
• The work requires collaboration with stakeholders, vendors, or other external teams

Sprinting

• ​The Sprinting Agile Planning Horizon is used by Scrum teams to rapidly and iteratively deliver complex and high-value work in defined timeboxes called Sprints; in a Sprint, work is planned and delivered on a fixed cadence.​

Scrum teams consist of 3-10 team members and perform three defined roles:​

• Product Owner (PO) – The PO is the customer representative who owns the backlog and work requirements, and prioritizes the work to be delivered by the team. The PO is responsible for accepting or rejecting the delivered work on behalf of the customer.​
• ScrumMaster (SM) – The SM is a servant leader who works to build and maintain a high-performing team, facilitate the various scrum ceremonies, remove blocks and impediments, and keep the team focused and on track.​
• Team Member – The team members deliver on the product vision by iteratively building the high-value work required by the customers. The collective team should possess all of the skills and capabilities required to deliver the work. The team members own grooming, refinement, and estimation of the backlog. The team also owns the “Sprint Commitment” – the team’s commitment of what will be delivered in a given sprint.​

Sprinting is best for work that is complex, where the requirements or technology are uncertain – where negotiation and collaboration are required. The priority and requirements of the work to be delivered are understood at general level, so that the work can be planned and delivered within a few sprints. The Planning Horizon is on the scale of weeks to a couple of months. Sprinting is also ideal for situations where the team is able to frequently collaborate with stakeholders or customers to agree on detailed requirements and where negotiation can happen during the delivery process.​

Sprinting is not recommended for organizations that cannot commit DEDICATED resources to fulfill the Scrum roles continuously; further, the organization should commit to building Scrum teams that are “sticky” where Team Members are dedicated to their teams and are not swapping in and out of teams. Further, sprinting is not a good choice for situations where delivery requirements are unstable and constantly changing. Sprinting is not the best fit for organizations whose stakeholders are not consistently available to engage, collaborate, or provide critical feedback.​

Program Increment (PI)

​The PI is the timebox artifact of a Scaled Agile organization, where multiple teams are working from a common “Portfolio-Level” backlog towards delivery of large-scale, strategic solutions. The PI Planning Horizon consists of numerous sprints during which all teams are synchronized on the same timebox cadence so that all teams coordinate and cooperate in the PI planning event as well as the ongoing execution of the committed PI plan. A PI will typically span 2-3 months on the calendar (basically this will be a Quarterly Planning Horizon). In general, any Scaled Agile Framework will have extra layers of communication and control to enable Agile practices for large or very large groups.​

In a Program Increment Planning Horizon, numerous Scrum Teams form a Release Train; for very large-scale solutions, multiple Release Trains form Solution Trains.​

• Release Train – A team of teams in synchronous cadence and executing in concert against Portfolio or Program level product goals​
• Solution Train – An organized group of release trains in synchronous cadence and executing in concert against Enterprise or Portfolio level product goals
• ​​
• Source: https://d2o2utebsixu4k.cloudfront.net/media/images/1544077632343-A-Value-Stream-can-have-many-ARTs-within-it.jpg​

In addition to the Scrum Team roles which exist at the Scrum Team level (Product Owner, ScrumMaster, Scrum Team Members), in a Scaled Agile Framework there are also some additional roles:​

• Product Manager – This role owns, defines, and prioritizes the Program Backlog. The Program Backlog is what populates the Product Backlog, which is owned by the PO at the Team level. At very large scale, Portfolio Managers own and define the Portfolio Backlog which feeds into the Program Backlog.​
• Release Train Engineer – This role acts as “Chief ScrumMaster” for the Release Train; the RTE helps to build and support the teams in the Release Train, facilitates PI ceremonies, and removes blocks/impediments at the Release Train level. At very large scale, Solution Train Engineers perform similar duties at the Portfolio or Enterprise level.​
• System Architect – Provides architectural guidance and technical enablement to teams in the Release Train. At very large scale, Enterprise or Solution Architects perform similar duties at the Portfolio or Enterprise level.​

A Program Increment Planning Horizon works well for large organizations which are mature with Agile development practices, who seek to deliver Enterprise-wide, “Market-making” capabilities at a (relatively) rapid pace.​