5 common misconceptions about working agile
Being without leaders and having no plans — those are some of the prejudices that e.g. corporate staff functions tend to have, preventing them from supporting the organization move in an agile direction.
“I’m against agile — it’s all about making people run faster!”
I looked incredulously at my high school friend, who also happens to be a work environment professional. I know that many misconceptions surround agile ways of working, but that she would think that my professional endeavors of spreading agile ways of working are fueled by a wish to make people run faster, left me quite puzzled (oh well, offended).
The corporate world is turning towards agile and it’s no longer restricted to the IT-organization. ‘Agile’ has become a corporate buzzword and can be found in most company strategies as they realize the need to become more innovative, nimble and responsive in order to keep up with the competition.
But underneath the generous application of the word, often lie many misconceptions of what it means to work agile. Especially among corporate staff functions such as HR, Finance, Legal and Communications — even Strategy. While they may be quoting agile elements such as iterations or sprints, they lack an in-depth understanding based on the knowledge and experiences of practitioners.
Agile is, however, not a superficial intellectual exercise, but based on empirical evidence, experience and knowledge about human behavior. The consequence is that the organization begins to speak different languages. Functions get out of step with each other as more and more areas embrace agile, while staff functions keep providing support based on the assumptions of the legacy organization.
Staff functions must learn the language of agile and what it means to their field in order to stay relevant to their organization. For now, let’s start by addressing the most common misunderstandings about working agile.
Making people run faster
The cadence of agile work may be based on sprints (if working in e.g. scrum) which may of course give associations to running fast if taken literally. But running fast is not the aim — quite the contrary. Sprints are broken down into tasks and estimated in detail to ensure a sound workload and a pace that can be sustained over time.
While our traditional production paradigm of constantly delivering more with less, aims at a constant 100% resource utilization, an agile team shouldn’t load their sprint with tasks exceeding 70% of their capacity. Empirical evidence has proven this to ensure optimal flow. In other words, teams become more agile and effective by having room to maneuver the social dynamics of collaboration and some slack to account for unforeseen incidents.
It may sound paradoxical that in order to increase agility, we need to have teams working at a steady pace. But while velocity (the amount of work that can be completed during a sprint) increases in well-functioning teams over time, this is a result of the team becoming more capable and mature, not the result of relentlessly pushing people to run faster.
Constantly changing teams
Liquid workforce, gig economy, digital nomads — all words for a strong trend of an increasing contingent workforce (of e.g. freelancers). Maybe this is one of the reasons, why some people have the impression that agile teams are constantly assembled and dismantled around specific tasks. In other words, an organization in flux.
But nothing could be farther from the truth.
When working agile, you aim at building stable teams. As scholars have pointed out long before ‘agile’ became a business term (remember Tuckman’s team phases from 1965?), high performing teams are built over time. Creating strong agile teams of diverse and complementary competencies, high psychological safety, end-to-end responsibility and a solid and sustainable rhythm of collaboration is not done overnight. It takes time and grows with experience. After all, we may be working in a digital age, but we’re still social, human beings.
Hiring freelancers can be a good complementary strategy to access new knowledge and skills when required, but you need to have a strong base of stable team members, not a constantly shifting workforce. The overall principle is to rather take a job to a great team, than to build a new team around the job.
Having no plans
If having a plan means having a detailed waterfall model outlining the full course of a project, then there is some truth to agile not having plans.
Dwight D. Eisenhower once said: in preparing for battle, I have always found that plans are useless, but planning is indispensable. Thereby pointing to the challenge that in an unpredictable world, we can’t plan far ahead. The same goes for problem-solving in a VUCA world: We don’t have complete knowledge at the outset, and neither will we get it through analysis alone. Thinking otherwise is naïve and time-consuming at best.
Therefore, when working agile, we move from having plans to planning. Agile methods replace the extensive upfront waterfall project plan with ongoing, just-in-time planning of sprints; taking feedback, changes and learnings into account as we go.
In this setup, planning is a structured social and collective responsibility, continuously reinforcing ownership, a common picture of the direction and a detailed understanding of the immediate tasks. While a classical Tayloristic approach is to split ‘the thinking’ and ‘the doing’, planning and execution become a shared team capability when working agile.
Working in a chaotic way
In continuation of the “no plan”-perception is also the notion of agile being chaotic. While the language and events of sprinting may seem unfamiliar and maybe random from the outside, working agile is actually very structured.
Scrum is a highly formalistic, yet simplistic framework designed to deal with complexity and volatility. With a number of fixed events during a sprint, social pitfalls and biases of collaboration are taken into account and hopefully avoided.
Having this formalistic structure creates a stable rhythm and sense of safety, while dealing with the fluidity of ever-changing product needs by ensuring ongoing planning, daily coordination, continuous learning, and getting feedback from customers during the course of an iteration (a sprint).
Having no leaders
Agile organizations have a flat structure compared to traditional hierarchies with multiple leadership layers. But while there are examples of complete leaderless organizations (e.g. Holacracy), this is not a goal in itself for agile.
We need to distinguish between ‘leader’ (as a position) and ‘leadership’ (as a capability). In an agile organization, we strive to move power, responsibility and decision mandate to the frontline with the autonomous team. In other words, the goal is to have a high level of leadership, but in a distributed sense and as a capability in the team.
There might still be leader positions in agile organizations, but the role changes radically from becoming power bases and bottlenecks of decisions to building and supporting agile team autonomy with a high level of distributed leadership.
