Planning

Planning is the process of defining an intention for, and making arrangements for, achieving something of Business Value

In Holistic Software Development a plan may be a formal or informal description of how work will be done and controlled, defining scope, schedule and resource usage targets. We focus plans on achieving business value to ensure that plans are aligned to the business strategy and “doing the right thing”. Planning does not constitute progress, only working products should be considered progress.
Plans should be understood to be “best guesses” rather than accurate predictions of the future.
“No plan survives contact with the enemy.”
The purpose of a plan is to answer:
  • What is the work?
  • Where are we now?
  • When will the work be done?
  • What resources will be used?

If a document, picture or other set of information is described as a plan but does not clearly communicate answers to these questions then it isn’t fit for purpose.
There are three purposes to planning:
  1. To communicate with team mebers and customers
  2. To provide an agreed response to expected events/risks so everyone doesn’t have to keep it in their heads
  3. To help answer some of governance questions

Planning Guidance

Plans typically include references to sets of requirements and required levels of done, chunking deliveries into releases, and are usually described using “pahses” leading to Milestones. As well as these “production” elements plans may include information on “management” elements such as:

For best results we recommend that planning is a collaborative activity between all relevant stakeholders. A common dysfunction is for a “Planner” who knows least about the business problem and technical solution to think they are in control, creating a plan in isolation that doesn’t reflect reality and is irrelevant to the people involved. Instead a talented Leader or Project Manager can guide the team to consider all of the elements that are necessary, understand their constraints, remove their impediments and facilitate a common understanding between relevant stakeholders.
We recommend that plans only contain enough detail to communicate the answers to these questions clearly and avoid planning chains of activities to be performed by people at set times (micro-management). This work breakdown structure pattern is logically flawed since the cumulative error margin on any estimated task after a chain of three or four tasks is typically greater than the length of the task itself. We cannot accurately estimate or predict the future, especially in such a complex field as team based software engineering and so should not offer false levels of precision in our plans.
We recommend that top level plans are rich pictures that explain and communicate key elements of direction, time, scope, releases, levels of done and resource usage. Plans focused on Releases, monitored by Milestones, that are expected to change, can be extremely valuable communication tools that join up the views of delivery teams with business management functions such as portfolio management.
Although most planning is based on the production of something according to requirements, teams often also wish to plan non-requirements activities. For this, we recommend “objectives”.

We recommend planning non-requirement activities as Objectives.

Objectives represent non-requirement activities that must be done to enable successful delivery.

Objectives can be used to represent overhead, setup and team improvement activities on a backlog. These concerns should not be considered as user stories as they add no direct value to a consumer. Objectives, therefore, should not contribute story points to team velocity (for agile/iterative teams) as they are not part of the product scope and will be inconsistent in terms of effort, therefore extrapolation of their completion is meaningless. Instead Objectives are best thought of as overhead. Explicit representation of overhead vs. requirements means that teams can be transparent in discussions with Product Customers regarding the necessity of overhead activities and trade them in/out against requirements.

HSD Plans

In HSD the various Backlogs and the Portfolio Requests, structure of Programmes, Projects and Releases form the basis of planning in terms of defining sets of deliverable scope, target levels of done, timescales and resource usage across teams.

Strategic Planning

As part of Strategic Direction, the Business Strategy and Strategic Goals forms a top level plan for an organization.

The Strategic Direction practice involves Business Leaders articulating the Business Strategy and deriving Strategic Goals that shape the Portfolio and Enterprise Architecture

Portfolio and Programme Planning
The Portfolio can be considered an annually refined plan, with in year feedback from Continuous Investment Review, used to focus investment on strategic goals. The Portfolio may be structured according to the Hybrid Dynamic Model or in other ways. Ultimately the Portfolio is composed of pieces of work with varying delivery methods such as Incubators, Experiments, Projects, Programmes, Cells etc.
Portfolio Planning is used to execute the Strategy.
At Portfolio (and Programme Level if it exists) plans focus on Milestones, dependencies, resources and top level risk management. As delivery work executes it will refine estimates and often resource needs – these must be fed back to higher level plans to refine them.
A Portfolio is a collection of programmes and projects collectively forming the set of investments held by the organization
Common ways of structuring work within portfolios are programmes and projects.
A Programme is a collection of related projects that collectively deliver business value (through a series of Releases)
Note that although we cover all of these levels of planning we do not intend to imply that a structure of Portfolio → Programme → Project → Team is required for every piece of work. These different levels of planning are tools that can be used in different combinations for different types of work.
Traditional definitions of Programmes vs. Projects sometimes focus on Programmes being “transformational” and Projects being about “delivery”. We do not use this part of traditional definitions because it implies that Products cannot be transformational, unless there’s a programme. This leads to unnecessary Programme structures for single products. Instead, we think that every project should include its relevant business change activities, sometimes transforming the business or market segment. We use the Product Forum practice as an alternative to traditional Programme Management.
Projects

A Project is a temporary collaborative endeavor undertaken to create a unique product, service or result (through a series of Releases)

This definition of “Project” is close to the PMBOK standard and points out some key features of a project:

  • It is temporary, once its aim has been met it finishes
  • It is collaborative, it uses people and resources
  • It has a specific goal, normally one primary goal

Strictly by this definition most work to create a product can be considered a “project”. In HSD we often talk about “product development” and “projects” fairly interchangeably because of this. However, the word “project” also invokes ideas around traditional “project management” that can be counter to modern ways of working with embedded bias towards waterfall methods. As a result, we see a lot of focus on “teams”, “cells”, “delivery units” etc. The software industry needs to move past this discomfort. When we use the word “project” in HSD, we mean a temporary collaborate effort to meet a specific goal or create a product through a series of Releases

Project != Project Management

Many organizations stretch the definition of a project to include many different aims, making their projects run for a very long time (sometimes over many years). When organizations do this they change the nature of the “project” into something more similar to a “programme” and yet frequently do not change the practices applied to manage the work. As a result, project management practices are inappropriately applied. If a “project” has many aims and will deliver several products as a large system of systems it is a Programme, not a Project.
If a Project construct is tightly tied to creation of a Product it can be useful, but “projects” and “project management” are not required to deliver a project. Both constructs are used when delivery teams need managing, which is not always the case. Many teams, and many delivery methods are self-managing.
The idea that all work, and all people, need a manager is a myth.

A Project in Holistic Software Development

In Holistic Software Development we consider a software project, whether in explicit form, or an implicit collection of activities and people one of three ways:

1. The Small Picture of HSD

The Small Picture of HSD is essentially a map of a single project. 

2. A stand-alone Project

When Projects aren’t part of a programme, they are simply stand-alone projects as part of the Portfolio. This means that their requirements will derive directly from a Business Case (or Portfolio Request) although they won’t need intermediate levels of requirements elaboration or Solution Architecture as the only architectural context is Enterprise Architecture.

The Project boundary is further expanded as a stand-alone project is responsible for raising its product to the highest required level of done and will also normally have product adoption and business change as part of its scope.

3. As part of a Programme

When Projects are part of a Programme they get a lot of context from the programme in the form of requirements (a programme backlog), planning (some form of coordinating roadmap) and architecture (Solution Architecture).

A Programme will normally be responsible for sourcing development and test environments for the Programme as a whole rather than each child project diverging, but sometimes a Project will have to source its own environments if it is unique.

A Project that is part of a Programme will deliver its product to the Programme iteratively and incrementally, if not continuously, for integration with output of other Projects to form a Product Family.

During development we recommend seperation by interface between Project teams, not source sharing dependencies.

The Programme is normally responsible for adoption and business change of the entire solution, delivered incrementally rather than individual Projects.

Due to this structural relationship, Programmes can feel like the customer to Project/Delivery teams. Programmes, may actually be a Business Customer (in that they are coordinating funding) but they are not the Product Customer, which should be a real end-user Customer wherever possible.

If conflict is likely between Programme Business Customers, Product Customers and delivery teams the Product Forum practice is ideally suited to de-conflict the situation.

Projects with Internal Structure

Within a project (in either shape) projects may have internal structure as teams are organized to deliver the primary aim of the project. Teams are often organized into function teams and component teams, delineated by architecture, work streams/packages or other patterns. All have their advantages and disadvantages, the key thing to bear in mind, is that pull is established across each team to the project. Teams must be formed effectively and understand their value proposition to the project and in turn the business. When considering internal project structure be mindful of Conway’s Law.

Critically, the definition of done must be understood between teams without losing focus on the teams’ collective responsibility to deliver the product as a team of teams. More information on cross-team interactions is in the Team-Forming practice.

Projects may encompass a mix of agile/iterative teams, continuous flow teams and other delivery models as part of Product Delivery.

#NoProjects

As mentioned earlier, the “project” construct isn’t necessary for product delivery. Various delivery methods ranging from Incubators, Accelerators, Hackathons, organic cells etc. exist to deliver projects. Sometimes it’s useful to treat all of these things as “projects” as it makes sentences shorter when talking about portfolio management, which is why we often use “project” with a lower case “p” to cover these pieces of work.

The hybrid dynamic model, and HSD in general, embrace multiple methods. We recommend that leaders enable multiple processes to be used in parallel for different types of work. There is little to be gained from standardization of creative knowledge work and a lot to lose.

Project Management

Project/Product Managers act as leaders for teams performing critical communication roles, dealing with stakeholders, coordinating with other teams, mitigating local risks, driving continuous improvement etc. Not all teams need Product/Project Managers as some teams perform these functions as a group.

Release Plans

A Release Plan is a medium term plan that defines a series of high level goals that delivery teams can “sprint” or “flow” towards.
Release plans join up the Portfolio/Programme views with Projects/Delivery Teams.

Each Release is typically defined iteratively in terms of scope as a subset of a Backlog. We recommend Releases are defined in terms of Integration Scenarios or Features, or other elements from a Scoping Diagram, with target levels of Done. The HSD model itself provides consistent standard Definitions of Done to bring them together. We recommend planning Releases in a visual form similar to the HSD Big and Small Pictures, using Milestones over time:

In larger organizations, resource management can be done based on Release plans at a Portfolio level. Resources can then be traded across pieces of work by incorporating feedback from Release progress into higher level plans as estimates are refined. Release progress is typically tracked using Release level workflow metrics. We recommend that Releases are at a maximum quarterly, preferably monthly or continuous.

Builds

Personal Builds will happen very frequently, at a developer’s discretion, and are not formally tracked. They may well fail and such failures are simply part of the local software development technical practices – they should not be reported. Developers using compiled languages will often build simply to check their syntax and run IDE based code analysis – maybe never actually running a personal build. Team Builds tend to follow successful Personal Builds when a developer pushes their changes or an integrator pulls them into an integration stream or automated build server (see Continuous Integration).

Personal Builds tend to happen at the “Developed” level of the Definitions of Done, whereas Team Builds tend to happen at high levels of integration and Definition of Done.

A build may apply to a component, system or system-of-systems and represents proof  that the code elements pass inspection and some limited quality assurance. In the case of non-compiled languages, a build may be harder to define, especially at a personal level, however since personal builds are not tracked or reported that tends not to be important. We recommend that a basic level of developer testing, unit testing and/or static analysis is done prior to promotion of changes to a team Build level, even for non-compiled languages.

We recommend that team builds are frequent, preferably daily or continuously (see Continuous Integration). ). A Build may not be a releasable version of a product or product family. The purpose of frequent builds is to ensure that the collective changes that make up software are in a working state (and haven’t introduced “regressions” or Problems). If the interval between working versions is short, then finding the cause of bugs is relatively easier (and can even be done by “binary bisection”) making defects easier to fix or simply discard rather than fix.

Personal Builds will typically not affect a Product version number, whereas a Team Build might affect the very last part of a version number (e.g. 2.3.67).

Builds are the smallest form of feedback cycle in Holistic Software Development and therefore the earliest opportunity to prove value, reduce risk, verify and validate the product at both Product and Product Family Level.

Technical Development practices such as Test Driven Development, Pair Programming and Mob Programming can even move the feedback, verification and validation into the code production activity prior to a Build although they are no replacement for actually running working software.

Releases

A Release is a version of a product which has met enough high-level requirements to deliver sufficient business value that the product could be adopted by the business and deployed operationally. This means that Releases must have a high level of Done, typically as far as “End 2 End Tested” and even into “Business Acceptance”. While a Build typically integrates a number of low-level requirements to a minimal level of Done, a Release delivers a number of high level requirements to a high level of Done. A Release delivers  Business Value.

A Release (via a Release Plan) is also the bridge between planning phases (and therefore often contractual phases) and high level requirements such as Integration Scenarios and Features, or sometimes other Scoping Diagram elements.

These plans and requirements come together, through product delivery and integration into a Release – an implemented version of a Product or Product Family. Since a Release as a planning construct defines a scope in terms of the requirements it also bridges planning with architectural achieving risk reduction through working software.

A Release is the physical realization of a significant milestonein a development lifecycle. Releases are the heart of any development endeavor and so the heart of the H-Model. We recommend focusing planning, process, architecture and adoption efforts on Releases.

A Release represents a significant achievement for the development team, however not every Release will be deployed operationally as Release cycles may be de-coupled from Adoption and Business Change cycles. However, Releases that are not deployed carry quality and validation risks, despite acceptance activities so we recommend that adoption and release cycles are kept reasonably in sync. The only way to actually mitigate risks is to use working software in real situations, testing can only indicate not prove quality.

Continuous Deployment practices involve every releasable version of a product being, often automatically, deployed operationally. Continuous Deployment can be difficult for business users to become comfortable with, as from their perspective, the product can change every time they use it, however if deployment is truly continuous then user facing changes are typically small and can be easier to adopt than a large set of changes requiring user retraining.

Importantly, Continuously Deployed products have their quality assured continuously, meaning feedback can be continuous and so are far more responsive to change.

Very early Releases may be focused on proving architectural approaches and may not be viable products from a customer perspective, however early architectural releases are significant achievements for any development and we strongly recommend their use in conjunction with a risk driven approach. Despite not being viable products they are important points for feedback and course correction. We recommend that any release, including these very early releases is requirements based and delivers at least one functional requirement to avoid architectural gold-plating becoming divergent from requirements.

Releases will typically affect the major numerical or named parts of a version number/label  (e.g. 2.3.67).

Releases are a critical point at which planning, requirements, architecture, testing, and customer validation come together enabling feedback cycles throughout the Software Development organization.

Release planning is commonly dysfunctional in complex software organizations, in part due to the duality inherent in the concept of a release. Holistic Software Development aligns the various concerns at Product and Product Family Release levels through Requirements, Architecture, Integration Streams, Reporting, Environments and Definitions of Done – all cohesive at horizontal layers of the Big Picture.

The idea of a Minimum Viable Product (or MVP) has recently become popular to describe “a version of a product that allows a team to collect the maximum amount of validated learning about customers with the least effort” – Eric Ries.

Integration Streams combine the output of multiple developers, and/or from multiple contributing teams in a complicated or complex system. They also provide a staging mechanism for testing prior to promotion from “build” to “release” enabling progression through the levels of done. Integration Streams are typically implemented as “streams” or “branches” in version control tooling.

Delivery Planning

The only other plan explicitly indicated in the HSD Big Picture is a Sprint/Iteration Plan, which may not even be used by Continuous Flow Teams since planning at delivery level will take different forms depending on the nature of delivery teams:

Waterfall Teams use the waterfall model of development that entails a linear sequential path through requirements definition, analysis, design, development (coding), testing, deployment and maintenance. The waterfall model has been extensively proven* to be badly suited to Software Projects as it is only suitable for trivial, very small time frame, very low risk work with an experienced team where everything is completely predictable.

Agile/Iterative Teams follow a lightweight, evidence based, adaptive approach to software development. Delivery is frequent, with regular increments adding to an increasingly rich product.

Continuous Flow Teams delivery value one change at a time. Pulling work from a prioritized backlog, typically limiting the amount of work in-progress to smooth flow across delivery activities. Continuous Flow teams work towards a pull from customers, releasing continuously as each change reaches a high “Level of Done“.

Sprint/Iteration Plan

A Sprint Plan (or Iteration Plan) is time-boxed plan of a short duration usually 1 to 4 weeks. The sprint plan will be fine grained, identifying user stories intended for implementation during the sprint/iteration.

A Sprint/Iteration Plan is only valid for an Agile/Iterative team as Continuous Flow teams will simply take the top requirement from the Product Backlog and Waterfall Teams have no concept of fine detailed short-term plans. The terms “Sprint” and “Iteration” are interchangeable. Sprints/Iterations work towards achieving Releases and so Sprint/Iteration Plans are closely related to Release Plans.

Estimates

An Estimate is an approximate calculation or judgement of the value, number, quantity, or extent of something
In business, we often wish to estimate software complexity, effort and timescales to help with business planning and feed into start/stop decisions as part of Portfolio Selection and Continuous Investment Review. Estimates should always be presented with uncertainty indicators and are little more than guesses. Estimates should never be treated as accurate.

Maintaining cohesion across plans – Milestones

A Milestone is a significant event or decision point in the lifetime of a project.

Holistic Software Development uses a standard set of layered Milestones to drive the Risk-Driven Lifecycle. Milestones are a useful way of tracking top-level guesses about when scope will be delivered. Like estimates, they should not be treated as deadlines.

Planning Formats

As with our Requirements recommendations we recommend flexibility when choosing a planning format. Plans are a communication tool and so clarity is the most important factor when thinking about how to represent a plan. Organizations that adopt a planning tool will often attempt to represent all plans in that tool to force consistency at the expense of clarity. Instead we recommend choosing the right tool for the right plan.

Top level plans in the form of Strategic, Programme Plans or Release Plans are best represented as rich pictures, typically with a time element as a primary scale. We recommend linking rich picture plans to information on scope in portfolio, planning or work item tracking tools rather than representing scope details on high level plans.

Low level plans such as Sprint Plans or Team Plans may be represented in the form of a backlog or Kanban board (in either case plans may be physically represented with whiteboards and stickies or virtually in work item tracking or agile planning tools).