Analyse This

• 15May

  Pity the poor requirement…

  Analysis No Comments

  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.

• 11May

  No such thing as a “Change Request” ?

  Analysis No Comments

  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.

• 10May

  What is a “Good” team? (Revisited)

  Analysis No Comments

  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”….?

• 09May

  Estimation hell revisited – volume #190: ‘Estimates’ are not ‘Resource Bookings’

  Uncategorized No Comments

  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.

• 02May

  So. How do you do analysis exactly?

  Analysis No Comments

  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…

• 02May

  Points of View: #2 – Porters Five Forces

  Analysis No Comments

  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.

• 08Apr

  Points of View: #1 – The Boston Box

  Uncategorized No Comments

  One overlooked technique in analysis is the ability to see issues from various different viewpoints. It is something I personally have always tried to do, and is a critical technique which in general doesn’t seem to be used enough. There are a number of reasons for this – most often, i suppose, it might be because requirements are imposed (at least at a high level) or because schedule pressure dictates that we just need to ‘get on with it’.

  Recently I have had cause to revisit the techniques one can use to model viewpoints. They are techniques which change little over the years, and are none the worse for it. Here then, is the first in a series.

  #1 – Boston Box

  When I was first taught this, it was called the ‘Boston Matrix’. But anyway.

  The aim of it is to help you assess your products and services in terms of current and future revenue potential.

  The box is divided to four quarters:

  Problem Children or Wild Cats (top left)
  Stars (top right)
  Cash Cows (bottom right)
  Dogs (bottom left)

  

  You then plot the position of your products and services in the box accordingly, based on your view of their current merit. I suppose you could separately plot their ‘desired’ or predicted position.

  Successful products tend to start as wild cats and the go round the box until they die or get reinvented as something else – a new product or service.

  So, the cycle goes ‘Wild Cats’ > ‘Stars’ > ‘Cash Cows’ > ‘Dogs’

  If we take an example, and off the top of my head, Internet access via dial-up modems seems a good example – then we get this:

  ‘Wild Cat’: Internet access via a dial-up modem. In the 1990s this was cutting edge stuff, and the ‘big thing’ in terms of home computing. It’s not profitable at this point but the is an assumption it will become so. I suppose dial-up could have been viewed as a ‘Problem Child’ also, as the technology was so new at the start.

  ‘Star’: Becomes a profitable enterprise as it strengthens and becomes ‘the norm’, more and more sought after by customers. Dial-up Internet access as ubiquitous at one stage. It Becomes a big earner.

  ‘Cash Cow’: Became a profitable and consistent revenue earner. Predictable to support. A market leader.

  ‘Dog’ : Dial-up access got superseded by broadband and people switched away accordingly. Dial-up is still around but a niche optIon and was reinvented as such.

• 21Mar

  “Describing the damn thing driven development”. Or something like that anyway..

  Analysis No Comments

  The application I am currently working on is going through dramatic changes, which reflect the change in the organisation as a whole. Nothing new about that of course. It is interesting, and a credit to the people that built the application originally, that much of the change required can be achieved through configuration and modification to reference data. Quite alot can even be done by the business users themselves. That’s not to say it has been easy to define what we need to do though, as it absolutely hasn’t been.

  But my question quite simply is this: Should one attempt to employ BDD in this sort of situation? I have attempted to, but quite frankly, it is hard and unwieldy. I am not convinced it is even assisting us. What is required is some means of describing what is currently there and explaining simply and easily what changes we need to make.

  This could be done as a simple check-list – which perhaps is all that is needed?

  I am not an SAP person, but to widen the question, can you use BDD successfully on a SAP system, given that SAP is probably the archetypal case of achieving changes through configuration rather than development as such (I suppose a more dramatic example of my situation). The paradigm with SAP tends to be about the organisation adapting to the software, rather than forward-engineering “features” which is what BDD it seems to me, is geared towards. So should one attempt BDD here? I suppose I ought to just go downstairs and just ask the SAP team.

• 15Mar

  Grand Designs

  Uncategorized No Comments

  A colleague of mine is involved in a project to modify an existing application that our team are responsible for. For those of you that follow this Blog, the scenario is a familiar one: The application isn’t very well understood, yet it is live and in use. Meanwhile the team that built it have long since moved on and the business area in question has restructured with many people leaving and joining. Oh, and there are the inevitable challenges of budget and timescales.

  One of the biggest challenges has been – apparently – getting the developers engaged, given that at the beginning there was a fairly sketchy set of requirements and obviously a sketchy level of understanding about the ‘as is’ situation. So the first step was, quite rightly, to assemble a level of understanding of what is currently there. This of course, requires developer involvement.

  “How do you expect us to produce engineering estimates for this?” Came the cry.

  And therein lies the problem. Development isn’t always about forward-engineering a solution. It isn’t just about building new features. It’s great if it is, but sometimes development is about untangling what we already have, or reverse-engineering what others have left us. Thats the reality. It might not be glamorous work and might not get you up on stage at an Agile conference, but thats’s life. These activities inform and shape what comes later.

  In the meantime we could, I suppose, write a story like “as a user I want the system to work so that I can do stuff” but what’s the point? it doesn’t get us anywhere?

  I’ve always taken the view that ‘Analysis in progress’ doesn’t just mean Business Analysis. Analysis can take many forms – It can equally mean technical analysis, or more accurately, a developer prowling round the code to find out what it is doing. The idea that you can start with an “engineering estimate” or even that you can start with “stories”, is nonsensical if this bedrock of knowledge, understanding and investigation isnt there.

  My ‘Grand Designs‘ analogy is that if you watch the programme you’ll notice that the problematic building projects tend to be those where they are altering or renovating something that already exists because they are never too sure what they will uncover. Uncovering the unexpected and having the project go awry as a result doesn’t represent some massive conspiracy or wrongdoing, just life. Building something brand new on a plot of land is, on the other hand, oftern far easier and sometimes quicker. Furthermore, it is much simpler to describe how you want your brand-new purpose-built-from-scratch home to look, than to describe how your house conversion/renovation will look, since there might be many constraints and oddities around a conversion that can’t be altered. Not all of these will be known at the start so things may change after you’re underway.

  IT is no different. Dealing with something that already exists, is often (if not usually) far more difficult to deal with than a brand-new development. It probably shouldn’t be, but there we are. Also, Agile is at it’s strongest when dealing with the ‘new’.

  So, at the risk of repeating myself, the fact is that “Stories” and “Engineering estimates” and all the rest are often the product of the analysis. Not the input to it. Not everything is a new, “green field” development. We are often faced with “brown field” developments – which I suppose are good for the environment if nothing else….

• 13Mar

  The Internet before the Internet

  General Suff, Technology, Uncategorized No Comments

  Once upon a time there was a service called Prestel The idea was that by connecting a computer to the telephone line, you could access a remote central computer containing a database of information. A kind of much expanded and turbo-charged Teletext service. Further, and unlike Teletext, you could interact: You could send messages to other users, order goods and services, make reservations, and take part in various multi-user facilities such as chat rooms.

  Sounds a bit like something we have today?

  .

  Nowadays, Prestel has long since disappeared and is virtually forgotten. IT, never an industry to have much regard for it’s own history and heritage, doesn’t celebrate past advances much. Even important historical figures such as Alan Turing (who is becoming regarded as something of a father of computing) are almost unknown today. It is left to volunteers and enthusiasts to raise the profile of the past. (A tip of the hat to Jason Gorman and others who are doing this).

  In one of my less successful predictions (though to be fair, I was still at school when I made it), I thought at the time that Prestel was the future. I thought people would embrace it with open arms. Instead it was pretty much written off as expensive and pointless by most and never achieved more than 90000 subscribers. In a weird twist of fate, the point at which It may have started really breaking through into the mainstream coincided with the internet and World Wide Web taking off. It is perhaps Ironic that one of the reasons for Prestel’s unpopularity was the fact that to connect to it involved the cost of a local telephone call. Yet when the web took off (in the era of dial-up modems – no broadband yet) people seemed to forget that that was exactly what they had to do.

  The rest is history. Prestel was dead and buried before it even got properly started.

  Should we feel nostalgic or emotional about such things? I do – though I’m not entirely sure why. In a way, you could just dismiss the whole thing as a failure. After all, many printed magazines had more subscribers than Prestel ever did. But it did do one important thing: By planting the seeds of an online world, people could at least see the possibilities for real. It wasn’t just research lab theory – It worked. Technology could deliver instant information and interaction into your home. People hopefully would (and did) get enthused and strive for a bigger, better and more ubiquitous online world. And we all know where that led.

« Previous Entries