Tag Archives: PDD

PDD

Development Strategies

The Development Strategy triangle.


Most [all?] discussions on Agile (or lean, or XP, or whatever the strategy de jour is currently) seem to use a sliding scale of “Agileness” with pure a Waterfall process on the left, a pure Agile process on the right. You then place teams somewhere along this axis with very few teams being truly pure Waterfall or pure Agile. I don’t buy this. I think it’s a triangle with Waterfall at one point, Agile at the second, and Panic Driven Development at the third. Teams live somewhere within this triangle.

So what is Panic Driven Development? Panic Driven Development, or PDD is the knee jerk reactions from the business to various external stimuli. There’s no planning process and detailed spec as per Waterfall, there’s no discreet chunks and costing as per Agile, there is just “Do It Now!” because “The sky is falling!“; or “All our competitors are doing it!“; or “It’ll make the company £1,000,0001; or purely “Because I’m the boss and I said so“. Teams high up the PDD axis will often lurch from disaster to disaster never really finishing anything as the Next Big Thing trumps everything else, but even the most Agile team will have some PDD in their lives, it happens every time there is a major production outage.

If you’re familiar with the Cynefin framework you’ll recognise PDD as living firmly in the chaotic space. As such, a certain amount of PDD in any organisation is absolutely fine – you could even argue it’s vital to handle unexpected emergencies – but beyond this PDD is very harmful to productivity, morale and code quality. Over a certain point it doesn’t matter if you’re Agile or Waterfall, the high levels of PDD mean you are probably going to fail.

Sadly, systemic PDD is often something that comes from The Business and it can be hard for the development team to push back and gain some order. If you find yourself in this situation you need to track all the unplanned incoming work and its affect on the work you should be doing and feed this data back to the business. Only when they see the harm that this sort of indecision is causing, and the effect on the bottom line, will they be able to change.


1 I have worked on quite a few “million pound” projects or deals. The common denominator is that all of them failed to produce the promised million, often by many orders of magnitude.


“PDD” originally appeared as part of Agile In The Real World and appears here in a revised and expanded form.


Three Bin Scrum

Allan Kelly blogged recently about using three backlogs with Scrum rather than the more traditional two. Given this is a format we currently use at Virgin Wines he asked if I would do a writeup of how it’s used so he could know more. I’ve already covered our setup in passing, but thought I would write it up in a little more detail and in the context of Allan’s blog.

Our agile adoption has gone from pure PDD, to Scrum-ish, to Kanban, to something vaguely akin to Scrumban taking the bits we liked from Scrum and Kanban. It works for us and our business, although we do regularly tweak it and improve it.

With Kanban we had a “Three-bin System“. The bin on the factory floor was the stuff the team was actively looking at, or about to look at; the bin in the factory store was a WIP limited set of issues to look at in the near future; and the bin at the supplier was everything else.

When we moved to our hybrid system we really didn’t want to replace our three bins, or backlogs with just a sprint backlog and product backlog because the product backlog would just be unworkable (as in 1072 issues sitting in it unworkable!). So we kept our three backlogs.

The Product Backlog

The Product Backlog (What Allan calls the Opportunity backlog, which is a much better name) is a dumping ground. Every minor bug, every business whim, every request is recorded and, unless it meets certain criteria, dumped in the Product Backlog. There’s 925 issues in the product backlog at the moment, a terrifyingly large number of those are bugs!

I can already hear people telling me that those aren’t really bugs or feature requests, how can they be, they’re not prioritised, therefore they’re not important. They’re bugs alright. Mostly to do with our internal call centre application or internal processes where there are workarounds. I would dearly love to get those bugs fixed, but this is the Real World and I have finite resources and a demanding business.

I am open and honest about the Product Backlog. An issue goes in there, it’s not coming out again without a business sponsor to champion it. It’s not on any “long term road map”. It’s buried. I am no longer thinking about it.

Our QA team act as the business sponsor for the bugs. Occasionally they’ll do a sweep and close any that have been fixed by other work, and if they get people complaining about a bug in the Product Backlog they’ll prioritise it.

The Product Backlog is too big to view in its entirety. We use other techniques, such as labels and heat maps to give an overview of whats in this backlog at a glance.

The Sprint backlog

Bad name, I know, but this equates to Allan’s Validated Backlog. This is the list of issues that could conceivably be picked up and put into the next sprint. The WIP limit for this backlog is roughly 4 x velocity which, with our week long sprints, puts it at about a months work deep.

To make it into the Sprint Backlog an issue must be costed, prioritised and have a business sponsor. Being in this backlog doesn’t guarantee that the work will get done, and certainly doesn’t guarantee it’ll get done within a month. It simply means it’s on our radar and has a reasonable chance of being completed. The more active the product sponsor, the higher that chance.

The Current Sprint

With a WIP limit of last weeks velocity, adjusted for things like holidays and the like, this forms the List Of Things We Hope To Do This Week. We don’t have “Sprint Failures“, so if an issue doesn’t make it all the way to the Completed column it simply gets dumped back into the Sprint Backlog at sprint completion. The majority of uncompleted issues will get picked up in the next sprint, but it’s entirely possible for something to make it all the way to the current sprint, not get worked on, then get demoted all the way back to the Product Backlog, possibly never to be heard from again.

Because issues that span sprints get put back in exactly the same place they were when the last sprint ended we end up with something that’s akin to punctuated kanban. It’s not quite the hard stop and reset that pure Scrum advocates, but it’s also not continuous flow.

The current sprint is not set in stone. While I discourage The Business from messing about with it once it’s started (something they’ve taken on board) we are able to react to events. Things can be dropped from the sprint, added to the sprint or re-costed. Developers who run out of work can help their colleagues, or go to the Sprint Backlog to pull some more work into the sprint. Even the sprint end date and the timing of the planning meeting and retrospective is movable if need be.

The Expedited Queue

There is a fourth backlog, the Expedited Queue. This is a pure Kanban setup with WIP limits of 0 on every column and should be empty at all times. QA failures and bugs requiring a patch get put in this queue and should be fixed ASAP by the first available developer. Story points are used to record how much work was spent in the Expedited Queue, but it’s not attributed to the sprints velocity. The logic here is that it’s taking velocity away from the sprint, as this is work caused by items that aren’t quite as “done” as we had hoped.