In the product owner must pull I described what can happen when there are not enough stories in the pile. Here I want to look at the same problem from a slightly different angle: in terms of the Theory of Constraints.
The development team’s throughput is low. TOC says that the organisation must therefore include a Constraint (a bottleneck). The Constraint is the major factor in causing that poor productivity, and our first step is to IDENTIFY it. In software development, one of the easiest ways to find bottlenecks is to look for stuff piling up. In this case we find that the constraint lies outside the team, in the person/process/team that creates the story pile. There are piles of visions, wishes and capabilities waiting to be analysed, but downstream there’s no work for the developers to do. The constraint is the analysis function.
Our second step must be to EXPLOIT the constraint – to get it functioning on full power. In iterative backlog management I adopted Scrum to help the analysts generate stories and incrementally build a pile of stories for the developers to work on.
Third, we must SUBORDINATE everything else to the constraint. In this case we decided to stop development for one iteration. In lean manufacturing terms the development has no customer pulling features. So instead the development team will carry out some maintenance work: refactoring the codebase (tidying gemba), improving test coverage, installing new tools etc. (As things turned out, analysis generated some high-value stories quite quickly, and so we were able to re-start development on those stories before the end of the current iteration.)
Fourth, we must ELEVATE the constraint. Which means we must look for ways to make the current constraint more productive, or else eliminate it from the production flow. In our example this probably won’t be an issue. As the analysis team settles into being proactively managed it looks to be capable of creating stories faster than they can be developed.
Which leads us to the final step: we must PREVENT INERTIA and re-start the process with step one. Now that analysis is creating a story pile and development is working on it, we need to IDENTIFY the system’s constraint all over again. This time it will be somewhere different, and again we’ll find it by looking where things seem to be piling up…
When the Product Owner doesn’t have enough stories to drive development, try running an incremental analysis project that keeps one iteration ahead of the developers. The deliverable from each analysis iteration is a modified Product Backlog, ready for the upcoming development iteration’s planning meeting.
Whatever the reasons, it’s sometimes a fact that the Product Owner just doesn’t have the backlog prepared in time for the next development iteration. This can have a destructive effect on the development team’s morale and productivity, and must not be allowed to continue for too long. So something we’re trying on a current project of mine is to set up a parallel “analysis” project, to be run using the Scrum process. (This is certainly not a new idea; for example, Martin Fowler talks about this technique in Planning and Running an XP Iteration.)
I expect the mechanics of the two projects to work something like this: Continue reading →
At the AgileNorth meeting on Monday of this week we recapped an old discussion about technical risk. Some months ago Phran Ryder had raised the question of how to prioritise stories during release planning. I have always held out for business value as the only factor to consider. Phran however insisted that his project was different, and that technical risk was more important. The topic came up again this week, and this time Phran was able to provide a very succinct explication of how we resolved the issue.
The dilemma is this: In order to deliver maximum value under all possible outcomes, we should prioritise our stories solely on the basis of their value as perceived by the Customer. But what if we can’t assess that value, or estimate the stories, in advance? What if we need to bring some stories forward to the front of the schedule, so that by doing them we gain further information to help us create the remainder of the plan?
Here’s a quick attempt at a conflict cloud:
(I’m not too pleased with this – please help if you can think of a better formulation of the dilemma.)
We resolved the dilemma by attacking the necessary condition at bottom-right in the diagram: we reminded ourselves that implementing a story isn’t the best way to obtain information about when to implement it! That’s the job of a spike (a throw-away prototype). We should do just enough work to obtain the information we need about the story. Just enough to put us in a position to correctly prioritise or estimate it and get on with planning the release. (At this point we must also throw away the spike code. Because the odds are very good that the world will be a different place when the spiked story comes to the top of the pile. If we kept the spike, it would likely require learning and re-work to fit into the new and growing system at that time. Best to just ditch it now and start afresh when the customer really needs it.)
As I’ve described elsewhere, I’m currently helping a large organisation that has a shared infrastructure / architecture and swarms of business projects. Many of these projects want to add features to one particular VB client. But the VB client is zealously protected: it must never fail, and too much change in it would swamp and confuse its low-skilled users. Consequently the developers can create new software features faster than the business are willing to deploy them.
TOC would say that we must subordinate the software production process to match the capacity of the bottleneck. That is, projects should only create new features if they can be deployed immediately. Amazingly, that’s exactly what happens. The bottleneck is protected by a design board (yes, nothing here is done by one person working alone); the board schedules a few releases per year, and project managers have to squabble to get their features into one. Any project that can’t get a release slot has to wait. It works!
I’ve just read a process guideline for managers who are unfamiliar with iterative development. It states that each iteration must have a detailed plan, and that in creating that plan the manager will be making “constant trade-offs between scope, quality and schedule”. (The whole document seems to be written with the intention of making iterative development seem more difficult than waterfall! Is there a subtle agenda, attempting to steer managers down familiar paths?)
The advice seems reasonable at first glance. After all, if we’re behind in adding the key feature for this iteration, we’ve always had the options of cutting it out, or not testing it, or slipping the date – right? I don’t think so. We should always reduce the scope of the iteration. Continue reading →
Last night I was the invited speaker at the first meeting of the British Computer Society’s new Chester & North Wales branch. Being a regional group, rather than a specialist group, the membership is very diverse. So my title was Agile Software Development – An Overview. But agile is a huge subject, so what should I cover and where should I focus for an introductory talk?
Last month as I began preparing, I kept running aground. I was expected to deliver a ‘lecture’, which implies a linear pass through the subject via a set of PowerPoint slides. But each time I came back to my slides for another pass, I came up with a different tack that might be appropriate to the imagined audience! Finally I had a brain-wave: ditch the PowerPoint. Continue reading →
Today, as part of my learning process, I sat in on a planning/progress meeting for one of the plethora of projects currently happening here. At one point the project manager set a quite aggressive (ie. early) date for the first release. A few people in the room expressed some nervousness about whether such an early date would cause quality to be compromised, for example. “No, of course not – because we’ll be doing a bugfix release a month later,” he proudly announced. “Tremendous,” said everyone. “Good plan. Well done.”
I sat very quietly in my corner, observing. If that’s good practice, I really do have a lot to learn…
I once worked alongside a chap who was a project leader in a large organisation. His team produced a new release of their system every 4-6 months, and so over a few years he ran quite a sequence of projects, all on the same codebase and all with the same team. He’s a bright guy, good at his job, one of the nicest people I ever worked with, and his story is quite typical. I’m sure you’ve seen something similar to what I’m about to describe.
During the second and third of these projects he diligently noticed that his programmers were spending a portion of their time fixing defects in previous releases. He diligently measured the time thus spent – at 10% of the project’s staff-time. And this was his perfectly rational reason for missing his deadline and dropping a couple of features into the bargain. During ‘planning week’ for the next round of projects he therefore proposed to set aside 10% of his staff’s time for fixing defects. He had the figures to prove that this was sensible, and the programme managers supported his plan. (In fact, they encouraged all of his peers to do the same.)
So for the next release his team spent 10% less time adding new features to the system. A thinking person might then have expected that the following project’s time budget would thus need to be shortened by only 9% – because surely 10% less product will have 10% fewer bugs, right? Wrong. The 10% figure never tailed off, and no-one ever noticed.
So either the bug-fixing time was being used to mop up other problems in the estimates, or the bugfixes contained as many bugs as the original code. At one point I suggested he spend the 10% of all future projects in implementing defect-prevention measures, but he didn’t have the time…