Wednesday, 17 January 2018

The UI that broke Hawaii

Does anyone need reminding that design is more than pretty colours? Apparently they do. Here’s the web-app screen that sent an SMS to some 1 to 1.5 million Hawaiians, that a ballistic missile was headed their way.

Emergency SMS control screen

At least bad data design didn’t kill anyone this time *. I hope.

* This is awfully reminiscent of the powerpoint slide at NASA that should have, but didn’t, warn of the likelihood of the Space Shuttle Columbia disaster.

What’s wrong with that screen?

Let’s count the problems.

  1. It’s heavy with acronyms and jargon that make it hard to understand the links
  2. The items aren’t in any meaningful order
  3. High-safety critical items (Tsunami Warning) are mixed with convenience items (road closure notification) and tests
  4. Heavy use of capitals means the emphasis on DRILL does not stand out
  5. Inconsistent language – there are three test options, all indicated with different phrases:
    • “DRILL” (at the start)
    • “DEMO TEST” (at the end and)
    • “1. TEST Message” (the whole line)

This adds up to a screen with heavy cognitive load to perform a basically simple but safety-critical task. It is inviting an error, and it is a serious failure of the team that commissioned, accepted and manages the software, and the team that built it.

I hope lessons are learnt in the right place, and it’s not the operator who suffers.

How would I change it?

Since I’m carping, I should be clear what I would do differently here. I want to remedy a couple of those faults listed above:

  1. Ditch the acronyms and the jargon. “High Surf Warning North Shores” is perfect. PACOM should say “Incoming Missile Warning”.
  2. Order the items, in a way that makes sense to the operators. Alphabetical would be a good start.
  3. Make a crystal-clear design distinction between high-criticality links, low-criticality links and test actions.

Why haven’t I touched the issues of CAPITALS or of inconsistent language? I want to get the design fix right first (point 3):

  1. Place options for Test, Info and Emergency on different screens, or clearly marked sections on the same screen
  2. Make Test the easiest option to pick (least deliberate) and Emergency the hardest (most deliberate)

Get this right – create utter clarity between Incoming Missile Warning and Incoming Missile Warning Drill – and those other points shouldn’t matter nearly so much.

Excuses, excuses. This means YOU!

So you don’t work on safety-critical systems? Me neither. This still applies to both of us.

At one time in my career I’d say “But a user wouldn’t do that.” Or “A user shouldn’t do that.” Why would they? It’s stupid. It doesn’t make sense. Obviously it will break the system.

So here’s the heads-up. Sooner or later your users will,/b> do that. Why? Because they’re in a hurry. Because they’re overworked. Because their partner yelled at them this morning. Or just because they’re trying to do their job, the best they can, with a limited view of a complex system.

We the Dev team, are the ones with the full context. We’re the ones tasked with thinking through the workflows – the exceptions as well as the happy path. We’re the ones who need to make the right thing easy and the wrong thing damn near impossible.

And it’s everyone’s responsibility – Devs, Testers, Product Owners and Scrum Masters – whether or not we have a Designer on the team.

A case study

My last product was a lead generation tool for fund managers, including the custom CMS, managing a complex relational content model. We provided content editors with a delete button on content items. What about content items with dependencies?

3 options:

  1. Leave it – the content team is responsible for content integrity
  2. Remove the delete button if there are content dependencies
  3. Make the delete button do...something else

1. is the attitude I used to take. A content editor would daft to delete an Investor with a Mandate hanging off it. But you know it’s going to happen, the very first time they’re in a hurry to clean out an old record.

This is the attitude behind the Hawaii screen.

2. is more helpful. But it leaves users wondering why that delete button is missing. This way, bug reports lie!

We went for 3. The delete button is still there, but instead of deleting the item it opens a dialog with an explanation and a list of links to the dependencies that need to be fixed. It makes the wrong thing impossible, and the right thing as easy as possible.

Coda. A fix for Hawaii

In the wake of the incident, the relevant agency has issued a software update:

Emergency SMS control screen, showing False Alarm option

There it is at the top of the list, a BMD False Alarm option! Granted we’ve seen that this is necessary, but it only adds to the shortcomings listed above:

  1. More acronyms
  2. Still not in a meaningful order
  3. A whole SMS new category mixed up with the ones already there
  4. More capital letters

And a whole new problem. There’s no way to tell from this screen which SMS warnings the False Alarm applies to. Just the missile alert? Whatever was the last message sent? What does this link do if the last message was a Test? Or was sent three months ago?

Without fixing the underlying design failures, they’ve actually made this screen worse not better.

In anticipation of the next inevitable accident,

Thursday, 4 January 2018

So your Product Owner doesn't like paying off Tech Debt?

No Product Owner likes paying off tech debt. It looks suspiciously like the Devs messing around with perfection when the product is already working. The team could be building me new features dammit!

Tech debt is a pretty abstract concept to people without a coding background. We want to communicate it in a way that explains the value to the PO, in terms that are meaningful to them. Here are two approaches – one that I've used before and that worked, and another that I mean to try next time.

Tried and tested – the car service

If you drive a car, you get it serviced every year. It's painful because (a) it's expensive and (b) your car's still running. Yes you could drive it to Birmingham next week without getting it serviced. And the week after. And the week after that. But it will keep getting a bit slower and a bit more expensive to run, until one day it stops. And it won't stop gently on a day that doesn't matter – it will stop hard on the motorway when you have to get to Birmingham in a hurry. Because that's when you're stressing it hardest.

Your codebase is just the same. Sure you can put off paying off tech debt, because it's still running. But dev work that should be easy will get slower and more expensive, until one day you can't go any further.

If your PO wants to keep driving, they've got to service the car. Otherwise expect it to come to a screeching halt just when it matters the most.

Next time – revenue protection

Product Management types understand two broad categories of project:

  • Revenue generation
  • Revenue protection

They prefer revenue generation projects. Everyone does – they're sexy and pay all our bills. But they understand the need for revenue protection as well.

Paying off tech debt is revenue protection for the workstream. Or maybe velocity protection. Without it, once again work will slow down until it can't go any further.

Can we avoid this in the first place?

Of course it's better if you can avoid having to commit time to paying off tech debt. In a steady-state business-as-usual workstream with frequent releases, ideally the team refactors the code as you go to avoid getting into this situation at all.

However sometimes you have to accrue tech debt – eg there's a cost-of-delay driving an MVP release. Or you'll discover it some time later. When that happens, you'll want to convince your PO to give it appropriate priority.


Thursday, 21 December 2017

SAFe - a second opinion

I had a brief introduction to SAFe at a conference back in 2015. The session focused very much on how in SAFe 100-plus participants come together every 8 to 12 weeks to plan their next delivery commitment. I was not impressed. This to me was the antithesis of Agile.

This week I sat the Leading SAFe course. Was my second opinion any different?

Summary: SAFe does something Very Very Good, something Somewhat Less Good, and something Deeply Troubling.

But first...

What is SAFe for?

The Scaled Agile Framework (SAFe) is for large teams, typically more than 50 individuals, working on a single software solution.

eg 1. One of the course participants was working on a European national train operator's programme to replace their entire ticketing and reservations system. 300+ people, most of them developers, working on a single programme at the same time. (I probably wouldn't structure it like that, but apparently it's working for them.)

eg 2. The trainer has acted as SAFe Programme Consultant on a military system. I don't know which one, but you can easily imagine that a programme to overhaul the systems on the Eurofighter Typhoon might take a dozen software teams several years.

The Very Very Good

In my first encounter with SAFe I was deeply unimpressed with Programme Increment Planning: a 2 week conference, every 8-10 weeks, involving every member of the extended team committing to typically 4 Sprints' work.

Well, I changed my mind.

If we accept that working at scale is something that some programmes just have to do, they are inevitably going to lose a degree of Agility. Can't have Team 1 pivoting when they're working on the same solution as Team 10, or ignoring a dependency from Team 7.

PI Planning is actually a really well designed way to get the teams collaborating. Some key features indicate the genuinely as-Agile-as-possible flavour:

  • Teams plan their own work, based on their velocity
  • Face-to-face discussions between developers across the organisation, to deal with dependencies, ambiguities etc
  • Commitment to Objectives for the upcoming Sprints, not specific User Stories
  • An explicit understanding that the teams' User Stories and plans will change during the forthcoming Sprints (Sprints. Does that sound very Scrummy? More on that below...)
  • A confidence vote towards the end, with an opportunity for team members to raise doubts, risks and concerns

SAFe appears to take de-centralised decision-making, respect for and autonomy of individual team members very seriously. Bringing 100 people together for two days is expensive. But if you're going to have them working on the same overall effort, giving them the opportunity to work directly together every couple of months is a pretty damn good start!

The Somewhat Less Good

So SAFe provides a great way for multiple Agile teams to work together – 10/10. SAFe also has something to say about how those individual teams operate. Actually, SAFe has lots to say about how those individual teams operate.

  • All Scrum teams operate to the same cadence, with Sprints starting and finishing on the same day
  • Teams can operate something other than Scrum (probably Kanban), but they have to deliver to the same cadence anyway
  • Lots and lots of guidance about specific practices: WSJF prioritisation, Lean UX, Story Point estimation and plenty more

SAFE derives these all from their 9 Principles. They're all good principles and it's all good advice – some of the best stuff from the last 2 decades of Agile exploration. But we're moving away from Individuals and interactions over processes and tools (Agile Value #1 for anyone who's forgotten), and replacing it with yet another One True Way.

Look, I understand that SAFe are selling into large enterprises. Some of them don't have any Agile implementation at all and need some guidance, and it is good guidance. (Plus large corporates like uniformity.) But yet another method from the ground up isn't what SAFe excels at and isn't what the Agile community needs. It just seems unnecessary.

The Deeply Troubling

Story Points. Are great. I. Am. Not. Going. To. Sell. Them. To. You. (not here anyway)

Critically, a team comes to their own feel for how User Stories scale for them. Except in SAFe. In SAFe, teams are encouraged to normalise their Story Points: a 3 in my team should mean the same as a 3 in yours. This breaks the cognitive basis of Story Point estimation and the trust put in the team to engage with it. And that should be all I need to say.

It gets worse.

The reason to encourage uniform story-point scaling is so that Product Managers can estimate the sizes of Epics, without consulting the people who will be doing the work, to determine prioritisation and funding. Yes, we're back to software decision-making based on management estimates.

And once more I understand why they've done it. SAFe scales all the way up to Enterprise Portfolio level, and they want to offer a way for senior budget holders to approve pieces of work that could consume many thousands of developer days. And sure it could be done well. But I'm willing to bet that once the SAFe Programme Consultant goes home, these Product Manager estimates rapidly become personal commitments, translated into direct pressure on all those delvelopers or else...

This only exacerbated by the scale of these Epics, reasonably in the range of 1000s of Story Points. A software organisation going through the detail of Programme Increment Planning might be able to come to a reasonable estimate at this scale. For a Product Manager, it can't be anything but a guess.


  • If you have to structure a software programme with 50+ developers, SAFe offers a great Agile way to plan and deliver at scale. Yes there's a sacrifice of agility here, but it's a cost of operating at scale.
  • SAFe also offers its own approach to Agile delivery. This may be a useful starting point for enterprises new to Agile. For experienced practitioners, it may just be overly restrictive.
  • SAFe's use of Story Points should be treated with a great deal of caution. IMO it's a reversion to a damaging pre-Agile mode.

Like any other Agile method, I recommend you take what works for you and leave the rest.


Friday, 13 March 2015

I love Scrum / I hate Scrum

Scrum is a wonderful Agile method with a huge amount to commend it. And Scrum is a liability for the Agile paradigm.

Why I love Scrum

There’s no doubt at all that Scrum is a fantastic Agile method. Not the be all and end all, but just look at the tools it’s given us:

  • Short iterations
  • Retrospectives
  • Project Manager as Servant Leader
  • Burndown
  • Prioritised backlog

These alone should cement its place in Agile thinking.

Scrum also provides a consistent, compelling and simple model (single Product Owner, no external dependencies) that makes it a powerful sell to teams. Inspect and Adapt at all levels:

  • Inspect and Adapt your product: Sprint Reviews
  • Inspect and Adapt your process: Retrospectives
  • Inspect and Adapt your daily progress: morning Scrum
  • Even the backlog and its user stories undergo revision in the light of ongoing work

Scrum has also had excellent marketing. A host of user-friendly terms - Scrum, Scrum Master, Backlog, Product Owner, Sprint &c. And in selling training, the Scrum Alliance and continue to spread Agile understanding and uptake.

These have all made Scrum a fantastic first step into Agile for new teams. It remains the backbone of my Agile practice (and I suspect many of ours) even when I want to mix-and-match with tools from other methods.

There’s an awful lot to love in Scrum.

Why I hate Scrum

Agile is bigger than Scrum

I met a senior manager this week who worried that Agile’s insistence on a single Product Owner simply didn’t fit the realities of his business. This isn’t a feature of Agile at all - it’s specifically a feature of Scrum.

Of course this is a downside of that marketing I was praising a minute ago. And this confusion reaches its nadir in job advertising:

Project Manager with Agile/SCRUM

ugh! Agile isn’t Scrum. And Scrum isn’t SCRUM.

Scrum is bigger than Sprints

I used to think the major emblem of Scrum, and of Agile more generally was the whiteboard of post-its. I was wrong. For many, the entire Agile movement boils down to Sprints.

As in

“We work in Sprints.”


“We blend Waterfall and Agile (because we work in Sprints).”

Like many of us, I’ve worked in a company that sold fixed time/scope/cost projects (yes all three) for their developers to deliver in an ‘Agile’ fashion by splitting the work into ‘Sprints’. Of course it wasn’t Agile and it wasn’t Scrum.

I really want to repeat that. Not. Agile.

Splitting fixed-specification work into short delivery periods is pure waterfall incremental delivery. They’re not even Sprints. Sprint is a Scrum-specific term for an iteration, so they’re only meaningfully Sprints if:

  • They start with collaborative Planning
  • They end with Review and Retrospective
  • The backlog is open to review and is expected to change
  • You build change into your expectations, without onerous Change Control or contractual penalties

Unfortunately companies doing this think they’re already Agile. It limits their own ability to embrace genuine Agile change, and brings the entire paradigm into disrepute.

The upshot

The marketing genius behind Scrum is both a benefit and a hazard. Scrum practices are and remain an invaluable contribution to the Agile space, and it is many practitioners’ first bite at Agile. At the same time, Scrum terminology has become debased by buzzword abuse that threatens broader Agile uptake.

If I had my way I’d abandon all those cool Scrum words. Make a clean break - save the great practices and leave the language to the buzzword cowboys. Iteration and timebox would be perfectly good plain-English alternatives for Sprint. (There are other good reasons for a language change - perhaps for another post.) Of course a wholesale language change isn’t exactly my decision to make ;)

That aside, I can only make a few recommendations:

  • Challenge assumptions that Agile = Scrum. If it’s something you yourself believe, learn about Kanban or DSDM or one of the other Agile methods. Expand your practice and your toolset.
  • Use Scrum and Sprint only when you’re genuinely employing Scrum practices.
  • When you find a Waterfall house that believes it’s Agile, gently work with them to to introduce genuine Agile change. And let me know how you did it and how it went!


Thursday, 26 February 2015

Dual-Track Scrum and the Waterfall Monsters

I was recently introduced to Dual-Track Scrum / Dual-Track Agile at a presentation by the Head of Product at a major high-street brand. It scared the willies out of me that he could describe his process as Agile. More on that later. First...

The challenge

A perennial difficulty for Agile teams: how to combine design with delivery.

  • You often need a degree of design before implementing in code
  • UX specialists often want to work to a very different cadence from developers, being less inclined to break their work into separable chunks

Some teams have difficulty resolving this within a Sprint. Some solve it by UX working 'a Sprint ahead'. It's not a difficulty that I've particularly experienced with Agile teams.

Another challenge: backlog items that are insufficiently understood or not 'validated', leading to protracted planning sessions where the team tries to understand the story, or expensive validation in code instead of cheap paper testing.

This too is a difficulty that I've not encountered.

Cue Dual-Track Scrum.

Discover / Deliver

Dual-Track Scrum addresses both of these by splitting the multi-disciplinary team into two: Discovery and Delivery.

The Discovery track clusters around the Product Owner. It may include BA, UX, technical representation (perhaps a designated lead engineer) and potentially QA. This track develops the Product Owner's ideas into feasible user stories and designs. At the end of their sprint they hand the designs to the Delivery track for implementation in the next sprint.

The Delivery track implements the Discovery track's specifications. They might then hand them back for QA a sprint later.

Why this makes me shudder

Let's look back at the first point of Agile manifesto:

Individuals and interactions over processes and tools

Dual-Track privileges inter-disciplinary interaction between members of the Discovery track, and subordinates the Delivery track. While it subtracts interaction, it adds process. It limits the ability of the experts on the Delivery track - the people with the bread-and-butter experience of actually building the thing - to feed their insight into the designs they're being asked told to implement.

To emphasise the point, Dual-Track also runs against the third point of the Agile manifesto:

Customer collaboration over contract negotiation

Each design that is passed over the wall from Discovery to Delivery is a mini-contract. We've 'validated' this. The lead engineer has signed it off for implementation. Now build it. Dual-Track is starting to look like a step back towards process and waterfall - even more so if Delivery hand the code back to Discovery a sprint later for QA.

Of course we try to be pragmatic rather than purist. If we lack effective tools to overcome those two challenges, perhaps Dual-Track is worth it.

We already have the tools

Back when I started Scrum, our whiteboard had two ticket states: Not Done and Done. Then the Kanban guys encouraged us to visualise our workflow, the INVEST mnemonic prompted us to make our tickets smaller, and our boards started to look rather different: Backlog / Design / Dev / Test / ...

Sure some up-front design is still required. By the same token there will almost always be some up-front dev: databases, environments, architecture, or spiking to discover the domain. This is not wasted time - it's the business of creating a high-functioning team.

Last time I facilitated a team on this basis, the devs came back with a familiar difficulty in the very first retrospective: designs that were unnecessarily difficult to implement. There and then the team agreed to have a quick multi-disciplinary conversation around the emerging designs straight after each stand-up. It served us for the next three months, to the end of the project.

Thats the second great tool. Inclusive, ongoing conversation. Or in terms of the Agile manifesto again: Individuals and interactions over processes and tools.

I'm not saying that Dual-Track is never a useful or appropriate tool. But if you have the problems that it's designed to solve, perhaps try some core Agile techniques first:

  • Visualise your workflow
  • Small, Independent, individually Valuable user stories
  • Conversation, Conversation and more Conversation

Lord knows this is lower impact than slitting your team in two.

Dual-track goes pathological

If my concern is that Dual-Track is process-heavy, it was rammed home in that presentation I was talking about. Head of Product. High-street brand. 150-head Agile Centre of Excellence!!!

Their Dual-Track process sports:

  • Multi-sprint Discovery, with multiple stages for each feature
  • Yes he really called them stages - straight outta PRINCE2
  • Finished designs handed to the Delivery team for implementation
  • Multi-sprint stages in Delivery
  • In fact so many stages that he couldn't fit them all on one slide
  • Designs that never make it to Live, simply because the pipeline is so long that they're no longer relevant when they get to the end
  • Tweaks to features on Live that have to go back to Visualisation, the very first stage of the Discovery track

He described the process as "Agile" and "Lean", with the tagline "Speed leads to perfection". Yet it's a perfect picture of Big Design Up Front and Winston Royce's original description of Waterfall, complete with features that never make it into production!

From Winston Royce's 1970 paper Managing the Development of Large Software Systems. It starts with a fantastic description of the problem that really is a must-read. His solution - lots more documentation - not so much...

Dual-Track may be a valuable tool in the hands of practitioners with a genuine commitment to Agile values. Clearly it holds appeal for some who understand Agile and Lean as buzzwords, but have an instinctive bent towards Waterfall and heavy process.

Beware snake-oil salesmen.

Tuesday, 18 November 2014

Cynefin Complexity - a new perspective on old Wickedness

The Cynefin Framework overlaps with earlier work on Wicked problems. Both have things to say about sophisticated software development, and both point towards agile techniques for delivery. DSDM seems to have a trick up its sleeve to meet the challenges of wicked problems.

Something New

The Cynefin Framework
The Cynefin Framework - wikimedia commons

In the past couple of years Dave Snowden’s Cynefin Framework has captured imaginations in the software industry. Snowden proposes that problems and activities exist in one of several domains through which they can be better understood: Simple, Complicated, Complex and Chaotic:

I'm not going to go into the framework in any great detail here. You can find out all about it on Wikipedia, on Snowden's own company, or all over the web.

Snowden recommends operating in the Complicated and Complex domains, and some commentators have suggested that this is the natural mode of software product development. Day-to-day coding sits largely in the Complicated domain, which requires specialists who can apply acquired expertise and perceive Good Practice solutions. Product and project thinking sit in the Complex domain: we make a small change, understand its effect on the product and on users, and modify our plans accordingly. It’s a nice characterisation of agile approaches.

Something Old

Wicked problems were first characterised in the late ‘60s and early ‘70s:

  1. The problem is not understood until after the formulation of a solution.
  2. Wicked problems have no stopping rule.
  3. Solutions to wicked problems are not right or wrong.
  4. Every wicked problem is essentially novel and unique.
  5. Every solution to a wicked problem is a 'one shot operation.'
  6. Wicked problems have no given alternative solutions.

This is a great description of software dev:

The problem is not understood until after the formulation of a solution.
The delivery process explores its own requirements, and invariably exposes complexities that the client hadn’t considered.
Wicked problems have no stopping rule.
There is such a thing as too little development and too much, and often a large grey zone around 'just right'.
Solutions to wicked problems are not right or wrong.
Any business requirement has multiple legitimate solutions. Some will be better than others.
Every wicked problem is essentially novel and unique.
Otherwise an off-the-shelf solution would already exist and the work would be unnecessary.
Every solution to a wicked problem is a 'one shot operation.'
If we fail, (as an internal team or a contracted consultancy) the client won’t have the money or the time to try again. And if they do, it certainly won’t be with us!
Wicked problems have no given alternative solutions.
No off-the-shelf solution.

A Cynefin perspective on wicked problems

It feels like Snowden’s Complicated/Complex boundary has things to say about wicked problems:

The problem is not understood until after the formulation of a solution.
Emergent characteristics of the Complex domain.
Wicked problems have no stopping rule.
Probe - Sense - Respond applied to stopping as well as to continuing.
Solutions to wicked problems are not right or wrong.
Beyond the domain of Best Practice, into Good Practice and Emergent Practice.
Every wicked problem is essentially novel and unique.
Hence the need to Probe - Sense - Respond.
Every solution to a wicked problem is a 'one shot operation.'
Big Design Up Front is dangerous - again why we prefer to Probe - Sense - Respond.
Wicked problems have no given alternative solutions.
Hence no established Best Practice.

A new representation of old observations can be fruitful - Mendeleev’s arrangement of the periodic table is a classic example. I generally find Cynefin frustratingly vague, and Wicked problems provide it with a concrete context that I can understand. The Probe - Sense - Respond approach partially dismantles Wicked Challenge 1 (problem not understood until after the solution) and Challenge 5 (one-shot operation). Of course this is part if the core of the Agile paradigm.

Cynefin also nicely characterises what clients hire consultancies for. Simple problems they can manage by themselves. The Complicated and Complex domains encompass activity where specialists can add expertise and value. Even the Chaotic domain has value for innovation spikes.

Wicked projects and DSDM

Agile approaches meet Wicked Challenges 2-6 very well. They generally address Challenge 1 only in iteration - The problem is not understood until after the formulation of a solution. This is fine for ongoing product development, but perhaps insufficient for projects with a discrete start (and end).

Waterfall methodologies have a partial solution. PRINCE2 has an Initiation Stage with a go/no-go gate preceding full delivery. At the end of this, the team should have given due consideration to the problem space and to alternative solutions. But PRINCE2's up-front approach to planning, with an expectation of minimal engagement, makes it fragile to unexpected change. It doesn’t Probe - Sense - Respond.

DSDM has a nice trick here - an agile method with an 'Enough Design Up Front' mentality. It directly addresses Wicked Challenge 1 with explicit Feasability and Foundations phases. At the same time, its principles of ongoing client collaboration, iterative delivery and flexible, prioritised scope retain the responsiveness required in the Complex domain.

Wicked problems and #noprojects

In my previous post I suggested that there are three equally legitimate modes of software development: projects, product dev (which I aligned with #noprojects) and support. How do these modes support Wicked problems?

When clients hire consultancies, it is almost inevitably project work. A start date, a fixed budget and therefore an end date. We'd better hope then that projects can satisfactorily address them - I've made a case above that by combining up-front preparation with ongoing agility, they can.

Product dev teams operating in the #noprojects mould are ideally placed to engage with Wicked problems. On the ground on an ongoing basis, they can continue to Probe - Sense - Respond and keep improving the solution. This may make #noprojects a better fit than a project or an external agency, if the company can afford and manage its own team devoted to the product.

Support mode is a poor fit for Wicked problems. A team focused on support is trying to address discrete issues as they are raised, and is unlikely to give a Wicked problem the all-round consideration and the iterative attention that it requires. We've all seen support teams continue to fix point problems without addressing the underlying root cause. Once they step back and recognise a Wicked problem, the team often drops out of support into one of the other modes - project or product dev, whichever suits them best.

Wednesday, 5 November 2014

Projects, #noprojects, language and thought

It's a truism that when you learn a different programming language, you learn a new way of looking at code. The language we use changes our abilities to think about what we're describing. The same principle applies to Orwell's Newspeak, the linguistic battlegrounds of social equality, to the fact that arithmetic is simpler in Chinese than in English.

So it's likely that the language we use to describe our work affects how we think about it and how we perform it. Last year for example a client pointed out to me an emotive stumbling block for participants new to agile methods - he found the standard terminology of Scrum alarmingly negative - sprint, backlog, grooming.

I've had roles with an interesting range of employers, on different types of of work. Real-life examples:

  • 'Lift-and-shift' of a website from one web stack to another, with no user-visible changes
  • Ongoing feature development of a website and its custom CMS
  • Development of a social network application, segueing into product support

All of these have been software development for long-lived products, and we've described all this work as projects.

But only one is a project. And the confusion is harming us, as practitioners and as a community.

Project projects and non-project projects

PMI describes a project:

It’s a temporary group activity designed to produce a unique product, service or result.

Temporary duration to meet scoped business goals. If that annoys you because it doesn't describe your work, bear with me for a minute.

By the PMI measure, my web lift-and-shift was clearly a project.

Ongoing feature development was not a project, and while initial delivery of my social network was a project, the current support effort is not. These efforts have existing descriptors - product development and product support respectively. Together they're sometimes classed as BAU (business as usual), distinguishing them from the one-shot (and disruptive) nature of projects.

Note that I'm not suggesting that one is 'better', 'more legitimate', 'more hardcore' or 'more professional'. Clearly these are all crucial software development activities and the language to tell them apart can help us.

Why does it matter?

Simply because the different types of effort have different delivery and (whisper it) governance needs. For the dev team, BAU and support need no spinning up - there's already a product, a UX framework, an architecture, domain knowledge etc etc. And save for occasional 'major' releases there's probably no need to think much about go-live. This makes them fertile ground for a wide range of fantastic lightweight agile techniques. Projects are harder, and often mean a new team, a new set of stakeholders and business domain, new architecture, a deployment plan, handover, training and so on.

For management - the lovely people paying us to develop software - there's a predictable operating expense to BAU (OPEX - the cost of doing business) to maintain and develop an existing product with known business value. Projects are a riskier proposition. They create change in the business - that's the whole point - which means rocking the boat. They take capital expenditure (CAPEX - investment over and above OPEX). The manager has a fixed pot of money and it might go anywhere - Project X or Projects A, B and C, another server, more marketing or straight into the bank to earn interest. She has to have some reason to believe that Project X is worth the investment, which means some idea of what she's going to get, when and for how much.

How our language harms us

We throw around the 'project' to describe all of these activities, and it harms us as individual practitioners and a community.

As an individuals, the language of 'projects' blinds us to difference between the models. After all, it's all programming (or design, or system development or...). We try to apply approaches suitable for BAU to projects, techniques for projects to support, etc. Or we simply get confused why two pieces of work are shaping up very differently. This is not conjecture - I've seen extremely intelligent and skilled engineers declare 'OK but it's all just projects.'

As a community, we're engaged in a divisive debate between estimates and #noprojects / #noestimates. Each side has its impassioned advocates, and they see each other as variously as hidebound or naive.

But the clue's right there in the name. If you're not doing projects, then the #noprojects paradigm might be an fantastic fit. #noestimates might clear a swath of unnecessary overhead - even enable you to make more accurate forecasts!

If you're doing projects, this doesn't apply. Your investors still need...a project and much that comes with it.

What doesn't this mean?

This doesn't mean that projects are waterfall and #noprojects is agile. It might mean that projects sacrifice a degree of agility for a degree of predictability. How far you end up along the agile spectrum may depend on the appetite of the investor and the deftness of the team.

In similar vein, it doesn't mean that there's a hard-and-fast divide between the models. The team doing a project within a product that they support. The ongoing dev effort managed as mini-projects. There are as many ways to blur the lines as there are individual circumstances.

Where from here?

As a software delivery professional, my role is to create clarity and shared understanding. Part of that is agreeing a shared language. So I propose the following.

Within the class of Software Delivery we have three (maybe more) subclasses:

  • Projects
  • Product Development
  • Support

Because they are all Software Delivery, some aspects of all three are very similar.
And because they have different technical and management requirements, techniques that are suited to one are not appropriate for another.

And perhaps we can re-frame the #noprojects debate. Rather than pushing dogmatic points on two 'sides' that now appear illusory, we can ask when are #noprojects and #noestimates approaches beneficial? What new tools can #noprojects and #noestimates thinking add to the seasoned software pro's armoury? And framed like this, might they even find applicability in the projects domain?