Peter Cronin

The scale-up expert

"Peter's insights on how to overcome today's challenges in the software development cycle is brilliant"
Book Peter

About

Peter Cronin demonstrates how it’s possible for tech companies (and others) to scale performance faster than costs.

When Peter introduces you to Pace, you discover a radical yet proven method that successfully brings scheduling into alignment with the speed of modern development cycles.

No fluff, no nonsense, just a revolutionary process that reboots software development so management can plan, implement and deploy at a faster rate with fewer risks and greater potential for growth.

“My passion is helping software companies scale without losing the magic.”

Peter's background

Peter Cronin is a Sydney-based Kiwi, director of ViAGO International, and the author of Pace.

Peter has worked with scores of software teams across dozens of different industries since 2010, helping companies (and their people) to reengineer operations so they can consistently deliver higher-quality code, faster.

In that time, he has presented in front of hundreds of business owners, and he jumps at opportunities to run courses, talk at conferences, webinars and guest-star on podcasts.

There’s only one catch; you’d be hard pressed to book him for a last-minute engagement; in his other life Peter is training for his pilot’s license, and picks up flying lessons whenever he has an hour to spare.

Peter is endlessly fascinated with the way people think and learn. He has been a Black Belt in Thinking presenter for nearly a decade, and is an expert in teaching Eli Goldratt’s Theory of Constraints Thinking Processes (System 1 and 2 thinking techniques) to people.

Results

A breakthrough business
methodology with striking results

  • tick

    Months worth of cash discovered hidden in work-in-progress chaos.

  • tick

    Solutions declared impossible ‘when pigs fly’ by founders only to be ‘grounded’ the next day, and implemented in the following months.

  • tick

    Scale up plains built on cause-and-effect driving the strategy through the organisation from small business to global giant.

Book Peter today

Find out why he has earned the reputation for breakthrough business change.

In Action

Enthusiastic, knowledgeable
presenter and facilitator

Peter offers keynote presentations, full- and half-day workshops, and seminars to C-level executives, managers, and business owners across Australia and New Zealand.

He is as effective and high-impact in delivering his free-flowing presentations from the podium as he is in an interactive seminar setting.

Download Speaker Sheet


For more details on Peter’s keynotes, please contact us.
For participant reactions, click here.

Peter's Book

Accelerating performance in software development

Peter has codified his ideas on and experiences with the science of flow of work in software development environments in his new book Pace.

Pace presents a breakthrough process to reboot and scale software development with unprecedented speed and efficiency.

Critical reading for all software development teams.

NEW APPROACH

Peter's 12 Rules for Pace

Current software development practices — Sprints/SCRUM — are no longer keeping up with today’s software development environment.

Scaling performance requires a new approach: Pace.

Pace consists of 12 radical and counterintuitive rules and a set of decision-making tools that encourages rapid growth without sacrificing quality.

Bottleneck Rules

Every system has a bottleneck that limits the possible output of that system. Some software teams are organised linearly (work is passed along a chain of teams); in which case the bottleneck is one of those teams. Many software teams are self-organising (or at least seek to be), in this case there will be a person or function in this team which is the bottleneck.

  1. 1
    Ensure there is a steady supply of work for the bottleneck

    As the bottleneck controls our output, and time lost from the bottleneck is lost for the team, we ensure there is always work for the bottleneck to do.

  2. 2
    Offload the bottleneck from unnecessary tasks

    Any work that can be done by others is disbursed to them, freeing the bottleneck up to only do work they must do.

  3. 3
    Plan others’ work around the bottleneck

    The bottleneck’s work (including others work that requires the bottleneck) is planned first. Once it is planned, others work which does not interact with the bottleneck’s can be planned.

  4. 4
    Ensure quality inputs into the bottleneck

    To minimise the risk of bottleneck rework, extra quality steps are introduced immediately before the bottleneck.

Variation Rules

Software development is often highly variable in type and length. This makes planning and delivering work reliably difficult. Some variability is intrinsic to the type of work, for this we must ensure the teams are protected from normal variation such they can deliver consistently and at high quality.

  1. 5
    Ensure the bottleneck’s work is buffered

    Adding in a time buffer gives the team a shock absorber to their iterations, allowing for deviations from estimates without compromising agreed deliverables or quality.

  2. 6
    Make the passing of time visible

    The passage of time is visible against the state of completed work, shown as a percentage of the buffer that has been consumed. All team members can clearly see how likely the team is to complete the iteration on time at the current rate.

  3. 7
    Use an alternate response system

    There are set of actions that are reliable at ensuring iterations are delivered on time (without compromising quality) in each team. These are decided by the team and must be executed once the team hits a pre-determined risk point of buffer consumption.

  4. 8
    Buffer Logging

    Hits on the risk point of the buffer and their causes are logged. This list is used to address the frequent or systematic causes of variation within the team as a process of ongoing improvement.

Flow Rules

External variation has a high impact on the speed at which teams can complete iterations. To further accelerate the performance of the team we must limit the amount of work exposed to the impacts of external variation, as well as the team behaviours caused by due dates. The outcome is starting and completing iterations quickly and consistently.

  1. 9
    Smaller chunks of work

    The shorter the iteration, the less likely it is to be impacted by external variation before it is completed. Iteration based steps such as reviews also occur on smaller sections of work, more frequently, increasing quality. Iterations are planned to their true estimated length, not forced into a pre-planned timebox length.

  2. 10
    Use time buffers not deadlines

    As tasks are completed, new tasks flow to the team to be started. Tasks are managed on buffer consumption as their risk measure. There is no batching of iterations into time-boxes with due dates.

  3. 11
    Limit work in progress

    To reduce the time taken to complete an iteration we limit the window of tasks available to the team. This limits multitasking and reduces handover times. This allows us to have a well-balanced team where the most relevant task is available but resources are not overloaded.

  4. 12
    Have a relevant mix of tasks

    The mix of task types for the team is decided strategically. The next task to flow to the team to be started is the same type as the one completed. This provides predictable completion of work (for example features, bug fixes, customisations).

Testimonial

What others say

Contact Us

Book Peter for your next speaking event

Peter Cronin offers keynote presentations, workshops and article contributions to publications around the world. Please contact us to learn more.