What’s Wrong with the Project Approach?

Some time back the late Grant Rule wrote this paper on the problems with “projects” as an approach to organising software development. As the original has now ceased to be, I’ve taken the liberty of reproducing it here for posterity:

What’s wrong with the project approach to software development?

January 11th, 2011
Author: pg_rule

Pretty much since “software” was first invented (60 years ago?), numerous folk have been promoting an ‘engineering-led’ approach to ‘software projects’. Yet this advice goes largely unheeded, with the result that the relative success of IT projects is poor, and has improved very little during all my years in IT (38 and counting). Given that such admonishments seemed to have had such little effect in all that time, I also find myself asking, “Do I think it likely that further exhortations to those involved in ‘software projects’ to change their project practices is likely to achieve improved value delivery to stakeholders?”

And I have to conclude that the answer is “No”.

Following Albert Einstein’s adage that, “The definition of insanity is doing the same thing over and over again and expecting different results”, it seems to me that we need an entirely new approach. A new approach which goes to the root causes of what actually goes wrong in the end-to-end process. Why are the honest endeavours of software developers often so disconnected from the delivery of customer and stakeholder value?

Observation of what actually happens in organisations suggests there are two root conditions to the problem:

  1. Those responsible for business strategy are disengaged from, and know relatively little about, software- intensive systems and technology. So they structure their organisations so that software & technology people are segregated into silos. In those silos, the inmates talk amongst themselves in whatever arcane language they choose. But importantly, they don’t communicate (or interfere) with the ‘real business’.
  2. Everyone conspires to pretend that software-related activities should be managed as ‘projects’. That is, as chunks of work that start and end (on more or less clear and agreed dates), that have more or less well- defined goals, that contain a list of activities (tasks) that are assigned by a ‘project manager’ to a project team to which ‘resources’ are assigned for a limited period.

The results of studies too numerous to mention shows that most software projects are ‘challenged’ or ‘fail’. One study suggested that the majority of experienced project managers (and I am sure, folk playing other roles) expect at least 1 in 3 of the projects they lead to fail! As systems become more complex, and larger, they employ more teams combining projects into programmes… which further reduces the likelihood of successful achievement of the overall goals.

My conclusion is that we need a complete change of mindset. We need to move away from the inherently batch & queue concept of the ‘project life-cycle’ (as promoted by organisations including BCS, APM, PMI, OGC, SEI, NCC, ISO, IEEE, IET, etc. etc.) to a different approach.

I suggest that the required new mindset will accommodate the ideas of flow production and lean systems thinking that first began to be developed systematically (in e.g. automotive engineering) around 100 years ago. (Of course, one can trace elements of flow production & lean at least back to Carthage c.300-200 BC, but let’s ignore the history for now.)

I posit that Tom Gilb’s Evo method, and other agile methods such as XP, Scrum, Flowchain, and software Kanban, etc., begin to achieve ‘better’ results compared to ‘traditional’ big-design-up-front, wholly batch & queue methods, precisely because they encourage workers to focus on smaller batches of stakeholder value. In other words, value in terms the software developer can get to grips with.

Agile methods are one or more steps nearer to the ideal of ‘single piece continuous flow’. BUT… they are inherently limited because they continue to create & disband teams, to establish & abandon value streams, to create & throw away know-how, at – it seems – every opportunity. And crucially, they allow the C- suite and ‘business-side’ managers to ignore their responsibilities for the system of work and for the desired outcome.

Flow production (toward which Evo, Flowchain and Kanban currently make the nearest approaches IMO) would:

A) Make the entire end-to-end, whole-life, ‘concept to consumption & retirement’ process of defining, deciding, acquiring, designing, developing, operating, supporting, maintaining & replacing software- intensive systems a visible, inherent part of normal business operations… forcing issues onto the management horizon so they can be addressed as business issues – and not just something technologists worry about.

B) Because it would be apparent that software & IT issues were causing interruption to (or even cessation of) the flow of value, C-suite executives would have to recognise the pressing need to engage with software & IT related issues just as much as they do with other kinds of business issue. Conversely, the engagement of the ‘systems and software engineers’ with ‘the business’ would also be stimulated, the role of each and the communication between them finally becoming acknowledged as a main artery of the organisation’s lifeblood.

Flow production can only work effectively with the active engagement of all involved. For this reason it is a far more sustainable business model than other, perhaps more familiar, approaches. It embeds the ability to flex and respond to market forces deeply into the organisational culture. The focus on ‘the unforgiving minute’ forces constraints and problems out into the open where everyone can see them. It won’t allow problems to be swept under the carpet, or passed from one department to another like the proverbial buck. Hidden problems will always result in debts in one or more of the five kinds of capital. And such hidden debts, whether financial, technical, intellectual, social or environmental, all too often bite you when you least expect it. They will injure or kill the project – and destroy stakeholder value. Even if the project avoids repaying its hidden debts, this usually means that the debt has been passed-off onto one or another unsuspecting stakeholder group (sometimes, the end-customer or taxpayer). Which must be judged as unethical behaviour.

Unfortunately, not only have most people in the software industry been taught to sit in their silos and focus largely on coding, they and their masters have developed a cultural love affair with the project concept. To the extent that everyone assumes that all work has to be compartmentalised into projects, the very epitome of batch & queue thinking. Tell me what you think. Has the software project had its day, or is there another way of revolutionising workpatterns in the software industry?

– P Grant Rule

Coaching and Peer-instruction More Effective Than Teaching

[From the Archive: Originally posted at Jan 3, 2012]

Excellent article (well worth reading the whole piece) presenting quantitative evidence that teaching / lecturing is way less effective than “coaching” and “peer- instruction”.

Taken from the domain of Physics education, but I see many parallels with e.g. Agile coaching and, yes, even Scrum Mastering (done well).

Amplifyd from
Mazur sees himself now as the “guide on the side” – a kind of coach, working to help students understand all the knowledge and information that they have at their fingertips. Mazur says this new role is a more important one.


– Bob

Clausewitz’s Concept of Friktion – Bungay’s diagram

[From the Archive: Originally posted at Dec 3, 2011]

The closing Keynote at Lean Kanban Central Europe 2011 (Munich) was presented by the excellent Stephen Bungay. You can see the highly informative video here [Update: sadly now only available to conference attendees on request] and read more about Stephen Bungay via his website and on Wikipedia.

As there is no HD version of the video (that I can find), the chart in the video is a little difficult to read. I have therefore prepared a version of the chart (see below), which he uses to illustrate Carl Clausewitz’s concept of “Friktion” i.e. the “resistant medium” in which War (and Business) has to operate.

Carl Von Clausewitz

Carl Philipp Gottfried von Clausewitz (1781-1831)

The Chart

Stephen Bungay's Chart of Clausewitz's "Friktion" concept

(Open in new window to see at full size)


I am also struck by the fact that throughout history, Man has repeatedly found the answers to the problems of “modern (i.e. twentieth-century) management”, yet these problems still persist almost universally.

– Bob

Software Kitchen Nightmares

[From the Archive: Originally posted at Nov 20, 2011]

Explaining FlowChain Via A Restaurant Analogy

I love Gordon Ramsay’s TV series “Kitchen Nightmares” (including the USA version).

As well as being entertaining, I share Gordon’s obvious passion for helping folks improve their businesses (in my case, technology-related businesses – not restaurants!). The series illustrate in an almost visceral way the key issues facing any business, and a simple means to address these issues.

He follows much the same strategy in each encounter, a strategy which guides the changes he proposes to owners:

  • Understand what the customers actually want in the way of food, prices, dining experience, etc..
  • Change the restaurant’s offerings to more closely match that demand.
  • Get the management and workers to care about what they’re doing again (intrinsic motivation).
  • Sort out the kitchen so it has the capacity and capability to meet the expected increase in demand.

It’s the latter point which I’m going to use, as an analogy, to illustrate FlowChain and how the FlowChain perspective can benefit technology businesses. (In this post, for the sake of clarity, I’ll talk exclusively about the software development aspects of producing or enhancing a technology-based product or service).

Things In Common

In a restaurant kitchen, orders from customers arrive at the pass.

Newly-arriving orders are inserted into a running backlog, according to some prioritisation scheme, as the whole kitchen, synchronised by e.g. the Head Chef, works to prepare each element of the highest-priority orders. As elements become ready, they arrive at the pass, where they are assembled and checked before being dispatched, in small batches (one course for one table at a time), to front-of-house and the waiting diners.

In a FlowChain context, orders (in the guise of, say, new user stories) enter the software development department (or maybe it’s called the IT department – that’s an issue for another day).

Newly-arriving orders are inserted into a running backlog, according to some prioritisation scheme, as the whole department works to prepare each element of the highest-priority orders. As elements become ready (with Continuous Integration we can skip a separate assembly step, and with e.g. TDD/BDD we can skip much or all of the checking) the orders are dispatched to the waiting customers. (With Continuous Deployment we can skip much of the dispatch step, too).

So, the essential aspects which these two scenarios (kitchen, software development department) have in common are:

  • Incoming orders arrive with unpredictable variation in e.g. size, timing, priority and requested customisations.
  • There’s a constantly-changing, enterprise-wide backlog of pending orders.
  • Workers assign themselves to the highest-priority items, depending on their skills.
  • Customers do not want, nor expect, their entire meal to arrive at once.
  • Customers do expect to have a single course for the whole table arrive at the same time.
  • Continuous operation, day-in, day-out.


The benefits of this approach include:

  • Elimination of overheads such as project management (no projects!) and programme management (no brawls over resources for competing projects).
  • Elimination of project set-up and tear-down overhead (no project teams!).
  • Reduction in delays due to e.g. elimination of handovers and sequential processing.
  • Much improved flow (of valuable user-stories to customers). Increased flexibility in responding to customer needs.
  • Improved collaboration between workers, and between front-of- house and the delivery unit.
  • Provides opportunities for learning and, especially, multi-skilling, in the workforce.
  • Requires leadership (although not necessarily ONE leader), not management.

Of course, as we described in Gordon’s strategy, building a successful business as a whole means we have simultaneously to attend to a range of issues, not just simply ensure that the “delivery” part of the organisation has sufficient capability to play its part in the new scheme of things.

And please accept that this is ONLY an analogy, to help explain FlowChain a little better. A software development department is not a kitchen, and the issues – whilst similar in some aspects – are sufficiently different that I for one would not want to run a software shop in the same way as a restaurant kitchen.

– Bob

The Nature of Time-boxing

[From the Archive: Originally posted at Nov 18, 2011]

Time-boxing seems like such a simple concept. A team – with their Product Owner – gives themselves a fixed period of time, say two weeks, to:

  • figure out what’s the most important things to next add to their working product
  • build those things
  • integrate them into the working product

(Note: I’m not going to digress about the need for *working* software in this particular post. Maybe another day).

But there are some hidden dynamics at play, underneath this simple- looking veneer.

This post is about just one of those dynamics, namely, the interplay of time-boxing and commitment.

Many Scrum practitioners (and their customers even more so) have come to believe that if a Scrum Team fails to completely deliver ALL the items it has planned for a given time-box (Sprint), then it has “failed” in some way. Failed, indeed, to “meet it commitments”.

This viewpoint leads to increasingly dysfunctional behaviours, as describe recently by @yuvalyert (Yuval Yeret) in this blog post.

For all the successful development projects in which I have been involved, we have always treated time-boxing as a means to curtail overruns of effort, especially with respect to individual items (deliverables). That is to say, during Sprint Planning the folks involved in working on a given Sprint deliverable (for example, a User Story) agree amongst themselves – and with the rest of the team – on how long they will spend on that item (Note: NOT how long they expect to take to bring that item to some kind of completion, or state-of-readiness. I.E NOT an “estimate”). So, the Team commits to spending some finite amount of time on the item, NOT to completing it. We have found this distinction to be crucial.

We also apply this same perspective to the Sprint as a whole. We commit to spending two weeks (no more, no less) of our collective best efforts on working towards the Sprint Goal. We do NOT commit to delivering specific things in a fully-finished state. (Aside: It’s kind of important that everyone – Team, Product Owner, stakeholders, management, customers, etc. – all understand this clearly, with regular reminders).

Of course, if during the Sprint it begins to look like some items will not be completed in their allotted (mini) time-boxes, then the Team, the Product Owner (and maybe other stakeholders too) can have a discussion about what to do. This, for me, is one key aspect of being Agile (correcting course as necessary, even whilst “in flight”).

This does mean that some Sprints will deliver less (integrate less functionality into the working product) than expected. And some will deliver more than expected. Swings and roundabouts :).

This is the nature of software development.

– Bob

PERMA and the Positive Business

[From the Archive: Originally posted at Nov 5, 2011]

In his great, recent book “Flourish“, Prof Martin Seligman introduces the idea of “Positive Business” – an idea aimed at “broadening what MBAs care about” – i.e. beyond mere money, towards the five different pursuits which he posits comprehensively constitutes “well-being” (and for which he uses the acronym PERMA):

  • Positive emotion
  • Engagement
  • positive Relationships
  • Meaning
  • positive Accomplishment

Upon reading this, it immediately struck a chord with me, surfacing some subconscious thoughts I had been accumulating whilst reading his book up to that point. For me, Rightshifting is inseparable from the idea of creating workplaces where well-being (of employees, for sure, but also of all other stakeholders) is at the core of the work experience. As Prof Seligman states:

”If you want well-being, you will not get it if you care only about accomplishment [e.g. profit]. If we want our [Management] students to flourish, we must teach that the positive business and the individuals therein must cultivate meaning, engagement, positive emotion, and positive relations – as well as tending to profit.”

Aside: John Kay in his book “Obliquity” goes even further, positing that accomplishment, such as profit, desirable as it is, often best comes about obliquely – as a fortuitous by-product of the search for other things.

Prof. Seligman goes on to write (paraphrasing): “Even if rich profits and growth are not forthcoming, individual and collective well-being may well remain stable, or even rise, on balance.”

Quoting Friedrich Nietzche’s concept of “The Child Reborn” he then asks:

“To what can we say ‘yes’? What can every human being affirm? We can all say ‘yes’ to more positive emotion; we can all say ‘yes’ to more engagement; we can all say ‘yes’ to better relationships; we can all say ‘yes’ to more meaning in life and we can all say ‘yes’ to more positive accomplishments. In short, we can all say ‘yes’ to more well- being.”

Amen to that.

+1 for Flourishing.

+1 for the Positive Business.

– Bob

A Round-up of European Lean/Agile Conferences

 [From the Archive: Originally posted at Nov 3, 2011]
I’ve been speaking at a bunch of Lean/Agile conferences across Europe recently (e.g. October 2011). Some of the organisers have asked me for my feedback (I applaud folks who listen to their customers and want to improve). So here’s my feedback on each of the events I attended, in the “Perfection Game” format:

Lean/Kanban Benelux

What I liked

  • The venue
  • That everyone was in the same hotel
  • The production quality of the videos
  • The audio and projection facilities for the session speakers
  • The Hotel lounge
  • Belgian beer and food
  • The camaraderie common to all the attendees
  • Meeting many Twitter friends in meatspace
  • The roster of great speakers

Overall score out of ten: 8

What would have made me give a ’10’ score

  • Reliable Hotel Wifi
    • As a visitor from another country wishing to avoid excessive mobile roaming charges, and not wanting the cost and hassle of buying and swapping-in a local SIM, wifi is the best solution for me to stay in contact with home, and MORE IMPORTANTLY to stay in contact with other conference folks to arrange e.g. social events during our stay.
  • Reliable Conference WiFi
      • Ditto the above, plus live tweeting
  • Hotel and conference venue closer together (within a short walking distance)
  • Better air-conditioning in the conference venue
    • I guess we could not have anticipated a heat wave in October, but the venue was often way too hot for me.
  • Better Hotel management
    • Although the hotel decor, bar service, food, etc was great, the Radisson Astrid seemed poorly organised and run overall (i.e. great staff were defeated by a dysfunctional system).
  • Absence of personal attacks from some of the speakers on the work and – more perniciously, on the integrity – of some of their fellow speakers. I am speaking in particular of Dave Snowdon as the major offender (literally).
    • Maybe some formal “polite request” of speakers to refrain from this kind of thing might help?
  • Less confusion and uncertainty over speakers’ arrangements, expenses.
  • Real-time display of the conference (or even better, session-specific) tweet streams, on stage (big screen), during all sessions.

Magrails Manchester

What I liked

  • The organisers: Lovely people who went way beyond the extra mile to make me feel welcome and valued.
  • The venue (in general, but not the room layout – see below)
  • That all sessions were videoed
  • That there was just a single session track – great!
  • The Magrails website – great job, guys!
  • The audio and projection facilities for the session speakers (barring the audio glitches)
  • Attention to detail, especially the handouts / conference bag
  • Tee-shirt (quality!)
  • The audience. A very attentive, inquisitive and widely knowledgeable bunch

Overall score out of ten: 7.5

What would have made me give a ’10’ score

  • Much more attention to the social dimension
    • Example: Late-night chatting in the hotel bar (didn’t happen)
    • Example: Over-breakfast chatting in the hotel (happened marginally – thanks Jason!)
    • Example: Evening events held somewhere quiet, calm and cosy, to facilitate conversations
  • A better layout for the session room (long and thin made it difficult to engage with the speaker in the far distance)
    • Personally, as a “speaker” who likes to get close up and personal (engaged) with an audience, I would have like it to be “in the round”.
  • A panel session as part of the day’s schedule (or maybe an early-evening thing)
  • Everyone in the same hotel
  • Reliable Hotel Wifi
    • As I could not get a 3G signal in the hotel, I may as well have been a visitor from another country. Under such circumstances Wifi is the best solution for me to stay in contact with home, and MORE IMPORTANTLY to stay in contact with other conference folks to arrange e.g. social events during our stay.
  • Reliable Conference WiFi
    • Ditto the above, plus live tweeting
  • Hotel and conference venue closer together (within a short walking distance)
  • Better Hotel management
    • Although the hotel decor, bar service, food, etc was OK (but not great), the Radisson (Park Inn Hotel) seemed poorly organised and run overall (i.e. nice staff were defeated by a dysfunctional system).
  • Real-time display of the conference tweet streams, on stage, during all sessions
  • Not being barred from charging things to my hotel bill just because the Hotel had lost the billing details.
  • A reliable taxi firm
  • More Buzz during the second (workshop) day.
    • OK, it was a Saturday, and I guess some folks had hangovers from the previous night, but the buzz of the previous day seemed conspicuous by its absence.
  • More effective “policing” of the day’s schedule (sessions overran)
  • Mike-up the audience (or as a minimum ensure speakers repeat ALL questions so all can hear)
  • Opportunity for Open space session(s) and/or lightning talks aka Pecha Kuchas

Lean/Kanban Munich

What I liked

  • The venue
  • That everyone could get to the Alpen Hotel quickly and easily
  • That some of the sessions were videoed
  • The audio facilities for the session speakers
  • German beer
  • The camaraderie common to all attendees.
  • Meeting many Twitter friends in meatspace
  • The roster of great speakers

Overall score out of ten: 8

What would have made me give a ’10’ score

  • Reliable and convenient Hotel Wifi
    • As a visitor from another country wishing to avoid excessive mobile roaming charges, and not wanting the cost and hassle of buying and swapping-in a local SIM, wifi is the best solution for me to stay in contact with home, and MORE IMPORTANTLY to stay in contact with other conference folks to arrange e.g. social events during our stay.
  • Reliable Conference WiFi
    • This was particularly poor.
  • All sessions videoed (especially mine :}
  • Quicker publication of videos, slide packs after the event
  • Better (suggested?) Hotel
    • Avoid the Metropol 😦
  • Less confusion and uncertainty over speakers’ expenses.
  • Real-time display of the conference (or even better, session-specific) tweet streams, on stage, during all sessions
  • A lounge area (specifically, with comfy seating) at the conference venue

LESS Stockholm

What I liked

  • The “volunteer” nature of the event – thanks to all those who made it so great 🙂
  • Everyone in the same hotel
  • Outstanding catering facilities, especially the fruit, drinks, amuse bouches, and cake
  • The audio facilities for the session speakers (when they were used)
  • The camaraderie common to all attendees and organisers alike
  • Strengthening many Twitter friendships in meatspace
  • The roster of great speakers

Overall score out of ten: 7.5

What would have made me give a ’10’ score

  • A chance to see something of Stockholm
  • Better beer
  • More cake! 🙂
  • Not getting bounced out of the bar in the late evening “because of Swedish alcohol laws”
  • Better session rooms
    • Rooms were too bland and impersonal
    • Room B1 was imo too wide and shallow and too small for keynotes
    • Other session rooms were too large
    • All projection screens were way too high
    • Lighting of e.g. the speakers themselves was poor. Needed spotlights!
  • Sessions videoed
    • I really hated having to miss sessions from the multiple tracks in the knowledge that I’d not ever have the chance to catch them on video later.
  • Convenient Hotel Wifi
    • As a visitor from another country wishing to avoid excessive mobile roaming charges, and not wanting the cost and hassle of buying and swapping-in a local SIM, wifi is the best solution for me to stay in contact with home, and MORE IMPORTANTLY to stay in contact with other conference folks to arrange e.g. social events during our stay.
    • Telia’s wifi service was (generally) reliable, but a UX nightmare (continually having to reauthorise).
  • That the Hotel had refrained from remodelling their bar area during the time we were there
    • Particularly all the banging (demolition noise) during breakfaster and lunch
  • More clarity re: speakers’ expenses.
  • Real-time display of the conference (or even better, session-specific) tweet streams, on stage, during all sessions
  • Cheaper airport transfers. The Arlanda Express is way too pricey.

Happy as always to answer any questions, etc.

– Bob

Applying Silent Grouping to Sprint Retrospectives

[From the Archive: Originally posted at Aug 26, 2011]

I recently tweeted about the advantages of Ken Power’s Silent Grouping technique for Scrum Release Planning sessions. We have found it much preferable (i.e. quicker, more fun) to the more common “Poker Planning” approach.

I have been thinking about using the same principle more widely, and had the opportunity yesterday to apply a variant of Silent Grouping to a Sprint Retrospective.Our teams have recently found the Speedboat Game a welcome improvement to retrospectives, but have been somewhat frustrated by the time it was taking for everyone to contribute their ideas (leaving little time to prioritise issues and discuss possible remediations).

So I suggested we apply Silent Grouping to the contribution, and prioritisation, of issues via the speedboat’s ‘anchors’.

This turnout out swimmingly (sic) and gave us much more time to identify and discuss some Rightshifting (i.e.. improvement) stories – as backlog candidates for the next Sprint.


  • Briefing: Folks were encourage to write (just) one or two (super) stickies identifying issues that they really thought needed positive action and resource to address in the next sprint (i.e. fix or do more of).
  • Round 1 (silent): Each team member in turn adds ONE sticky to the speedboat, until all stickies have been posted.
  • Round 2 (silent): Each team member in turn has the chance to move one group of stickies (i.e. one anchor chain) towards to the bow or stern of the speedboat (we arbitrarily decided that the highest priority anchor chain would be the one nearest the bow). When movement ceased, we proceded to round 3.
  • Round 3 (discussion): The team then discussed the issues in order of priority (top priority first). In this case we devoted about 10-15 minutes to each of the top two issues, clarifying the issue (reaching some consensus on the nature of the problem) and floating possible (general) solutions. Each such issue then became a candidate Rightshifting story for the next Sprint.

Possible improvement for next time: Start with the speedboat and chains from last time, so as to sweep up issues not yet actioned as e.g. Rightshifting stories.Happy to share more detail/ideas on this with anyone interested…

– Bob

Further Reading

Using Silent Grouping for Rapid Story Ranking – Blog post

Managing Costs Causes Costs to Rise

[From the Archive: Originally posted at Jul 10, 2011]

In case anyone wants more detail on why this is so. A handy reminder.

Amplify ’d from

Managing costs causes costs

Before we explore how managing costs causes costs in service organisations, we need to consider an important advance in manufacturing, where this counterintuitive truth was first discovered. Taiichi Ohno was the man who developed the Toyota Production System: a system designed to make vehicles not at the rate the machines demanded in order to achieve economies of scale, but at the rate of customer demand. He took Ford’s ideas a massive leap further. While Ford was concerned with unit cost, Ohno concentrated on total cost. He took the view that cost was in flow – how smoothly and economically the parts were brought together in the final assembly – not just the aggregation of unit costs. How long the part is in the system is also part of its real cost. So Ohno’s factory had parts delivered to the manufacturing line at the rate the line required them – ‘pulled’ in his language (by kanban or ‘just-in-time’).


– Bob

The Carrying-Cost of Code: Taking Lean Seriously

[From the Archive: Originally posted at Jun 5, 2011]

A somewhat tardy response to a recent blog post by @mfeathers.

Amplify ’d from

@mfeathers /cc @markdalgarno

Re: The Carrying-Cost of Code: Taking Lean Seriously

I was with you all the way until your assertion that “code is inventory”. (And only dysfunctional Lean Software Development groups have “chosen to see tasks as pieces”).

In software development we are not “essentially working on the same car or widget continuously, often for years”. We are working on the *designs* for the same make or model of car, continuously, often for years. Regularly (as regularly as every couple of weeks, or even every couple of hours, for some web companies) we pass the latest design to the “factory” and another car instance pops out and passes into service.

To me, requirements (user stories in the product backlog) and everything downstream from there (including code, and even testing effort) is inventory. In fact, borrowing from Theory of Constraints’ definition of the term, I hold that inventory is “everything that a business spends money on (e.g. buying or building), that it might expect to sell again some time later”.

And inventory itself is not necessarily a bad thing. It’s the *carrying costs* of inventory that suggest we might do well to minimise it. Yes, code certainly has carrying costs. But so do many of the other assets/artefacts that arise during the process of software development.


P.S. Thanks for your patience. And I’ve posted here as your blog post seems to not want to accepts comments any more.


– Bob

%d bloggers like this: