Planning is the process of defining an intention for, and making arrangements for, achieving something of Business Value
- What is the work?
- Where are we now?
- When will the work be done?
- What resources will be used?
- To communicate with team mebers and customers
- To provide an agreed response to expected events/risks so everyone doesn’t have to keep it in their heads
- To help answer some of governance questions
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:
- Stakeholder management (inc. DevOps concerns)
- Portfolio and Programme level Dependency management
- Risk Management
- Teaming and resourcing
- Adoption and Business Change
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.
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.
As part of Strategic Direction, the Business Strategy and Strategic Goals forms a top level plan for an organization.
Portfolio and Programme Planning
A Portfolio is a collection of programmes and projects collectively forming the set of investments held by the organization
A Programme is a collection of related projects that collectively deliver business value (through a series of Releases)
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
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.
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/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.
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.
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).
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.
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.
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.
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“.
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.
An Estimate is an approximate calculation or judgement of the value, number, quantity, or extent of something
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.
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).