When you’re trying to convince your organisation’s leadership or your customers to invest in enterprise agility, you need to highlight the many advantages it has to offer.
Increasing agility
One of the advantages of enterprise agility and iterative, incremental product delivery is that they enable organisations to respond quickly and creatively to all sorts of changes, including the following:
- Evolving customer needs
- New technologies and approaches
- Emerging opportunities and threats
- Changes in the industry and marketplace
Although large organisations can certainly plan ahead to respond to change, change often occurs at a rate that exceeds the ability to plan for it. Modern organisations need to be agile to keep pace with the rate of change.
Boosting innovation
Enterprise agility drives innovation in numerous ways, including the following:
- Solutions involve collaborative input from customers and developers, who are the closest to the product, opportunistically merging business and technical perspectives.
- Developers work from user stories instead of detailed requirements, so they have more freedom to develop innovative solutions, adapting just in time to the current context and new insights.
- Developing product increments enables everyone to interact with working versions of a product, which sparks more creative ideas. That also enables more responsive “steering” based on current feedback.
- Cross-functional team members have broader knowledge and skillsets, so they can synthesize and contribute ideas beyond their traditional areas of expertise.
- Given more creative freedom and the authority to make decisions, developers have a greater personal stake in the product and more motivational drive or incentive to create awesome products.
Enhancing transparency
Traditional product delivery is almost like a submarine mission. The process remains hidden for the most part, so problems are rarely exposed or addressed, and there are missed opportunities for contemporaneous guidance or steering.
Enterprise agility increases transparency in several ways, including the following:
- Customers can review the product at the end of each product development cycle: for example, at the end of each two- to four-week sprint. Customers see their products improve incrementally.
- Small, cross-functional teams work on smaller areas of a product and test the product frequently, so their work is constantly scrutinized.
- Most teams use Kanban or a similar system to visualize workflow, which improves visibility into workflow issues, such as incomplete work items and bottlenecks. (Workflow visualization also enables managers and other
stakeholders to monitor progress without requiring teams to waste time building progress reports.)
- Enterprise agile principles emphasize transparency and learning from failure to encourage employees to be more open about mistakes, missed opportunities, and areas that need improvement.
Boosting productivity
Enterprise agile transformations almost always result in increased productivity, most of which comes from Lean thinking and systematic, global workflow optimization based on queueing theory. Most teams don’t realize how much time they spend waiting for others to finish their tasks. No employees in the organisation like to look idle, so they engage in other activities, such as reading tech journals or researching ways to improve the product — activities that deliver little or no immediate value to the customer.
Don’t underestimate how well people can make themselves look busy when they’re really not delivering any value to the customer. Watch out for teams that have several hours of meetings each day or team members who are working on individual tasks that are not clearly linked to the product.
Making product development more fun and rewarding
Enterprise agility makes product development much more fun and rewarding in the following ways:
- Development teams have more creative freedom.
- Teams have less management oversight, spend less time in meetings, and waste less time keeping management posted of their progress.
- Team members are continuously acquiring new knowledge and skills, learning from each other, improving their mastery and make their teams more cross-functional.
- Team members work more collaboratively, feeding on each other’s creativity, leading to more productive synergy.
- Iterative product development gives teams more opportunities to celebrate their wins and learn from their experience. Instead of feeling as though they’re pushing a boulder up a mountain, they can celebrate each time they roll a pebble up a hill.
-
Strengthening customer relationships
Product development can create an adversarial relationship between your organisation and its customer. The customer wants the maximum value at the lowest cost, whereas your organisation wants to maximize its profit. Enterprise agility can improve your organisation’s relationship with its customers in two ways:
Customers collaborate with developers on the product, so they build a deeper connection.
Budgeting can be more flexible. Customers and developers collaborate to create a prioritized list of features, which can then be gradually built and integrated into the product as the customer’s budget allows.
With traditional product development, budget disputes can often make the customer feel that your organisation isn’t aligned with its goal of creating a spectacular product. With enterprise agility, everyone agrees that the product should be spectacular and works toward that goal until the money runs out or the customer decides that the product is spectacular enough.
Enhancing product quality
Several agile practices are designed specifically to boost product quality, including the following:
- Cross-functional teams exchange information through open and honest communication, exposing problems instead of obscuring them.
- The definition of “done” ensures that the product has been tested and fully inspected by at least two people, for example, and that it has met all agreed business and technical criteria for release.
- Automated testing ensures timely and rapid quality verification throughout the development process without any additional time or effort required of the team.
- Continuous integration ensures that developers merge their completed work and test it frequently to identify and address integration issues early on.
- Test-driven development (TDD) or test-first development deters developers from writing any more code than is required to enable a feature to fulfill its function, ensuring cleaner code. It also encourages everyone to get clarity on acceptance criteria before writing code.
- Pair programming requires that programmers write code in pairs, so one programmer can focus on writing the code while the other offers guidance and checks the work. This has a strong, positive effect on code quality.
Making product delivery more predictable
An organisation’s leaders often fear enterprise agility will make product delivery less predictable because it does away with a lot of the upfront planning. However, developing product increments in short cycles actually makes product delivery more predictable. Anyone who wants to see the status of the product development can just sit in on one of the review meetings, or peruse the Kanban boards or other real-time project information radiators.
With traditional product development, organisations often waste a significant amount of time drawing up plans that they later discard when something changes that makes the plan obsolete. In fact, managers often build buffers into a plan, because they’re relatively certain that development won’t go according to plan and they’re likely to miss the deadline by weeks or even months.
There are now many sources of empirical project data confirming that — on the average — agile product development results are more “in control” than similar development using traditional waterfall methods.
Reducing the risk of failure
Software projects can fail for a number of reasons, but one of the most common is a disconnect between what the customer wanted and what the team delivered. Enterprise agility reduces this disconnect in two ways:
Short product development cycles, such as two- to four-week sprints, give customers more opportunities to let the development teams know whether the product they’re creating is on track, and frequent opportunity to influence and help steer continuing efforts.
A customer representative or product owner communicates the customer’s needs directly to the team. With traditional product development, customer needs are typically relayed to the development teams by someone in the organisation who’s outside of development. Having an actively engaged product owner as a part of the team ensures that the product will meet the customer’s needs.
Improving developer discipline
An agile team must stick closely to the work items it committed to completing during any given product development cycle. Together, the product owner and the team agree upon a group of high-priority work items and then the team decides how to complete those work items.
If the team thinks other work is a bigger priority, it must convince the product owner that this work will deliver value to the customer. A good product owner will push back and ask tough questions such as, “Why do you need to do this now?” and “What happens if we don’t do it?”
This push and pull between the product owner and the development team keeps everyone honest and makes all of them more focused and disciplined in their work. In the end, this inherent conflict and close collaboration usually result in a higher-quality product.
Overcoming Enterprise Agility Obstacles Related to Your Organisation’s Culture
Your organisation’s existing culture can create a great deal of inertia that your organisation needs to overcome in order to change direction and move towards enterprise agility. In fact, an inability to change an organisation’s culture is one of the leading causes of failed enterprise agile transformations. Here, you learn how cultural factors can undermine an enterprise agile transformation, and I provide guidance on how to overcome cultural inertia.
Seeing how culture can sink agile
According to an annual survey conducted by VersionOne on the state of agile, the number one challenge companies face when they attempt an enterprise agile transformation is “Company philosophy or culture at odds with core agile values.” Number four on the list is a “General organisation resistance to change.” Further down at number six is “Insufficient training.”
Most organisations understand and are willing to embrace a more agile mindset. The real challenge is overcoming cultural inertia. The organisation wants to adopt enterprise agility, but agile conflicts with a deeply engrained incompatible mindset.
Acknowledging the challenge
The first step to overcoming cultural inertia is to confront it. Many teams try to change culture through training. They think that once individuals understand agile they’ll be more likely to embrace it. Unfortunately, more training is rarely the solution. Even when all employees in the organisation understand agile and appreciate its potential benefits, they often feel that it’s not a solution that’ll work in their organization. They lack faith.
If you think about it, this feeling makes a lot of sense. A lot of organisations have a strong control culture. Some of agile’ s key values may be in direct opposition to long-established practices. A culture that puts a lot of emphasis on hierarchy and accountability, for example, is going to have a tough time embracing self- organised teams and distributed authority.
Prioritizing the challenge .
When you start your agile transformation, make culture your number one priority. Agile teams always begin with the highest value items first. Training is number six on the list of common challenges, and culture is number one. It’s clear that you need to start with culture. Your effort here will make or break your enterprise agile transformation.
Build on your success. If you’re considering an enterprise agile transformation, you already have at least one agile team in your organisation, and now you’re looking to scale agile to work on larger projects. Leverage the success of your existing agile team(s) to drive cultural change throughout the organisation.
Gaining insight into the motivation
Managers and developers often clash on the enterprise agility battlefield because their motivations differ. While management often embraces big organisational change and enterprise agile frameworks that promise improved productivity, quality, and customer satisfaction, developers often want management to get out of their way so they can do their best work.
Management
High-level managers are the first to embrace big changes. It’s not because they’re less conservative or more adventurous. It’s because they’re evaluated by how well they improve the organisation’s processes. When they can take a group of people and change the process to improve results, they see that as good management and strong leadership. Large frameworks, such as Scaled Agile Framework (SAFe) and Large-Scale Scrum Huge (LeSS Huge) are like catnip for these high-level managers.
Developers
On the other side, software developers and engineers see themselves as craftsmen. They want to build something that’s elegant and satisfying, and they often view a large framework as a way for management to gain more control over their work. If you’re a craftsman, the last thing you want to do is create something ugly because someone forces you to make a quick fix.
Large-scale organisational changes often create tension between managers who want to rewire the machine and developers who want to create a world with fewer wires. Developers want agile, and they may think of enterprise agile as an attempt by management to make them less agile.
When you’re starting your enterprise agile transformation, take a long objective look at each of these groups’ motivations. If you have a manager who wants to make big changes, prepare yourself for a lot of communication and pushback from many of the developers. If the change is driven by developers, be prepared to convince the managers that this is a worthwhile change.
People often assume that others share their motivation. Managers assume everyone wants a big framework, while developers assume that everyone in the company wants (or should want) to deliver beautiful, elegant software. The truth is that the two aren’t mutually exclusive. You can have a large framework that provides developers with the creative freedom they crave.
Whether you try the Kotter approach or Fearless Change, think about your organisation and how each group feels about the change. Both approaches push you to better understand everyone’s motivations so you can mitigate resistance and avoid unpleasant surprises.
Enterprise Agility and the DA Process Decision Framework
DS (Disciplined Agile) is based on the premise that every organisation, team, and individual is unique, so frameworks should offer choices, not prescribe solutions. It helps organisations ask the right questions, and for each question, it provides a set of answers (solutions) from which to choose.
That’s much different from more prescriptive enterprise agile frameworks with clearly defined processes, meetings, and roles. For example, the Scaled Agile Framework® (SAFe®) introduces the idea of the agile release train (ART) and Large-Scale Scrum (LeSS) creates several new meanings for planning and conducting retrospectives. Disciplined Agile Delivery (DAD), on the other hand, doesn’t require specific meetings, and the roles involved are probably already in your organisation.
DAD represents all the practices centered around enterprise agile product delivery, whereas DA casts a much wider net and is more attuned to business agility. In addition to product delivery, DA covers marketing, sales, governance, legal, and human resources (HR).
Disciplined Agile Consortium. Reproduced with permission. The Disciplined Agile framework goes beyond product delivery.
Think of the difference between DA and other enterprise agile frameworks in terms of baking a batch of chocolate chip cookies. A prescriptive framework such as SAFe would provide a list of ingredients and step-by-step instructions. DA, on the other hand, would describe the size, texture, and flavor of the cookies and offer some general guidance, such as “all ingredients must be mixed in the right proportions, and the mixture divided and heated.” The pastry chef would then be free to choose the ingredients and quantities, decide how to mix them and how to divide the mixture and figure out how to heat it to produce the desired final product.
Small- to medium-sized organisations may find the DA approach unsatisfying, but it may be the perfect fit for large organisations, where many different teams are trying out different agile ideas. Instead of telling people how to do their jobs,
you set common goals and leave it up to the teams to decide how to meet them. You specify the what and let your agile teams address the how.
Unfortunately, giving people so many choices and then trying to educate them on how to make the best choices is often much more challenging than simply giving them a uniform process to follow. The sheer number of choices can boggle the mind.
DA can become agile quicksand in that the more you struggle, the deeper you get sucked into the framework. When starting with DA, take a very high-level view. Steer clear of the goals and milestones and focus on the higher-level processes — the DAD principles, primary roles, secondary roles, and the three-phase delivery lifecycle.
If you have any questions you can mail us at [email protected]
