“Pro tip: Never assume shared understanding” – Charles Lambdin.
In fact, if you’re in a position where a topic is under serious debate (consultancy, coaching, training, change programme, etc.) you should prioritise grasping exactly where your understandings differ, & removing that. From then on, change will be a lot less painful.
Changing basic assumptions is the basic lever for initiating change in just about anything. But equally crucial is the fact that assumptions are not just things in your head – they’re also built into the very structure of your organisation.
That is, if you currently work one way rather than another, that’s as much as because your organisation, systems & processes permit only a limited range of actions – or specifically mandate a formal sequence – as it is because everyone agrees you should act like that.
This is what core management tools like formal requirements, Big Planning & Design Up-Front, milestone reporting & bureaucracy generally mean: they not only make one way easier but also make most alternatives impossible.
So if you’re planning to implement Agile, what are the basic assumptions you & your existing organisation are making? Here are 10 basic assumptions of many non-Agile organisations. How many do you plan to actively challenge as part of your Agile implementation?
- Change happens in large blocks. It’s not desirable – or realistic – to break large changes into smaller changes that could be implemented incrementally. Even if we could, this would confer no benefits & eliminate no risks.
- Big Everything Up Front (Requirements, Modelling, Design, Planning, etc.) is a realistic strategy. Our specialists can say in detail what stakeholders want & anticipate the detail without extensive prototypes, partial implementations or advice from testers & developers.
- Change is bad but fortunately rare. Once defined, requirements, architectures, designs etc, will not change to the point where the ROI on Big Everything Up Front becomes negative.
- Silos are good. Not just in development (business analysts, designers, coders, testers, etc.) but wider delivery functions too – pipeline, architects, operations, deployment, maintenance & support, etc. We see no benefit in direct collaboration between these groups.
- Silos are really good. Not just in IT but in wider organisational functions too – recruitment, resource allocation, financial control, etc. We see no benefit in IT collaborating directly with these groups either.
- The basic units of our organisation are resources, not ‘people’ (whatever that means). We use tools like matrix management & resource pools to assign resources based on skills & availability. We use & evaluate them as resources, not rounded individuals (whatever that means).
- Teams are temporary artefacts. We see no benefit in teams accumulating experience by working continuously with individual products, systems or technologies. We do not value their shared experience of collaboration.
- Hierarchy is good. Smart, experienced people sit at the top, and less smart, inexperienced people sit below. Command & control is good: people need telling how to do their jobs. Project managers tell their teams what to do, execs tell PMs, etc. We tell, we don’t ask.
- We have no need for ‘upwards’ feedback. Disagreement may be tolerated but too much becomes dissent & is treated as such. But fortunately, few dare to tell their superiors what they really think.
- In short, deploying the ossified products of past human intelligence – hierarchy, bureaucracy, authority, etc. – will deliver better than allowing our current employees to express expertise, adaptability, creativity, innovativeness, etc.
Of course, just abandoning these assumptions won’t get you to Agile. But if you do not weed them out, you’ll find the journey to Agile is much longer than you hoped, and you may well never won’t reach your goal.