management agile metrics continuous improvement

On metrics

There’s still an ongoing debate whether development in particular and IT, in general, are engineering practices. In all cases, there’s no denying that our industry is based on scientific foundations. Most of the organizations I’ve worked for implement the Deming wheel in one form or another: From a bird’s eye view, it makes a lot of sense. And given the success of the method in the Japanese car industry, there’s no denying that it’s effective. However,

agile cargo cult

Agile cargo cult

One of my first talk at an international conference was about cargo cult in the Java world. The story behind cargo cult is quite interesting: indigenous peoples were living their life on some islands in the Pacific Ocean. During World War II, both Japanese and American forces happened to come to those islands which were important to their respective military supply chain. Both sides did what every armed force in the world does to achieve their goal: they brought soldiers, constructed airplane r

agile infrastructure ops devops

Exploratory Infrastructure projects

Nowadays, most companies use one or another Agile methodology for their software development projects. That makes people involved in software development projects at least aware of agile principles - whether they truly try to follow agile practices or just pay lip service to them for a variety of reasons remains debatable. To avoid any association with tainted practices, I’d rather use the name 'Exploratory Development'. As with software development, exploration has a vague feeling of the f

agile management software development

Work for a company not lead by finance

Disclaimer: this post touches bits and pieces of finance, management and sociology for which I’m far from qualified. However, I’ve plenty of experience working in companies where they had big effects and I couldn’t resist drawing my own conclusions. I’ll happily listen to realistic solutions. I’ve been working for more than a decade in the software industry, always as a consultant. Most of my employers were pure consulting companies, with only my latest employer be

agile project management

Can we put an end to this 'Estimate' game of fools?

When I was a young software programmer, I had to develop features with estimates given by more senior programmers. If more time was required for the task, I had to explain the reasons - and I’d better be convincing about that. After some years, I became the one who had to provide feature estimates, but this did no mean it was easier: if the development team took more time to develop, I had to justify it to my management. Now, after even more years, I have to provide estimates for entire pro