software (2)


Software Delivery – Optimise for predictability or productivity?

This blog post was inspired by a recent work rant:

/Rant
It may be worth having a conversation around what a delivery plan is (and isn’t). Once the delivery-plan has been communicated, it will likely be out of date as we’re working in a unpredictable complex system (not an ordered predictable system). I hope we consider the delivery plan as an alignment tool which will constantly change as we learn, react & adapt (not as a stick for fixed dates/deliverables). If we need a guaranteed delivery plan and dates, then perhaps we need to use a different method of planning & delivery (perhaps Waterfall, with lots of buffer, contingency & lead times).
/End 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?




Peopleware: Productive Projects and Teams summary

Authors Tom DeMarco & Tim Lister

Peopleware - Productive Projects and Teams 

1.Managing the Human Resource

  • Don’t manage to the software vending machine mentality – standard operating processes, telling a technical team how to do the job, hiding the team from the underlying problem, prescribing solutions, leaving no room for learning or creativity etc.
  • Allow and encourage teams to make errors and learn.
  • Work a sustainable 40 hour week, nobody can continually work overtime, or sprint from the start to the finish on a long project without slowing down, or worse, burning out. Creative workers require rest to be at their maximum productivity during their work hours, and great knowledge workers spend time outside work learning about their trade and applying learned excellence back to their work.
  • “Quality, far beyond that required by the end user, is a means to higher productivity.”
  • “Quality is free, but only to those who are willing to pay heavily for it.”
  • Employees who are experts at designing, developing and delivering the said work should be the people who estimate and commit to it; “Programmers seem to be a bit more productive after they’ve done the estimate themselves, compared to cases in which the manager did it without even consulting them. When the two did the estimating together, the results tended to fall in between.”

2. The Office Environment

  • “There are a million ways to lose a work day, but not even a single way to get one back.”
  • “While this [10 to 1] productivity differential among programmers is understandable, there is also a 10 to 1 difference in productivity among software organizations.”
  • A study on developer performance showed workplaces with larger dedicated personal workspaces which are quiet, private and interruption free performed much better and showed a reduced defect rate
  • A study of development showed how developers spend their time:
    • Working alone 30%
    • Working with one other person 50%
    • Working with two or more people 20%
  • Working alone requires Flow Time –  a near meditative, uninterrupted state where time flows unconsciously and developers are at their most productive – work output flows. It takes time to get into the zone (15+ minutes) which is mostly unproductive time and nothing kills Flow Time like being interrupted (by a colleague, phone, email, instant message, loud noise etc) or having a workplace which doesn’t understand and design for Flow Time.
  • There is a simple forumula to work out if you’re environment is setup for Flow Time called Environment Factor (EF). An EF of ~40+% should allow developers enough flow time and enable enough time to work with others and in groups:
    • Environment-Factor  = Uninterrupted Hours / Body-Present Hours

3. The Right People

  • Peopleware formula:
    • Get the right people.
    • Make them happy so they don’t want to leave.
    • Turn them loose.
  • Leadership as a service; leaders are enablers of knowledge workers who in large can self-manage. A leaders job should be to foster and grow teams, networks and aim to attain goal alignment. “The manager’s function is not to make people work, but to make it possible for people to work”.
  • Employee turnover is very expensive. It generally costs about 4.5 to 5 months of total employee cost to replace an employee and takes approx. 3-5 months for the employee to become fully productive.

4. Growing Productive Teams

  • A jelled team, aligned behind a common goal with momentum can be unstoppable. “The purpose of a team is not goal attainment but goal alignment”. A jelled team is usually has a strong sense of identity, a name, a brand, a catch phrase and a good, well known reputation.
  • Teamicide is a list of things that will likely prevent team jelling:
    • Defensive management
    • Bureaucracy
    • Physical separation
    • Fragmentation of people’s time
    • Quality reduction of the product
    • Phony deadlines
    • Clique control
    • Motivational posters, plaques & accessories
    • Overtime & weekend work
    • Internal team competition, performance reviews  (stack ranking, manage by objective etc), excessive personal praise & rewards
  • Overtime & weekend work – “That negative impact can be substantial: error, burnout, accelerated turnover, and compensatory undertime.”
  • Full transparency, delegation with trust, support, a safe environment where failing & learning is rewarded and open dialog helps teams and organisations gain great outcomes; to be properly effective an organisation has to have this at all levels. “This Open Kimono attitude is the exact opposite of defensive management. You take no steps to defend yourself from the people you’ve put into positions of trust. And all the people under you are in positions of trust. A person you can’t trust with any autonomy is of no use to you.”
  • Great teams build networks and this are not driven through hierarchies; “The structure of a team is a network, not a hierarchy. For all the deference paid to the concept of leadership (a cult word in our industry), it just doesn’t have much place here.”

5. Fertile Soil

  • Organisations tend to focus too much on certified methodologies rather than trusting its knowledge workers to setup systems and processes best placed for their work at hand;  “There is a big difference between Methodology and methodology. Small m methodology is a basic approach one takes to getting a job done. It doesn’t reside in a fat book, but rather inside the heads of the people carrying out the work. Big M Methodology is an attempt to centralize thinking. All meaningful decisions are made by the Methodology builders, not by the staff assigned to do the work.”
  • “Voluminous documentation is part of the problem, not part of the solution.” Big M methodologies often lead to:
    • A morass of paperwork
    • A paucity of methods
    • An absence of responsibility
    • A general loss of motivation
  • Better ways to achieve convergence of method are:
    • Training
    • Tools
    • Peer Review
  • Risk management within organisations is often seen in two extremes; non-managed, or managed so strongly risk adverse as to accomplish nothing of greats, transformational value; “The Peopleware premise—our main problems are more likely to be socio- logical than technological in nature—applies nowhere more strongly than in the area of risk”. “The risk we tend not to manage is the risk of our own failure.”
  • “The ultimate management sin is wasting people’s time.”
  • Starting projects with a full team – early overstaffing, rather than a slow ramp up during the start of a project planning & design phase most often wastes time and money
  • The cost of creating and consuming email should not be underestimated. Where possible avoid sending out corporate spam and grow a self-organising and coordinating culture without needing email as a centralised coordinating function.
  • “Experience gets turned into learning when an organization alters itself to take account of what experience has shown. Learning is limited by an organization’s ability to keep its people.”
  • Middle management is often the first to get downsized and can often have a direct and significant impact on organisational memory and the ability for an organisation to learn – “successful learning organizations are always characterized by strong middle management.”. To maximise organisation learning, middle management must work closely with each other in effective harmony, avoid bureaucracy, silos, have common aligned goals, have clear communication lines and frequent interaction. Ensuring management are operating as an effective team is critical.
  • Aristotle’s five interlinked Noble Sciences that together make up Philosophy:
    • Metaphysics: the study of existence, the nature of the universe and all its contents
    • Logic: the ways we may know something, the set of permissible conclusions we may draw based on our perceptions, and some sensible rules of deduction and inference
    • Ethics: what we know about man and what we may deduce and infer (through Logic) about acceptable interactions between pairs of individuals
    • Politics: how we may logically extend Ethics to the larger group – humans and the community made up of humans
    • Aesthetics: the appreciation of symbols and images of metaphysical reality
  • Fostering and environment where community and culture grows is one of the most important roles of managers and leaders

Meetings

  • Some organisations have a culture of meetings, which are considered more important than work and other organisations have an extreme no-meeting culture – you need to meet somewhere in the middle. As organisation age, their meetings tend to get more frequent, and longer.
  • Some dysfunctions of a meeting:
    • People in attendance but not present (ie using technology) or engaged – perhaps because they’re not getting value
    • Inviting more people than needs to be present to make a decision. Fewer people the better and meeting costs should be calculated – “The cost of the meeting is directly proportional to the number attending.”.
    • “A meeting that is ended by a clock is a ceremony”. A meeting where no decisions are necessarily made, and where most of the conversation is conducted between two-people (ie the boss and round-robin people speaking) with other attendees siting idle can be considered a status-update / FYI meeting and considered a waste of peoples time – can be replaced by one-on-ones.
  • The very nature of working meetings are ad-hoc and called when necessarily to reach a decision; a frequent, reoccurring meeting is normally a status meeting – “The need that was being served was not the boss’s need for information, but for reassurance”.
  • Start each meeting with an outcome in mind and the question – “What ends this meeting?”. Once the meeting has achieved its goal, end the meeting promptly.

Change Management

  • The hardest pert of change management is dealing with people (not necessarily technology) – “The fundamental response to change is not logical, but emotional.”
  • Different personas to change (increasing in resistance):
    • Blindly Loyal (Ask no questions.)
    • Believers but Questioners:
      1. Skeptics (“Show me.”)
      2. Passive Observers (“What’s in it for me?”)
      3. Opposed (Fear of Change)
      4. Opposed (Fear of Loss of Power)
    • Militantly Opposed (Will Undermine and Destroy)
  • Celebrate and acknowledge our old ways of working as enabling this new change
  • “You can never improve if you can’t change at all.”
  • Change involves are the very least 4 stages and two key events:
    • Old Status Quo –> [foreign element / event, catalyst for change]
    • Chaos –> [transforming idea / event]
    • Practice and Integration
    • New Status Quo
  • Often with new changes you’ll go through a learning curve and dip in performance, before mastering the new ways and (hopefully) improving
  • “Change won’t even get started unless people feel safe—and people feel safe when they know they will not be demeaned or degraded for proposing a change, or trying to get through one.”

6. It’s Supposed to Be Fun to Work Here

  • Work should be fun, introducing some chaos into the mix can help with empowerment, ownership, innovation, boosting productivity, enable team-work, help with change management and introduce novelty. It can be done via:
    • Pilot projects
    • War games
    • Brainstorming
    • Provocative training experiences
    • Hack-days / Hackathons
    • Training, trips, conferences, celebrations, and retreats
  • When brainstorming, encourage quantity over quality – sometimes the sillier the idea the better. As idea generation slows, you can try the following strategies:
    • Analogy thinking (How does nature solve this or some similar problem?)
    • Inversion (How might we achieve the opposite of our goal?)
    • Immersion (How might you project yourself into the problem?)

You can review and purchase Peopleware: Productive Projects and Teams on Amazon.com.au.