Ian Berry IT Blog

This blog post was inspired by a recent work rant:

Often when delivering software we have two competing interests; being predictable in delivery (i.e. hitting targets / deadlines) vs. maximising productivity (delivering valuable output). For this article we’ll define predictability as ‘delivering software features on time, to budget and to an acceptable level of quality’ and define productivity as ‘maximising value-add features, maximising learning and minimising waste’. From experience these two concepts can be opposing and depending on the type of work at hand can land your initiative in a different place on the scale below in figure 1.

Figure 1. Predictability vs. Productivity in software delivery

Often the more predictable a team needs to be, the less actual value adding work (or validated learning) it will produce, and will often partake in poor processes and generate low-to-no value-add artefacts. My hypothesis is if two independent teams were to solve the same problem, within the same environment, with the same constraints and technical stacks etc (i.e. identical space), the team choosing to be more predictable would be between 10% to 40% less productive. The more predicable team would spend more time on upfront analysis, design, architecture, upfront spikes on unknown areas, more time breaking down work into detailed tasks, estimating & planning. They would then likely deliver in larger batches and have longer release cycles, but the team would hit delivery targets, budgets and be predictable – happy days (or so we think)!

I suspect the more productive team would be less predictable, most likely starting by completing a high level delivery plan upfront (i.e. a mud map), identify dependencies with long lead times (early on), look to attack hidden complexities through working software and be constantly evolving their delivery plans, budgets and forecasts. The more productive team would spend less time producing upfront artefacts such as business requirement documents (BRDs), solution architecture documents (SADs), detailed work breakdown structures, detailed delivery plans & budgets, but would plan to deliver the smallest vertical increment of working software, and continue to iterate and build based on rapid feedback from the environment. Valuable working software would provide the best feedback, documentation and risk reduction and any artefacts required such as architecture diagrams, user documentation etc would be produced just in time. The team would frequently evolve the delivery plan based on historic velocity with just enough detail to communicate dependencies, ensure alignment, communicate actual & forecasted dollar burn-rate and set/reset delivery expectations as value is realised and the ecosystem changes.

Methods of Software Delivery

The Waterfall method is an extreme example of large up-front effort with little to no early value and long lead times, Scrum introduced time-boxed, value adding increments and lands in the middle of Predictability vs. Productivity scale and Lean / Kanban method is an example of a fluid, flow based delivery method as seen in figure 2.

Figure 2. Schedule based vs Flow based software delivery methods

Extreme caution should be used when moving too much towards big up front delivery planning (such as the Waterfall method) where there is a need to try to understand and solve all problems at the start of a project, as highlighted in the 2015 Standish Chaos report smaller projects have a much higher chance of success, and in all project sizes Agile methods delivered success 39% of the time (challenged 52%, failed 9%), compared to Waterfall which delivered success 11% of the time (challenged 60%, failed 29%) . Ignoring Waterfall, the predictable team above may choose the Scrum methodology and assuming a 7 person delivery team, two week sprint and a 40 hour work week we see the following time spent on Scrum rituals per team member:

• 15m daily standup
• 4hr backlog grooming, story breakdown & estimation
• 1hr sprint planning
• 1hr showcase
• 1hr retrospective

Total of: 9.5 hours per sprint or 12% of sprint time per team member
Total of : 66.5 hours of team time per sprint

Spending time breaking down the backlog into smaller backlog items, discussing visual and technical designs, teasing out complexity & dependencies, poker-planning and thinking about execution are very valuable activities which lead to higher confidence levels and better predictability. With a little bit more work relatively-estimating the delivery backlog, some historic velocity and some contingency built in, the predictable team can now forecast delivery in the 2-3 month window with a level of confidence.

The productive team may feel spending 12% of their time on rituals as heavy and would look to spend minimal time on overheads. As work comes in and is prioritised, the team would break work down into small (similar sized) items and tackle the next most important issue, continuously deploying value and seeking feedback. They would likely spend less time breaking down work and planning, and more time doing and assessing the results; more of a continual flow based method. Often the flow-based delivery teams are good at forecasting days-to-a-week of work, but not great at forecasting weeks-to-months of work, and are often less predictable than a typical Scrum team, but arguable more productive.

The culture of the productive team is likely to be more focused on being brave, attacking problems, compelled to action, taking calculated risks, rewarding failure & learning cycles, supporting each other and focused on getting things done whilst the predictable team will likely play it more safe, be more risk adverse, compelled to analysis and more focused on delivering to expectations rather than striving for stretch goals. The culture of the team and the broader ecosystem the team operates within is a major influencer on the teams ethos; to be predictable or to be productive.

The above example indicates both extremes of the predictability vs. productivity, there are many different considerations when choosing where to land on the scale and my hypothesis above assumes a certain context & problem; however many things needs to be considered such as:

The type of work at hand – is it well known, repeatable, complex or unknown?

Following the Cynefix framework, where does your work or ecosystem fit?

Are you operating in business as usual mode (BAU) of an established well understood application?

Are you building a new application from scratch and don’t fully understand the customer problem or domain?

Are you working on a pure innovation front, or with bleeding edge technology?

The team & individuals

How experienced are the team within the current ecosystem and technology?

How much career & technology experience does each team member have; graduate, junior, mid or senior?

How much cumulative experience does the team have (a team full of graduates, mid-tier developers or senior specialists or a good mix of all)?

Do you have an established, battle hardened team, or a newly forming team (going through Tuckman’s forming, storming, norming performing phases)?

The size of the feature, application or system

Are you building a small increment to an existing application or are you building an entire business support system?

Are you modifying a standalone feature, or a full customer or business workflow?

Are you building for a local market, or one that spans across language, time and culture?

The surrounding ecosystem of the feature, application or system

Are you working in a startup, trying to find customers, or in an established and highly regulated industry such as banking or insurance?

Do you have millions of customers on a legacy platform?

Do you have full freedom of ways of working to define your own processes, or are you bound to an existing corporate environment?

How much lead time does the business need for change management and go to market activities?

How many up-stream or down-stream dependencies do you have, and what are their lead times?

How easy is it to make a change in your ecosystem, how much effort is required to handle changes to an upfront plan?

The initiative, project or program of work in play

Are you working on a single, isolated system with limited dependencies or part of a complex, interconnected large ecosystem?

Are other teams and systems dependent on the work you’re producing to deliver on a program of work?

How many people are involved in the initiative, project or program of work – one team of 5 people, 15 teams and 150 people or hundreds of teams and thousands of people?

The lifespan of the feature, application or system

Following the lifespan of an feature, application or system by Kent Beck – Explore, Expand, Extract & Extinct

Is this feature a learning and innovative piece of work (i.e Explore) and needing extreme productivity and validated learning cycles?

Is this application or system scaling up and expanding (i.e Expand) and needing to overcome technical, system, process & people limitations?

Is this feature being delivered to an existing large customer base (i.e. Extract) where predictability and profitability are key drivers?

Is this feature, application or system being delivered at end of life (i.e. Extinct), hard to coordinate & expensive to change?

All problems are inherently different

Experience has taught me there’s often more than one way to solve a problem, each having a unique context & ecosystem; one size never fits all. Like most things in life, to move forward some trade-offs are likely required and most teams will find themselves somewhere in the middle of the scale, doing enough work to be predictable, without suffering significant productivity loses.

Where do you fit on the scale of predictability vs productivity?
What are your unique needs?
How fast do you want to go?
How predictable do you want to be?