Thinking Agile - the core ideas of Agility

Agile is not like any other changes, transformations or methods you may have previously applied to your work - it is a fundamental change in the mindset of a whole organisation. Everyone from the Chief Executive to the newest, most junior recruit must understand the ideas of agile and adopt the agile mindset if we are going to get the most from this change. We are rethinking what we do and how we approach it.

There are many articles, sites, books etc. about specific ways to be agile (e.g. scrum, kanban, lean) and many of the techniques used in agile have existed from long before agile had a name - we are not trying to reinvent things that already exist and work well. The difference is in the way we think about the whole approach to deciding what we do and how we do it. If you can think agile then any technique could be appropriate. If you do not think in an agile way then no amount of adoption of the words and processes of agile will make you agile.

It is also important to realise that ‘being agile’ is not something you will ever achieve. ‘Being more agile’ is the target - every step adds value. It is an ongoing process of change and improvement. Becoming more agile is, itself, an agile process.

The layers of agile are commonly explained with the agile onion.

{{pic and ref and description}}

An individual, team or organisation is not getting the best from agile until they ‘get it’ at all these levels. The articles on this site mostly concentrate on the mindset, independent of any specific technology or terminology.

What is Agile thinking?

Agile is about delivering the best solutions in the best way.

Essential categories of thinking:

• Joint enterprise because we should all be working towards common goals. This enables us to concentrate on things than benefit everyone
• Empirical basis because real data focuses our effort on things that matter
• Value because we deliver better solutions if we understand who needs what and why
• Simplicity because anything we cannot easily understand prevents us from delivering the solution in an appropriate manner
• Just in time because we respond to our users and stakeholders to deliver what they really need through close interaction. We also embrace feedback and change accordingly, so we do not try to pre-empt the solution and make sure the delivered solution is appropriate

Put those ideas together and they will help individuals, teams and organisations benefit from the true value of agile. Miss any of them out and you are not agile.

Why concentrate on these things?

These points are core differences between Agile approaches and other approaches. This section contains some short notes on why these things make agile more effective than methods that do not embrace these features.

Joint enterprise

Working together to deliver a common goal ensures that all work (including new, dynamic decision-making) is aligned to these overall goals. This reduces the amount of conflicting or competing work that is happening and facilitates streamlining by reusing work and activities where possible/appropriate, rather than having multiple parts of an organisation doing essentially the same thing. It also helps reduce the overhead of communication activities since people can focus on the things that impact them and require their direct involvement. This can have many effects such as reducing the length and improving the focus of meetings.

{{Would a value checklist at the end of each section help?}}

Empirical basis

Difficulties in teams and organisations can commonly arise from conflicting views on how to approach certain decisions and activities. Hierarchical structures and dictatorial management can result in projects and organisations following inappropriate routes, even though most of the participants know this is the wrong way to go. Decisions based on “Who shouts loudest” or “Highest paid person’s opinion” are common. So are decisions by committees who do not understand the implications of their decisions. The only sensible way to move away from this is to base our decisions on actual data. Newer tools make it much easier to aggregate and visualise this information without intermediaries who ‘interpret’ it in the way that they find most suitable for their ends.

This improves the realism of our planning, progress tracking and decision-making. It also helps us get rid of the “illusion of certainty” where we draw graphs and the like to make it appear that we know what we are doing despite having insufficient information. This ‘guess’ then often becomes embedded as a fact in the organisation - even though it has no basis in fact. With our empirical approach, we look at real data, but also embrace what we do not know and the uncertainties in the data. We can then target those uncertainties (in a structured manner, over time) to develop more realistic models. This is a continuous process.

The result is that we avoid going down “wrong paths” and make the best decisions we can at any given time. This can save vast amounts of wasted resource, time and money.

Value

It may sound obvious, but it is important to deliver solutions and services which are valuable to someone and doing it in ways where each piece of activity involved in that delivery contributes to the value. Of course, we would all like to be doing that all the time, no matter what approach we use. Sometimes that gets lost in larger pieces of work resulting in essential work not being done, priorities being mis-placed and less efficient use of resources.

In agile we place value upfront at all levels of our work and use it to help us with planning, prioritisation and many other decisions.

Simplicity

Most of us have had the experience of large, complex plans, specifications and other documents. These often try to be complete and exhaustive at the expense of comprehensibility - they contain much information which is not relevant to a specific audience and are rarely read or understood fully by everyone.

In agile a key measure is simplicity. By keeping things clear and simple we ensure the relevant information (and no more) reaches everyone who needs it. If something feels complex or incomprehensible, then it is not agile enough. This improves communication, planning, decision-making, effective use of time and much more.

We achieve a lot of this by breaking things down into hierarchical structures where each level can be related, but where most people can concentrate on a small number of levels at a time, depending on their role.

Just in Time

Just it time means producing things (including delivering solutions, refining plans, documentation etc.) just sufficiently far ahead of when it will be needed. This does not mean doing everything last minute, but doing it at the latest appropriate time.

By doing this, we ensure our work is based on the best and most accurate data we have available - and that will change as draft1a piece of work progresses, which is why this is significantly more effective than trying to make complete plans in advance with insufficient or inaccurate data.

This also means we can (and must) make a better job of working closely with end-users and stakeholders throughout our project. We can use tight feedback cycles to better inform our values and improve our data so that decisions in the near future are as accurate as possible and decisions which are further away can be revised and improved before we commit to them.

Some key ways to achieve these things

• We are engaged in a joint enterprise
  • We have shared high level goals and understand why we have them
  • We break these goals down into more detailed goals and activities, but they all contribute to the overall goals
  • There are no silos - it is not agile to say “I have done my bit, now it is someone else’s problem”. Understanding and supporting what others do is essential
  • This is a ‘no-blame’ culture. If things go wrong (as they inevitably will) we work together to fix the immediate problem and learn from it for the future. This helps the system and the individuals continuously evolve over time
  • Involve everyone early on - ensure all aspects are considered
• We make decisions based on empirical information, not opinions or who shouts loudest
  • Visibility of information - including what we do and why - is essential at all levels. This is not the same as telling everyone about everything, but about effective use of communication channels. Everyone needs access to all information that may influence their work and decision-making
  • We embrace uncertainty. Pretending we know things that we do not is not agile. We estimate things like timelines, resource requirements and costs - but we continuously revise them as information improves. We acknowledge this uncertainty and can create activities to reduce the uncertainty, but we cannot expect to know everything in detail until the work is complete (if it ever is)
  • Openness is the default. We do not hide any data about what we as individuals, teams or an organisation do unless there is a justification for it
  • Decisions are devolved as far as possible, and definitely to those with the competence to make them. Committees deciding things without understanding the implications are not acceptable
  • We minimise hierarchical structure and information flow through that structure. We have mechanisms at all levels to know which decisions we cannot make and escalate them or delegate them as appropriate. Intermediate hierarchical levels (middle managers) are much less important with current technology and should not be created or maintained without justification
• Delivering value is central to what we do
  • We use value as a way of assessing and prioritising what we do at all levels of the organisation. There may be many aspects to value
  • Determining value requires engaging with clients/users and stakeholders on a frequent basis to learn about their needs, inform them of what we are doing and get frequent feedback that informs what we do in the future. Some education of these groups is also a part of draft1keeping them informed
  • Value is dynamic - it can change over time
  • Keep it simple
    • If it is complicated then it is not agile - break it down a different way
    • If it is not flexible and responsive to change then break it down a different way
    • If progress cannot be communicated clearly and simply then break it down a different way
  • Work Just in Time
    • Do not try to know everything upfront
    • Plan ahead for appropriate amounts of time and appropriate levels of detail
    • Expect plans to change (especially at levels of details) but get refined within constraints
    • Continuously review what is required and refine with feedback
    • Work out the details of work items at the last sensible time
    • Do not commit to work until you are sure it is valued

  Tell me more

  {{To do - links to more MEC details and other resources}}