Category: Project management

Project versus product

There’s more to software development than getting a software project delivered to the users’ satisfaction, on time and on budget. (As if that wasn’t enough.) Sometimes someone has to ensure the system lasts for the long term. But when that happens it’s a balancing act: between the project and the product.

The project and the product might start at the same point, but they usually finish at very different points. A project finishes with the last milestone release of the code — and a party. The product finishes with the opposite: the last byte of code being removed from the servers — and a party only if it was really nasty software.

The balance between project and product is something that I see again and again in many different forms. Here are some examples from different stages of the project lifecycle…

Project versus productTools: Java verus Ruby

There’s an amusing little spat going on over at Michael Coté’s blog. It’s a fairly traditional tussle of Java versus Ruby (and other scripting tools), in which Coté accuses Java people of being overly concerned with internal architecture, while Ruby (and LAMP and Django) people are more concerned with delivering the goods. But Robert Cooper adds the telling observation that the maintenance of the delivered goods could well be a nightmare if it comes from the scripters, because it often involves a “mish mosh” of technologies with non-standard dependencies.

Robert’s point, more generally, is that getting the application out the door is only part of what a software team needs to worry about, and the choice of tools has a bearing on life beyond the project end.

People: Internal and external

Having an internal software team is a wonderful thing. Among other things you can build up a huge amount of expertise, both technical and business-specific, which helps everything go much more smoothly. But sometimes bringing in consultants from out the outside has a benefit, too, and beyond mere extra bodies. Consultants get to see many different projects, technologies, businesses and people over a very short time, and they bring this accumulated expertise with them.

Mixing internal and external people like this can work really well. In terms of ideas, external people can bring ideas and propose directions that might otherwise not have been considered. Internal people are all too aware of the long term implications of these ideas in their organisation and can stop the crazier ones before they get too far. In terms of making the best use of time, external people are often particularly driven by project deadlines, perhaps because they’re often only employed for projects, so it’s all they ever know. Internal people can see the time spent now but also have a very good feel for time likely to be spent in the future, so can determine better when additional time within a project is actually investment for the future.

Sometimes work is outsourced entirely to external teams. Sometimes work is undertaken entirely by internal people. When the two kinds of people mix there is creative conflict, and the balance between project and product is tested.

Release: Releases rarely happen once

I once worked on a six month project with a big bang release. At the end of the project was a single release which took three days. That wasn’t three days of integration, testing and launch. That was three days from the point when the software was entirely ready for the end users, to the point where it was actually available to those users.

In terms of the project this was fine: on the scale of a six month project, a three day release is negligible. But when we came to release 1.0.1 and release 1.0.2 it was a bit excessive, and by release 1.0.16 it was actually a serious business issue.

There are many lessons to be learnt from this, but one is that we had erred towards the project too much and our lack of consideration for the product caused us problems very, very quickly.

Soup to nuts

It’s too easy to forget about the product in the rush to the end of the project. At one time I realised I was so negligent in this area I stuck a large message on my monitor in 36 point font:

…and how will that be maintained?

Balancing project versus product affects everything from who you involve at the start through to how you hit your deadlines and on to how it affects the rest of your working life (and possibly your non-working life if you find yourself on call). There isn’t a one-size-fits-all answer, but at least if we are aware of the tension between the project and product we have a better chance of making more informed decisions.

Quality is a bogus variable

Quality seems to be widely misunderstood. People often talk about quality being a key variable that a project team can choose to alter to reshape their project — along with other variables such as cost, scope and time. I think that view is flawed. Meanwhile Mishkin Berteig is not unusual when he says “I have come to believe that quality is not negotiable” — meaning that although it’s possible to negotiate over it, it’s fundamentally wrong to do so. I think that view is flawed, too. From my position quality can rarely vary in the same way as other key project variables, is rarely changed directly, and often it is right to allow it to drop below 100%. I want to spend some time here explaining why.

Before I launch into this, allow me to say that although this is inspired by an issue on which I differ with Mishkin, I do have great respect for him. In fact, it’s arguable that I’m only writing this because I have such respect for him — because it’s so surprising to see him write something that seems to be so mistaken.

The sections ahead are:

  • Quality is about much more than bugs
  • Quality is rarely addressed at the outset
  • Quality is less flexible than scope, time or money
  • Quality is usually the driven, not the driver
  • Quality can be lowered — and sometimes that’s okay
  • Non-executive summary for non-executives

Now, let’s get on with things…

Quality is about much more than bugs

First, let’s make one thing clear: quality is not just bugs. It includes look and feel, ease of use, ease of installation, performance, and so on. Looking at Mishkin’s post it’s clear to me that we he says “quality” he really means “bugs”: he is making a strong case for test-driven development. But test-driven development doesn’t help with an application that requires six clicks rather than one to enter the default data. It doesn’t help that one of your modules needs administrator access to save its state. It doesn’t help that you can’t add any more servers when you need to triple its capacity. These are situations where quality could be improved, but which aren’t solved by test-driven development. Quality is wider than that.

Quality is rarely addressed at the outset

There’s a classic project management mantra in many variations: “cost, quality, time: pick any two” is one such [1, 2 (PDF), 3]. At one level it implies (quite fairly) that the major project variables at the outset are interdependent, and you can’t choose settings for them all. You can’t say, for instance “I want it to do all this, I want it to be flawless, and I want it in a week” — making just two of those demands determines what you get for the third.

But at another level it suggests that people are making these kinds of decisions, and that quality is often determined at the outset. I find this implausible. I rarely hear clear requirements at the start of a project about the quality of the result. I’ve heard vague pronouncements, but rarely anything that could be factored into a project plan. I’ve heard “we need to do better than last time”, and “let’s not over-do it the way we did before”. But that’s usually part of an agenda-setting speech, not the project plan. It’s not enough to help make a calculable impact on scope, cost or time.

At the start of a project you will hear a precise number for a budget, a strong date for a deadline, and (we hope) a clear list of requirements. But it’s very rare that people give a precise level of quality — it doesn’t even have a common unit of measurement (remember: quality is not just a bug count). Quality is rarely negotiated at the outset. The client expects the software to do the job specified, and that’s that.

Quality is less flexible than scope, time or money

Another misconception is that quality can be varied to the same degree as other major (initial, or input) variables such as scope, time and money. Scope can be cut right back, or added to indefinitely. Similarly for money and time. But quality doesn’t vary in the same way. Quality can’t be increased arbitrarily — after a point there’s nothing left to do, assuming the scope isn’t changing. Similarly it can’t be reduced to zero, because below a certain point — well before you get to zero — the product isn’t doing the thing it was supposed to do and therefore you’re reducing scope.

However, while I believe that quality varies less than other project variables, I do believe the consequences of improving quality — even a small amount — are significant. Unit tests reduce firefighting and ensure the project is always moving forward. Usability testing ensures people are much more comfortable and confident with your software, paying dividends throughout the business. Increasing quality by a small amount can have a big, positive knock-on effect.

Quality is usually the driven, not the driver

I’ve talked about scope, time and money being “input” or “initial” variables. They’re things that are usually explicity set at the start of the project. Quality, however, might be set early on, but it’s usually determined by other things.

Sam Newman writes, correctly in my opinion, that quality is driven by process. Here, they way you do things determines how good the result is. Quality is an “output” variable more often than not. Introducing test-first development is a process change; allowing post-development testing time to be reduced because the development phase has overrun is a consequence of an unfortunate project management process; introducing or eliminating performance testing is a process change. In all these cases quality is not an independent variable; it is driven by other things.

Quality can be lowered — and sometimes that’s okay

Quality is negotiable, and it would be foolish if it wasn’t. It would be foolish if budget, scope and time weren’t ever negotiable, but they are, and in that respect quality stands next to them on a level.

Real situation: The website is being built; the investors are making bullish noises in the City; the launch — a release and public demo — was scheduled months ago and is due next week with 200 big media attendees, and testing is still on-going. If a real, but infrequent, bug is found that can’t be fixed by next week does the company cancel the launch?

Real situation: You’ve been working for months on your release. It’s almost done, but there’s another project looming, which the sales team are desperate get started. The time remaining for your current work will leave some untidy edges, but there’s a pressing commercial need to release it and move on to the new project before the company loses more competitive edge than it already has. Do you push for a project extension?

If a developer tells me their professional needs are bigger than those of the organisation in which they work, then they shouldn’t be working there. A developer works for their organisation — just as everyone in that organisation does — not the other way round. And making the right decisions for the business must have positive consequences for the development team.

Mishkin says

Every time the developers sacrifice quality for schedule/cost/features, they incur a debt. Sometimes this is called “technical debt”. I like to call it lying.

Powerful prose, but I’m afraid that particular extract strikes me as uncharacteristically arrogant. “Technical debt” is an honest term. By using this term the developer says to their organisation that the decision taken now will incur an increased cost later. The organisation as a whole can then weigh up the options and make an informed decision. And call me crazy, but it might just be that after being appraised of the situation, the project board, or managers, or directors might be in a better position to make a strategic decision than the developer who’s paid for their expertise in one very particular part of the organisation.

Of course, that’s not to say that every decision on quality needs to be raised to board level. Just as a developer wouldn’t dream of bothering their project board as to whether they should use descriptive variable names (“Well, short names are quicker to type and might shave off 2% of our delivery time, but longer names will save us time if we need to revisit that part of the code…”) so there will always be ways to improve quality in refactoring, or configuration, or packaging, or architecture which the developer should just do without question because they’re a professional. But the developer who never informs their project board of major quality forks in the road, and who never allows their client to be involved in such decisions, is failing to fulfill their responsibility as a member of the whole project team.

At Guardian Unlimited we’re always looking for ways to improve the quality of what we do. But I’ve also heard people say “let’s not gold-plate it”, and “look, we’re not producing art”. These are senior developers who are arguing against particular quality improvements because they are able to weigh up not just the technical decisions but also the wider business decisions. They are being pragmatic. I’d say they are much better developers for it.

Non-executive summary for non-executives

Let’s recap. Quality is really important. It’s about much more than unit testing. And making small increments in quality can result in disproportionately large increments in the results. But let’s not kid ourselves that quality is a variable that can be tweaked arbitrarily and independently this way and that. It’s not of the same standing as budget or scope or time. And let’s not kid ourselves that developers of principle have to stand firm against some kind of management beast constantly trying to undermine them. Developers are an integral part of the organisation, and should behave (and be treated) as such. The quality of developers’ output needs to be balanced just as every other organisational demand does.

As long as we can see and understand software quality for what it really is, the better we are able to improve it.

Is it agile? Check the fixed points

One of the problems with agile development is that it’s subject to changes, so means you’re in danger of changing it into something which isn’t agile. How do you know when you’ve gone too far?

This isn’t a problem for seasoned agile practitioners, but it’s a concern if you’re just starting out, or working with people who are. It’s certainly something I found looking back at my early agile days. There are some non-obvious or difficult agile practices which one might omit, but which make a big difference. How do we know what to watch out for?

My suggestion is to ensure there are some fixed points. Then you can evolve the process without straying from the ideals. My rule of thumb for creating fixed points is this:

Could I stand up at an international conference and be sure that my process would be generally indistinguishable from that of any of the speakers?

With that in mind, here’s what I’d want to be sure I did before I stood next to my peers…

A fixed point, by lobo235

Daily stand-up meetings at a set time

There are three things here: daily, stand-up, and set time. Making the meeting daily can be difficult, but having spoken to people who hold weekly meetings it’s pretty clear that they take up the same time in the end. In addition, daily communication keeps people veering too far off the track.

Insisting the meetings are stand-ups might be difficult and there’s no clearly tangible gain — after all, if you keep the meeting to 5 minutes, who cares whether you’re sitting or standing, or bouncing on one leg? But this important to me because it instills a sense of urgency. A sit-down meeting fails to distinguish us from our document-heavy, procedure-driven colleagues. It’s entirely psychological, and all the better for it.

Making the meeting at a set time can be difficult, particularly if the lead has other responibilities. But this is important to me because it forces people to focus on the project. It says “The train’s going at this time — be there or get left behind”. It tells people the project won’t wait for them. It keeps the team to a rhythm.

Iteration kick-offs and/or close-downs

It’s surprisingly easy to get away without these: some of last iteration’s story cards might not be finished, so the team just carries on; new story cards become available when the old ones are done, which could be any time. Iterations blur.

But a formal meeting to mark the iteration boundary again ensures the project and the team keeps to a rhythm. Coming up to the boundary it ensures people know ahead of time that they’ve got something to aim towards, and deadlines always focus the mind. Entering the new iteration it gives people the chance to think afresh and renew their goals.

Mid-project retrospectives with the whole team

An end-of-project retrospective is good, but mid-project retrospectives are agile. They ensure the team really is seeking to improve not just for the next project but for the current one. It can be difficult to see the benefit of retrospectives (another time-consuming meeting), nor do I think they’re not very obvious. I certainly don’t recall them cropping up in the Extreme Programming Explained or in Agile Software Development with Scrum. One way to keep retrospectives effective is to ensure any actions are (a) objective and (b) assigned to named individuals. This way improvements will be much more tangible.

Continuous integration and testing

This is certainly an obvious feature of agile, but it’s also difficult. If the project is anything more than a few days long it’s worth spending the time up front to get the continuous integration and testing working. This ensures rapid change and frequent delivery. Otherwise it’s very likely that features and fixes will regress, that this won’t be discovered for long periods, and fixing the regression will take a long time, too. Agile is about frequent delivery and constantly moving forward at a regular pace. That can’t be done without continuous integration and testing.

Frequent customer demos

Again, not necessarily obvious because while agile talks a lot about on-site customers it doesn’t often talk about the common case of customers not being around as much as you’d like. Frequent mid-project demos are the next best thing — at Guardian Unlimited we call them “show and tells”. A customer demo has two benefits. First, it steers the team towards feature-driven development rather than architecture-driven development. (It’s very hard to impress a customer with a data object layer.) Second it encourages prioritisation of the next batch of features.

Anything else…?

There’s much more you need to do to be sure you’re being agile, but to my mind the things above are easily missed. So next time I create a team for an agile project I’m going to make sure we start with some fixed points, and evolve round those.