The ABC of the ESB IT people must be some of the cleverest and expensive in the world. Or at least that the theory. And yet we are constantly falling for the emperors new clothes in the form of next-big-things whilst discarding what we have, even the bits of what we have that work. The answer lies in understanding the history of how we got to where we got to and, unfortunately, accepting that some things are hard work and we have to do it. ...
Magnificence in the Mundane Relationships between IT departments and business customers are not unlike real world friendships. If you can see what works with your friends you can apply it in business. And it’s mostly about conversations. If you can talk, you have a good chance of resolving anything. As professionals in a complex subject area it’s always tempting to look for sophisticated answers to problems, but by focusing on the common sense basics of how we structure ourselves and how we act we can deliver better software. When we do that we cease to be something distinct from the business and we can stop talking about business/IT alignment and get on with doing what we do best. ...
The Interview - Part One Interviewing is a vastly underrated skill, and yet if you can do it well it brings you the best of all rewards - good people to work with. This is part one of a two-part article looking at effective candidate filtering, interviewing techniques and questions that work for technology roles.
Change Steps The last of three articles about change programmes. This one assumes that you have got to the point where you have to have one (the two previous articles explained why generally they are not a good idea). If issues have been left to fester for too long though sometimes you have no choice. This article proposes a way to run a change programme that is effective with the minimum amount of paperwork and fuss. A change programme that makes changes. What a novel idea that is. ...
Scalability
The Fallacies of Agile The Agile approach is great when applied appropriately, but the concept is nothing new. In fact it goes so far back it shares its roots with the waterfall method. But Agile got a cool name in 2001 (before that it was just working closely with the customer in an iterative fashion, which wasn’t anywhere near as catchy) and was jumped upon by consultants and cowboy coders. This article looks at just some of the common fallacies that have grown up around this peculiar buzzword. ...
What would Scooby do How change programmes usually go once the consultants turn up. These are the warning signs to look out for. All found by deep reading the masterful and authoritative canon that is the work of Scooby Doo.
The Retep Principle
Foundations Packaging up delivery work for the annual plan is tricky. You don’t want huge programmes that spend a fortune and lose their way, but equally too many small projects will likely dupllicate work and create a communication nightmare. What you need is a mix of business-outcome driven initiatives supported by a small number of carefully scoped foundational projects. Here’s how.
The Analysis Business A look at business requirements from a functional and non-functional perspective, concluding that partitioning requirements up into arbitrary categories isn’t very helpful as it reinforces the subjective politics we need to get away from.