Product driven development

The majority of problems in becomming an agile organisation is classic thinking. When offices started and people moved into cities to sit behind a desk the whole day there was no real format of how people should work together in an office environment. So the closest example of teamworking was adopted; the military style. Strong hierarchical systems ruled by a despot many called boss.
People worked as teams on farms bringing in crops before the rain; all the thinking was product based and result driven. And within a couple of years the office crowd clotted the system with a new way of working. People started to think in responsabilities and processes.

With Prince and ITIL the process driven development had it's heyday's. After a hundred years of officework we finally beginning to understand that the way we worked together the thousands of years before the offices existed we worked very well as self-driven/organising/steering teams. And now we call it Agile.

The most companies I have worked for are strugling adopting agile software development. They are trying to implement agile as the next perfect solution, become scrummish, adopt some devops, define a developmentstreet and buy some tools like Jira. All in all they are still process driven and don't think in products.

The main difference between old school software development and new school is project- versus product thinking. If companies start to focus on products and added business value and use their common sense; there is nothing hard to become agile. It will come naturally. There are actually no rules to agile, there is no one way, no golden nugget, no perfect.

If we throw away processes, we can focus on products. If we throw away command-and-control we enable people to think again. Think of the end product, about quality and come to a consensus how to develop and maintain that product. And share the pain and the success of the product with all involved!