This HTML version of the Pulse Guide is also available as a PDF here.

Introduction

Pulse is at the heart of business agility. If you are struggling with transforming your organisation to be more responsive and need a fresh perspective on how to approach the problem, please read on.

You will probably be experiencing some or all of the following challenges:

  • Multiple waterfall projects running in parallel
  • Long lead times to deliver projects to your customers
  • Complex integration processes
  • Extremely complex architecture
  • A history of legacy systems
  • Lack of time to complete testing adequately
  • Driven by governance processes, audit and assurance functions
  • Lots of handoffs between teams and departments
  • Unclear roles and responsibilities

And … you are probably asking the following questions:

  • It takes months or years to deliver projects. How do I flow work through the system faster?
  • My teams aren’t happy. How can I organise teams so that they are motivated, self-organised and more productive?
  • What are the key metrics we need to measure in order to validate we are doing the right things?
  • My organisation works in a highly regulated environment. How do I deal with this problem?
  • When is the right time to introduce an agile framework?
  • I have lots of teams, how do I tackle the scaling problem?

History

Pulse is an outcome of working with large organisations that struggle with the history of Waterfall processes which are hampering their ability to flow change through their system.

Companies rush to implement Agile frameworks thinking that they will solve all of their problems. What companies find is that Agile frameworks quickly highlight lots of issues but they don’t give any answers. Companies will then look to Agile scaling frameworks for answers. Scaling frameworks give the answers organisations want to hear by prescribing organisational processes, behaviours and structures. What these frameworks lack is the DNA of your organisation which is the key ingredient for success.

What is Pulse

Pulse is simply a collection of patterns that have been proven to enable Agility in organisations and a System Flow that uses these patterns to realise value for your customers.

Pulse is made of the following components:

  • Pulse System Flow
    A target system that will enable a faster flow of work through your entire organisation.
  • Pulse Patterns
    A collection of patterns that Pulse highly values to enable Business Agility in organisations.
  • Pulse Principles
    Three principles that will dramatically increase the success of your major transformation programmes.
  • Pulse Guide
    A guide that brings together the Pulse Principles, Pulse Patterns and the Pulse System Flow.

Pulse Components

Pulse is complementary to existing Agile frameworks. You don’t need to hire expensive consultants to experiment with Pulse and we encourage you to start experimenting with the Pulse Principles, the Pulse Patterns and the Pulse System Flow using your own internal capabilities right now alongside any Agile framework currently being used in your organisation.

The scaling problem. Teams are the basic building blocks of any successful Agile organisation. Even before you think about scaling you first need to create successful teams. Pulse helps you create high performing teams and move from a Waterfall mindset to a mindset of measuring and flowing work through the system.

Pulse Patterns

Pattern. A particular way in which something is done, is organized, or happens.

Pulse simply presents you with a collection of patterns that it highly values. By understanding and adopting the Pulse Patterns you will create the right conditions for high performing entrepreneurial teams to emerge.

The Pulse Patterns are:

  • Each team has a clear set of goals
    A single prioritised backlog of work gives teams a clear set of goals. A team backlog should consist of new requirements, bugs, tech-debt items and non-functional requirements. Teams without clear goals lack focus and motivation. Multiple backlogs of work increases the amount of work in progress (inventory) within the team and reduces flow.
  • Teams stay together for longer
    Team that stay together longer are more successful. If you find yourself ramping up and ramping down teams on a project by project basis, fund these teams for 1 year or more to create team stability and retain knowledge in your organisation. Flowing the work through stable teams will increase throughput and reduce kep man dependencies.
  • Teams are autonomous
    Teams that are autonomous and in control of their destiny are high performing. You must coach teams to code, test and deploy as independently as possible and within strict timeboxes and make them accountable for the desired outcomes. You must remove any contracts between teams and departments so that works flows through the system faster. Decision making must also sit within the team to avoid delays in flowing the work through the system.
  • Teams have short feedback loops
    Continuous improvement requires listening to feedback frequently. This can be feedback from internal stakeholders and external stakeholders such as customers. To reduce the feedback loops you must increase the frequency of releases, implement test automation and remove handoffs between teams and departments.
  • Teams have a shared understanding of the work
    Context is king. Teams that have a shared understanding of the work have a higher probability of getting it right first time. If you have offshore and onshore teams you must help these teams work as a unit and all team members must be part of the conversation regardless of location.
  • De-centralise control
    De-centralising control to the teams does not mean you are not in control. Set clear goals and outcomes for teams and get out of the way. Listen to the feedback loops and key metrics to create focus and intent of direction.
  • Break down projects into small batches of work
    Projects or demand is broken down into small chunks of work. Large pieces of work carry a high level of ambiguity, unknowns and risk. Small chunks of work flow are predictable, carry low risk and flow through the system faster.
  • There is a single backlog for all requirements
    All work is managed through a single portfolio backlog of requirements at organisational level. All new requirements as well as business as usual requirements are prioritised, ordered and relatively sized within the single portfolio backlog. Having multiple backlogs of work increases the amount of work in progress, lack of transparency on priorities and slows down flow.
  • Measure Lead Time
    We measure the Lead Time of each step in our system to enable business agility. Change requires a short lead time in order to minimise the work in progress which reduces waste and allows new priorities to be delivered effectively.

Pulse System Flow

System. A set of connected parts that operate together to create a whole that is greater than the sum of its parts.

Flow. To move in one direction continuously and effortlessly.

Pulse aims to provide organisations with a target system flow to enable transformation to Continuous Deployment through a series of interim states, no big bang. Pulse starts by enabling organisations to identify a target operating model and the transition states to get them there.


  • Demand
    Change is delivered into the system via demand, likely to be in the form of projects/requirements/epics/stories/bugs/problem statements.
  • Single Backlog
    Clear goals are achieved by identifying the portfolio resources and strictly prioritising the work. Resources take many forms working together to enable change.
    • People
      All people need to be considered to enable the change. Think about whom is your constraint? Is there someone who works outside of the teams that you rely on ? Maybe a DBA that you use once in a while, yet he’s never available when you need him?
    • Systems
      Systems need to be available to enable a change. We need test systems, we need development systems, we need UAT systems. If these systems are again not available at the time you need them they will become a constraint
    • Applications
      All applications that you need to deliver change should be within the portfolios control to prioritise. If there is a shared application then this may become a constraint that hampers your flow.
  • Refinement
    Pulse aims to minimise the amount of analysis teams spend on requirements that will never be delivered. Requirements flow through the refinement process gathering detail and certainty as they make their way up the priority stack.
  • Team Backlog
    Detailed requirements from the refinement process flow through into the team backlogs with all teams contributing together to achieve the portfolio goals.
  • Teams/Systems/Applications
    Teams systems and application work together delivering team level continuous integration and portfolio level integration on a regular basis (with the target of being continuous). Quality Assurance is like life insurance, you have to have it, but you don’t want to use it! Therefore all testing is completed in the Team and Portfolio level continuous integration phases maximising the feedback cycles through automation. QA provides a final validation check to ensure all software is fit for deploy, which may be run on a production like environment with production quality content.
  • Deploy and Realise Value
    Value can only be realised if we release the change to the customers.
  • System Feedback
    We crave feedback through the system minimising waste and lead times in order to maximise customer value delivery.

In our experience teams which adopt Agile frameworks prior to meeting the right organisational conditions for Agility result in engineers forgetting how to do software engineering and the immediate focus is on process.

Pulse Principles

50-75% of major change programmes fail to realize their intended outcomes. You will minimise the risk of failure of your change initiatives by adopting the Pulse Principles. Pulse highly values the following three principles:

  • We clearly communicate the change
    Organisations need to clearly and regularly communicate goals, milestones and outcomes of the transformation programme to all affected teams.
  • We assign single accountable owners to the desired outcomes
    Transformation change programme goals, milestones and outcomes are assigned to single accountable owners. Outcomes must be measurable and it is important that those accountable for the change understand how to measure and communicate progress with transparency.
  • There is a high level of commitment at all levels of the organisation
    There is a high level of commitment to transform the organisation in terms of structure, ways of working and reward. The transformation is part of the work and not a side of desk activity.