Many organizations are seeking ways to move faster to market and want to be “agile.” They associate agility with speed, and with this mindset all people, process and work items are fast-tracked. Unfortunately, most of these initiatives fail because organizations view it as a mechanical problem, not one of alignment through purpose-built teams.

The blockers to agility
Harvard Business Review in their Agile issue of June 2018 audited many companies and found the main reasons why agile was not working to expectations was due to :

• too many organizations focus on big-bang transformations but are risk averse
• focus on employees needing to change, but not management
• organizations struggle with reorganization of slow moving bureaucracies
• organizations defend the status quo
• reducing control is scary to management

Mandating agile protocols and processes which are unfamiliar to employees can create discord and reduce the effectiveness of individual and team contributions. This is also true for companies that force Design Thinking on employees to embrace human centered out of the box thinking.

One of the main reasons for these failures is how work is completed in organizations based on the “do/due” model : managers tell employees what do and when it is due. Employees then do the work, and report back to the manager – and then wait for the next order. This dependence model of centralized control to define general conditions that could be optimized is really the problem and is why Agile does not offer immediate benefits to organizations.

Organizations do not understand how to address VUCA
The world is an unpredictable place. Stability and certainty which companies have traditionally yearned for are giving way dynamism and quickly changing landscapes which place stress on the same organizations.

The United States military which is probably one of the most highly structured command and control organizations in the world ran into this reality when the cold war ended. Traditional military doctrines that supported all people, processes, methods and decision making to run large armies that fought large armies began to break down in post 911 assymetical warfare where smaller brigades would fight paramilitary groups that blended into civilian populations.

The United States military defined this new world they had to operate in as “VUCA“:

• Volatility The nature and dynamics of change, and the nature and speed of change forces and change catalysts.
• Uncertainty The lack of predictability, the prospects for surprise place stress on awareness & understanding of issues and events.
• Complexity The multiplex of forces, the confounding of issues and the chaos and confusion that surround an organization.
• Ambiguity The haziness of reality, the potential for misreads, and the mixed meanings of conditions; cause-and-effect confusion.

The United States military has rethought all of its people, processes, methods and decision making to match highly ambiguous situations. The goal now is dynamic awareness and readiness through fail early & often iteration for resiliency.

The interplay between design thinking and agile
To many practitioners, they view design thinking and agile as incompatible. The main reason is intent where design thinking is viewed as about creating options and making decisions and agile is only about software development. This is a flawed understanding of both frameworks and leads to over thinking without implementing anything of value, or implementing without understanding the problem to solve.

Design thinking defines the work, but does not necessarily break it down and manage how it is executed. Agile supports design thinking by defining the details to inform getting the work done and released.

Agile want to do the work right, but does not define the vision and benefits. Design Thinking supports agile by making sure the work supports the overall goal and intent.

Both are collaborative and iterate to learn over time. As new information is generated, teams can challenge assumptions and reprioritize, change or retire work items that they do not feel are relevant.

Agile is about customers, teamwork, cadence and done and creating motivated teams to do good work and enhance the competence and confidence of teams. In agile, teams are shaped over time and should be purpose built to solve a problem. This means that there is a core team that has the skills and experience to work on the problem and an extended team of subject-matter-experts to provide deep understanding to aspects to a problem. Both work together linking people, skills & expertise, collaboration preferences and shared digital tools.

People
What usually happens : Organizations state that people are their most important resource. Unfortunately in reality organizations work against this ideal every day by treating people as “resources” or lego blocks that can be swapped in an out.
What should really happen : The agile manifesto clearly articulates that people are not resources but are passionate and competent people who want to do a good job and know how to deliver end results. People should be chosen based on their skills, experience and motivation to solve a problem.

Skills & Expertise
What usually happens : People are put on teams regardless of experience or skills
What should really happen : Agile is about specific skills and expertise to get the job done. Hard skills are ultimately valued, but have to be supported by soft skills to be a contributing team member and increase velocity.

Collaboration Preferences
What usually happens : Teams are expected to work in the same place and at the same time and to meet many times to discuss the project. Work is only shown when it is ready to be shown.
What should really happen : Agile seeks to create balanced teams by understanding individual work preferences which can unlock how to make a functioning team and increased velocity. There is a social contract that the team creates that governs synchronous and asynchronous values and behaviors and are continually discussed when work is completed.

Tools
What usually happens : Everyone works in whatever tools they feel most comfortable with and there are many copies of work that is duplicative.
What should really happen : In Agile, there is no hidden work and digital platforms are critical in continually communicating the status of the work. Use of Slack, Mural, GitHub/ZenHub, Google Office (to name a few) are used by the whole team and all work is visible to be reviewed and commented upon.

Agility is about velocity – not speed
The main problem with organizations is that they focus on the speed of agile as the main trait and desirable result of using it. Unfortunately as outlined in this article, organizations that confuse awareness with understanding and directives with ownership.

Speed describes only how fast an object is moving. In agile :

• velocity is the ability of a purpose-built team (mass)
• to consistently get work completed (trajectory)
• in a unit of time (speed) called a sprint, which usually is two to four weeks where a specific number of work items get completed by the team in order to complete the trajectory.

Velocity is the combination of speed and trajectory of a mass. Velocity is dependent on the skills, experiences and dynamics of a team. Depending on the problem to be solved, two teams working on the same problem can have different velocities and different levels of completion.

Teams who are motivated, have complimentary hard and soft skills, a desire to make in order to learn and a willingness to reflect after every major deliverable can achieve greater velocity. The more a team creates, iterates and reflects, the better it becomes at raising the bar with more and more challenging work. Increased competence drives greater confidence and this cycle can create higher performing teams.

Agility is about engagement and continuous improvement
Agile needs to have three key things to unlock the value of the framework : a clear goal; iterating to learn; and teams that are loosely coupled but tightly aligned.

For management this means that they will need to rethink the traditional command/control model of managing work and pushing items for teams to do. Instead they will help set the goal and let the team decide how to achieve it. They will also have to let go of asking for time-consuming PowerPoint updates and instead go see the work in progress and make comments along the way.

For purpose-built teams it means that they will need to take more of a leadership role and define the work to meet the goal. They will value both independence and dependence through daily rituals to know where they are, limiting meetings to a few per week and usually only have 15 minute contact times to deal with both understanding and alignment, and continually communicate through the work itself.

Immature teams can become mature, and mature teams can become great if they view the work as a platform for continuous improvement which raises the bar over time – in the face of organizational and market resistance. This will increase their velocity and efficiency to accomplish more in less units of time at a higher quality level with greater team satisfaction of work outputs that are valued by organizations and markets.