Archive for May, 2012


Requirements get a hard time. People often seem scared of them. They are viewed as dangerous animals. They need taming. They need to be controlled, prioritised, re-prioritised, scrutinised, numbered. They are scary, unpredictable beasts.

And more terrifying than that: They Change.

Yet this shouldn’t be a problem at all, should it? It is ironic that we supposedly live in a world of continual change, where adaptation is absolutely central, yet people seem to have a problem with requirements changing. Bizarre. The fact that requirements change isn’t the problem. It is how we deal with the change that is the problem. If we understand our systems and how they behave and what they are capable of, why would unexpected changes in requirements be a problem? If anything, such changes should be encouraged. That’s what we’re here for. Furthermore, It ought to be the creative, rewarding part of the job?

Compare that to a situation where you have a suite of poorly maintained and poorly understood systems. In this scenario, you’ll have problems. Simple as that. (For a further discussion of this, read the rest of this blog).

The project I recently completed was successful in the face of incredible change, alteration and general vagueness. It was an object lesson in it. What was eventually delivered was almost the complete opposite of what the programme manager and other senior staff suggested at the start they wanted. So to say the requirements changed and were vague is talking things up. As a result, It could have been a catastrophic disaster.

Yet it wasn’t. So why wasn’t it?

Well, simply because the application in question was well understood.

Through what seems to me to be an accident of history as much as anything, it had been well invested in over the years. in that it had dedicated development staff to maintain it. This in turn was because its technical platform necessitates it rather than a conscious choice. This is an investment that has been rewarded many times – on this and other projects.

It is sadly very common nowadays to see people attempt to counter these issues by imposing more and more ‘control’. More and more scrutiny. This inevitably results in more and more administration. More and more reviews. More and more reporting. Furthermore it takes people away from doing the work itself. Well intentioned as it is.

One of the developers where I sit was re-jigging his project’s Kanban board the other day. He remarked on how all our boards have “Change Request” as one of the available cards. And then said something quite interesting: “When you think about it, there is no point in having Change Request cards as in Agile you would only ever have new features. There isn’t really any concept of a “change”. It’s a waterfall idea – where you are deviating from some upfront specification”.

And I think he has a point. I have to say the fact we have “Change Request” cards has never really bothered me. But equally, it is often difficult to choose between “new” and “change”. So perhaps he’s on to something, and the reason it is hard to choose is because “change” shouldn’t be there at all.

At the moment, on my specific project “change” generally means we are altering the behaviour of something, but it is done via configuration or reference data. You could argue the “feature” is unaltered but behaves slightly differently. Further, there is involvement from IT to make the change. It isn’t something the users can do themselves.

It’s an interesting question, and I don’t have an answer to it.

The other day I found myself (yet again) explaining to someone my interpretation of the phrase “a good team”. It is a phrase referred to a lot in agile. Some people seem surprised it is even open to interpretation at all.

To be clear, “a good team” means a team that “understands the behaviour (business rules, logic and so on) of the aplications we support or are building, so that they can become productive as swiftly as possible”.

Most applications have business rules and logic embedded in them. Often this is invisible to the user. If it is not well understood, our project will have problems. It’s that simple. These problems aren’t a reflection on the people in the team, or at least aren’t down to their technical skills. Or even their ability to apply those skills. It goes beyond that. If you are faced with I’ll-understood code, even ‘world-class’ (whatever that is) developers, analysts and project managers will struggle. They are not “a good team”. Sorry.

Some people will step in at this point and say “ah yes. But we can ask our customers or our BA”. They will know how it all works.

Really? Even for behaviour invisible to the user? What if we have new people? What then?

Possibly the team wouldn’t struggle if they were building something completely brand new with no legacy to it. This is a situation that most developers (or all of us come to that) generally want to be in, but can’t.

The above also assumes there is a stable set of people. And more often or not, there isn’t.

One big issue people also need to recognise is that understanding the behaviours of the application can influence the stories and requirements that we eventually produce. We need to know to a pretty good level of detail how our requirements fit in the global game. You can’t just impose them and pay no attention to what already exists.

Perhaps you could call this “Behaviour Driven Development”….?

Some project managers still seem to have this (albeit unwritten) notion that estimates can be treated as a kind of ‘resource booking’ or ‘Diary Booking’ arrangement. You are allocated to work on one thing and one thing only, you work on it until it’s completed and that’s that.

So if I estimate 2.5 days of analysis, that means I will start on Monday and finish at lunchtime on wednesday, right?

Wrong.

And it’s wrong on many levels. Not least because the nature of analysis is such that you often need to leave and come back to things. Either because you are waiting for the customer to respond or digest what has been presented, or to take actions on their side. In the mean time, one can slot in other work. As long as we don’t have too much work in flight that doesnt get completed thats fine by me. And Kanban and agile is good at managing all this anyway.

I dare say 100% velocity on a piece of work is sometimes achievable, but often not. If anything I would suggest it is often undesirable. To leave something and come back to it can sometimes be a good thing. You see it with fresh eyes. Like composing music (which I do when not doing this) you dont do it all in one go. You have to sometimes step away and come back. It takes time *.

In my case, I avoid estimating on a ‘Diary Booking’ basis if I can. My 2.5 days of analysis might be spread across 2 weeks and rightly so. The The Mythical Man month explored the reasoning behind all of this nearly 40 years ago. Nothing has changed.

___________

* Having said that, developers often don’t like this. They complain about it and call it “context switching”. And sometimes they have point. There is nothing worse than being pulled continually from pillar-to-post and I am not for one moment condoning that which is equally as bad. But working on an IT project is not like fitting a kitchen.

Reasonable enough question I suppose.

“Talk to people, but also know when to shut up and listen to what they have to say”, would be my answer. Closely followed by “don’t overlook the obvious”.

Not much of a basis for a book though. Perhaps advertising on this site is the way to go…

This continues our look at techniques to model viewpoints.

Porters Five Forces

This technique is used to assess the attractiveness of a market.

It consists of four forces that act upon a fith, which is the level of competition in the industry.

The four forces are:

- Threat of new entrants
- Bargaining power of suppliers
- Power of consumers
- Threat of substitute products and services

Weirdly, this doesn’t include regulatory or political factors which you would think would be important when assessing a market.

Say we looked at the online music market as an example and applied the above:

- Threat of new entrants is high as new online services are emerging all the time
- Bargaining power of suppliers is strong, since this includes artists and copyright holders who can dictate payment terms
- Power of consumers is strong- they can go elsewhere even to free download sites
- Threat of substitute products is high, as the Internet provides a myriad of ways of obtaining/consuming the same content.

It all makes sense, but you could argue that most markets can be categorised in much the same way, so in some ways I’m not sure the technique is particularly enlightening.But there you go.