— i.e. they are synchronised with each other and the organisation’s goals
When we think about what makes Agile such an effective approach to software product development, we think about a single team, working toward a single product vision, happily iterating and incrementing toward a common goal.
As soon as you add just one more team or product in the mix (often referred to as “scale”), you have already added significant complexity to the situation in terms of product prioritisation, team processes, methods, estimation, relationships, dependencies and more. In short, keeping the magic of single team/single goal becomes increasingly difficult — seemingly impossible.
Well, It’s certainly not impossible. Agile organisations make principle-led decisions that allow them to keep the single team/product magic alive. They ensure that every person in the organisation has a clear goal at any given time — the same goal as that of the team they work with — which in turn is aligned to the correct organisational goal at that precise time.
Principles are one thing, but structurally this might sound too hard. Again, yes it’s hard, but it can be achieved via clear and ongoing prioritisation of initiatives (the things of [assumed] value that we want to achieve as an organisation), and forming autonomous teams/squads/tribes around them. If there are dependencies between teams, act to minimise them — remove them completely if possible — for your highest priority initiatives. Push the dependencies down the priority list.
It can also be achieved by forming teams around long-lived themes, such as customer capability. For example, MYOB builds accounting software. If I were to ask one of our SME customers “What does MYOB software enable you to do?“, the type of answer that would come back would be “banking“, “taxes“, “payroll“, “reporting“, etc.
These functions are all candidates for forming cross-functional squads around — squads that include all folks required to deliver end-to-end value within that area of capability for the customer. Suddenly, our business mission of “Making business life easier” is broken down into “Making banking easier“, “Making taxes easier“, “Making payroll easier“, and so on.
As a side note — this kind of customer-centric approach is also a hallmark of a truly agile organisation.
— via ubiquitous information, not based on rank
In knowledge work organisations, thousands of little decisions are made every day. If folks do not have good information with which to make those decisions — or they are not empowered to make them for some other reason — there can be a huge impact on the organisation, both culturally and economically.
For example, if I am asked to deliver two outcomes, and it becomes apparent it is only possible for me to deliver one of them, what should I do? Do I have the appropriate information (and authority) to choose which one to sacrifice? What about technology choices? How should I deal with this customer situation? Should I fix this bug? Should I ship this feature now or delay delivery for a week?
If I cannot make these decisions quickly — in a way that is consistent with how others would decide (because we all have access to the same information), and without fear of being punished for making the wrong decision — the organisation might effectively grind to a halt.
An agile organisation makes decisions quickly — based on clear decision frameworks that enable everyone from the CEO to the cleaner to fearlessly make good decisions every day.
— i.e. responding to change over following a plan
An agile organisation is not [necessarily] one that can churn out masses of features every week. It is also not one that jumps around, shifting priorities from one week to the next. Instead, it is an organisation that can seize opportunities very quickly — opportunities that arise either via internal ideation or changes in the market.
An agile organisation should have a strategy, sure, but it recognises that the strategy might be misguided, or needs to change for some other reason, so it ensures that teams can adapt quickly to a change in strategy rather than require a painful restructure. It does not put all its eggs in one basket and optimise for delivery of the strategy. It actually embraces agility itself as a strategy.
Lead time is a common metric for lean/agile organisations to focus on, and rightly so — how quickly can we turn an idea or request into real value for a customer?
In theory, it is easy to turn that killer idea into a real thing for a customer quickly, even if your organisation does not yet have the necessary infrastructure for true agility. You can achieve it via an authority figure usurping other “priorities” and thus seeing their request expedited by a team swarming around it, doing what they are told to do as quickly as possible at the expense of everything else. Look how quickly critical production issues are resolved when all the key people are thrust together immediately with a single, shared focus and goal.
This is why organisational agility requires not just responsiveness but sustainable responsiveness. The expedite situation above can never be sustained. True agility is being able to turn on a sixpence due to work being done in small enough batches — and with enough slack in the system for folks to be quickly available when new and better opportunities arise than the ones we currently have.
— and conveying information to and within a teams via face-to-face conversation.
Organisations typically default to processes and tools when trying to address improvements in performance. Truly agile organisations are full of folks who recognise that improving the quality and quantity of their interactions with other folks is the key to improved performance.
For example, frequent all-hands gatherings to plan together, celebrate and review achievements, learning and progress toward goals — over trying to get everyone to put all their tasks in Jira.
— i.e. build projects [sic] around motivated individuals — give them the environment and support they need, and trust them to get the job done
This one almost speaks for itself. If every hiring manager in the organisation hires other folks with a mindset aligned to the desired collective organisational mindset, they are [by design] hiring people they trust and who will be motivated to achieve the organisation’s goals.
There is no place — nor need — for hierarchical authority, carrots and sticks in effective agile organisations.
— not via the sum of collective individual performance appraisal
Managers and leaders who focus their efforts on trying to improve the performance of individuals in their teams are playing a low percentage game in terms of the likelihood of any significant effect on organisational performance. Managers are far better served addressing “the way the work works” — the system conditions — to achieve the kind of improvements they are being asked to make.
If you want your organisation to get better in a particular area (e.g. efficiency), fix the environment to support improved efficiency for the whole eco-system, not any one team or individual.
(I’ve referred in my talks to this systems approach to improvement as “building a network for high speed trains” rather than “trying to make trains faster“).
— technology folks work daily with other folks who share the primary concern of serving customer needs, thus the organisation operates as one “we” rather than many “them’s”
As I’ve already alluded to, organisational agility requires high trust between individuals, teams and departments. Unfortunately, typically organisations are instead built around silos, which encourages and then perpetuates a low trust environment. This is why folks in, say, development teams, end up referring to folks in, say, sales or marketing teams as “the business”.
High level strategy and day-to-day task execution must be mutually respected in equal measure by the folks who are responsible for them. Everyone in an organisation is “the business”, and until folks recognise this and live it daily they cannot be part of a true agile organisation.
Organisational agility requires an embedded continuous learning and improvement culture. There are always better ways of doing things in complex environments (such as knowledge work organisations). “Best practice” and cookie-cutter processes will never achieve agility.
Instead, we must experiment with models, heuristics and methods that allow us to adapt, pro-act, react and enact with respect to what we’re building and how we’re building it.
What other signs are there of an agile organisation? I’m sure there are more — please share.