Thoughts from a Thirsty Bear

We have all seen them. Aspiring boy racers who have taken an old banger and put on the trimmings of a sports car - spoilers, big noisy exhausts etc. But it doesn’t change what is under the disguise - an old vehicle, nearing the end of its useful life, but can still limp along and get the owner from A to B. Eventually. If you have an old, rusty, Ford Fiesta, you can’t just get away with painting it red and calling it a Ferrari. It is still a Fiesta. Yet it still appears that some parts of the software industry genuinely believe that they can get away with this mentality. Let me say this one more time (with feeling) - you cannot simply take a broken software development process, put some agile tools and ceremonies around it and expect it to perform like the real thing . Or to put it another way, no matter how many spoilers and exhausts you bolt on, they can never have a significant impact on the performance of something that already has the aerodynamics of a brick and the power of an as

" What are we trying to do?" "Where is the failing test?" Repeat this mantra all the while you are developing. When you pick up a story, when you start a new slice , when you rotate onto a story, when you simply feel bogged down in detail and need enlightenment. These questions leave you with nowhere to run to, nowhere to hide. And certainly no excuses.

OK, I admit it. I have played on the Dark Side, and can confirm they have some damned good cookies . Yes, I introduced kanban to the Scrum process being used by my customer..... I know there are many people interested in this technique, so here are some key questions (and answers!) that you will come across during rollout. It's not exhaustive, but hopefully it will provide a practical starting point from which you can experiment. I have assumed some knowledge of what kanban is - limited work in progress, not timeboxed etc etc. Firstly, some background. The project I was coaching consisted of three cooperating but independent teams consisting of 4-6 devs and 1 QA. There is just one Business Analyst acting as Customer for the project - Product Owner by proxy. The project used fairly standard Scrum techniques to manage progress - stories on cards, on a board, estimated using planning poker. The board consisted of swim lanes Not Started, In Progress, QA and Done. Standard stuff. Howeve

It's such a common mistake. A company claims to be "agile" (whatever that is) yet keeps the old, stale accoutrements of waterfall interviews. The developer candidate walks in, answers random questions on what can relate to extremely wide and deep subject matter, and is then judged on their ability without them ever actually demonstrating that they can do the job . Sometimes the successful candidate really can fit in with the team, sometimes not. But most importantly, good, well suited people will inevitably be dismissed as unsuitable simply because they learn the  principles and not the detail . Being a "good" software developer is no longer about memorising a spec. The ability to regurgitate arbitrary sections of a language specification parrot fashion on request, although previously useful, has been de-emphasised by the invention of radical new ways to store information. Like books. And the internet . All you need are the basic frameworks, objects and pr

The Independent has recently published an article highlighting the state of the UK Government's IT projects . Let's just say that it's not a success story: ...the total cost of Labour's 10 most notorious IT failures is equivalent to more than half of the budget for Britain's schools last year. Parliament's spending watchdog has described the projects as "fundamentally flawed" and blamed ministers for "stupendous incompetence" in managing them. Think about it. That's £ 26 billion of taxpayers' money down the drain because of " fundamentally flawed " projects and " stupendous incompetence ". Putting this into context, university funding is being cut by a mere £449 million next year - so we are cutting investment in our future, while frittering away £26 billion on avoidable failures. Epic Fail . I have already suggested that these failures are likely to have been entirely avoidable . So have others . But there nee