5 Reasons Agile Is Working

Agile is going viral in organizations. Across industries, organizations are re-thinking how to perform work, how to organize teams, and how people communicate. Work is becoming dynamic, shifting between interactive (creative) and repeatable (efficient) tasks. Agile was recently recognized by MIT Sloan Management Review (article) and HBR (article).

But why? Here are a few observations from my work with large organizations.

(1) Teams are re-learning how to engage with each other ... and they like it. Over the years functions specialized, departments became siloed, organizations dispersed. Companies grew via acquisitions and now live across disparate locations. IT teams have outsourced offshore. Collaboration tools enabled teams to telecommute and work across geographies. These factors enabled growth and new ways of working. Yet, not the most efficient way for people to collaborate on new ideas, or problem solve together. This is the current construct faced by many Fortune 100 companies.

There is no substitute for face-to-face interaction

In an economic era where innovation is high (i.e. early stage "S" curves) this construct doesn't work well. Organizations face threats from startups, digital natives, and tech companies. Agile proposes a new way for people to interact. It focuses on co-location, daily interactions, and conversations across teams.

Co-located teams use less documentation which increases efficiency

Keep in mind most teams working in Agile way won't want to go back to old ways of working.

(2) Teams getting co-located as much as possible. There is no substitute for face-to-face communication. Problems are better solved in whiteboard sessions than countless emails and text messages. The power of writing on the board incites creativity, encourages people to engage, and activates brainpower in a productive way. Co-located teams can reach to the person nearby and ask a question. Over time they use less documentation which is one of the benefits of Agile.

Co-location is not always possible in distributed organizations, with many teams offshore. Yet Agile design should take co-location as an important factor.

More conversations, less meetings

(3) People interacting more often, ideally face-to-face. Agile methods, such as Scrum, prescribe ceremonies such as daily standups, demos, and retrospectives. They follow discreet principles. Teams should have frequent (e.g. daily) internal interactions, but no more than that. Imagine a day where your only meeting is a daily standup! The rest of the day focuses on productive conversations. More conversations, less meetings. The idea is to dramatically reduce number of meetings, which can take up to 40% of your time, according to The Atlantic.

Senior leaders also engage more often with teams on the ground. Sprint demos are designed so that teams get feedback from senior leaders. They align expectations often, instead of over “phase-gate” milestones, common in traditional thinking. Senior leaders “see” the work in progress, instead of reading derivative reports. Often times leaders are far removed from the work itself. Demos enable them to “touch and feel” products, and learn on how to achieve business objectives. The role of senior leaders changes from traditional “command and control” to setting objectives and guidelines, and removing blockers.

Teams also engage with customers and end users. Organizations become great at experimenting, whether via A/B testing, focus groups, or testing with internal employees. Teams learn to love getting feedback from customers, peers, employees. At MIT Media Lab students may come from diverse backgrounds but they excel in one thing – demos. Students perform demos to peers, professors, sponsors, and visitors. They do it ad-hoc and recognize feedback can come from anyone, to improve product design. When I coach Agile teams, I often get asked – who should do a demo? Who should attend? The answer should focus on how to optimize feedback to design the best product. For example, developers can demo to IT Ops so they learn to build a more stable product. Designers can demo to customers to improve usability. Product Owners demo to executives to align on business outcomes, and so on. Over time every team member grows to appreciate the value of demos and becomes great at it.

DevOps is necessary to "turbo-charge" Agile

(4) Organizations are modernizing technology enablers. Many organizations will focus too much on Agile practices and forget the tech components. DevOps offers an opportunity to turbo-charge Agile and extend its reach to IT Ops teams. It proposes tools and practices to optimize software development metrics. Yet, companies focus too much on tools instead of improving outcomes. Instead organizations must focus on high opportunity areas to improve via automation. Starting points include test automation, Continuous Integration, and automating operations functions. Implementing DevOps will help organizations avoid the "rush and wait" phenomenon. This happens when Agile teams design a new feature, and then wait for Ops to launch to production. DevOps is not about tools only.

A thoughtful roadmap to Agile must integrate modernization of legacy systems and infrastructure

Architecture modernization and cloud migration are often intertwined in the context of DevOps. Many large organizations depend on archaic legacy systems, which constrains speed to market. A thoughtful roadmap to Agile must integrate modernization of legacy systems and infrastructure.

There is no bigger symbol of Agile than removing cubicles

(5) Organizations are re-designing the workspace for Agile. Agile teams want to work in new environments. New workspace design encourages collaboration, idea sharing, and conversations. People want to write on the walls, share progress, and mock up ideas. They should use fewer presentations and more designs. Modern workspaces reduce siloes, and eliminate cubicles and individual offices. In the beginning it is difficult, but over time people become liberated. They embrace it as an invigorating cultural change. Once companies remove the cubicles people believe they are serious about Agile. There is no bigger symbol of going Agile than designing a new space. As a side benefit, modern environments contribute to attracting and retaining top talent.

Yet, many challenges to adopting Agile remain

(1) Agile has an identity crisis

Is Agile a framework, mindset, tool, technique? Organizations still face a challenge describing Agile to its constituents. Advisory firms also struggle with the same question. First, there is no "standard" Agile that fits all organizations. Companies must decide what works for them.

Agile is the thoughtful integration of practices to improve business outcomes

Second, companies must be relentless about outcomes. Organizations must be clear what they want to achieve, from a business perspective. And then work backwards to which Agile will help them get there. Third, organizations must be clear what Agile is not. Agile is not about migrating requirements to user stories. It is not about daily meetings. It's not about cross-functional teams. Agile is the thoughtful integration of practices to improve business outcomes. I get scared when I hear organizations claiming to be Agile because they are logging user stories in Jira. We have to be relentless about measurable business outcomes, not processes.

(2) Organizations are struggling with practical impact of Agile

There are many key questions to discuss and solve for. How do we find and groom Product Owners? How will people with different seniority work co-located in same team? What does Agile look like in a distributed corporate environment? How can line managers let go of their resources (e.g. developers, testers) so they work in Agile team? How long should permanent teams exist? How can someone with higher pay grade work for a Product Owner? Do people report to Scrum Masters? How do maintain morale in teams that are not Agile? What does Agile look like for legacy or BAU teams? Can you design for corporate functions (e.g. HR, Finance)? How to measure employee performance in Agile world? Will compensation change for Agile team members? Will people lose their desks if they move to co-located space?

These are real questions every organization is facing with Agile. But you don't have to address them at once. Organizations can learn with time and adapt. Some people will resist Agile, but either they will be late adopters or there won't be a place for them in the new world.

(3) How to avoid "half" Agile ... and how to scale

Once organizations go through first Agile pilots they will focus on how to scale. How to take it to other business units, corporate functions, legacy teams. At this point it is critical to integrate Agile enablers. First, technology enablers, such as DevOps, will "turbo charge" Agile and extend it to IT Ops. At the same time modernizing legacy applications and infrastructure. Migrating to more modern web and mobile frameworks is one option (e.g. Nodejs, React, hybrid mobile frameworks). Also migrating to private and public cloud will help speed up development and reduce costs. Second, re-designing the environment can be your biggest friend to migrate to Agile and attract top talent. Third, stay focused on business outcomes in a measurable way. Enable business experimentation to de-risk and add value incrementally. Each Agile team member should know which business goal to focus on. Team members should be data-driven and be hungry for proof that they are doing the right thing.

The pragmatic integration of these practices is instrumental to scaling Agile. In fact, organizations should not scale Agile unless the right foundation is in place.

Photo by Pascal Swier on Unsplash