Versible

The is not another essay on Waterfall versus Agile. For one of those arguments, see The Internet. This blog suggests the discussion of these well rehearsed arguments is mis-framed.

I think I have probably always "worked agile", although initially I was unaware of the term, let alone any formalised definition of it. We were merely working in the way we found best suited, through repeated experience, to working with only a few people on complex data projects that needed to show results rapidly.

Later, I worked for an organisation that said it "worked agile". Although it wasn't a form of working I recognised and rarely seemed to succeed in delivering much efficiently. Why?

An organisation comprises many things, but when it comes to complex technical delivery, lets simplify it to just people, processes and culture. When an organisation steeped in waterfall "does agile" it typically means changing the processes around how developers and engineers work: It starts delivery sprints, accepts a different way to organise tasks, and a different way to track progress. Developers and engineers remain at the end of the chain beholden to the plans of architects, business analysts, designers, project managers and the like. But at least the meetings now sound cool ("sprint planning", "stand-ups", "retros") so it must be doing agile.

This entirely misses the point of agile. It mistakes it for a task management approach, when it is far more fundamental. Re-organising processes is unlikely to change people or culture, when it is these that really matter. I'll stepback from saying an organisation needs to change its people, as long as its people are prepared to change (which is kind of what culture means).

Agile requires a different mindset. Not just from the engineers & developers, but from every other person in every other position from The Big Boss downwards. Out with a my-job-your-job attitude encouraged by specialist roles and job titles. In with a can-do-will-do attitude and a mutual sense of ownership. This isn't to say agile workers can't specialise in some area, but they need to generously share their specialist knowledge, and encourage others to do as much as they can within "their" specialist area. Critically, everyone must muck-in to undertake the pressing tasks of the moment, whatever they might be.

Herein lies the limitation of a traditional culture. It will put together an agile team like any other team; with representatives from each skillset. This team tends to then operate with a this-is-my-job that-it-your-job approach. This is not explicitly expressed, rather implicitly ingrained in culture.

So what is the alternative? You need a bunch of people, with a bunch of varied skills, who all understand what needs to be achieved, and who are prepared to do whatever work is needed to best achieve the objectives. When I say "achieve", I mean achieved overall for whoever is the beneficary of the work. Not "achieved" within a narrow definition of a traditional job title. So a Business Analysts might need to write some code. A Project Manager to write some documentation. A Developer do some user testing. Of course a Developer should not just let anyone loose on the code-base, but with a bit of guidance and encouragement, others should be capable of contributing. Everyone in the team is intelligent, so leave egos at the door and get stuck in.

Unfortunately corporate structures and culture often hinder this style of working in unintended and hidden ways. From individual expectation through to formal objectives and performance reviews, there is little incentive for individuals to "generously share their specialist knowledge" and "leave egos at the door and get stuck in".

How do you solve this? Afraid I'm don't have an answers for that. Unless you are a small organisation setting up afresh, in which case you are free to create whatever kind of culture you like, and this is what we set out to achieve at Versible.