For years businesses have been practicing agile, seeing notable success in time to market, productivity and creativity at the team level. Now they want to expand the scope of those benefits.
If you asked development teams a year or two ago to identify the biggest agile obstacle, most of them would have said getting management on the same page, according to Bill Portelli, CEO of CollabNet. But as management is beginning to understand the process, they are looking to leverage it even more.
“Agile is graduating from a discussion of what Forrester calls efficacy,” said Portelli. “Yesterday’s agile was more about Continuous Integration and user stories, and now it has emerged into what the executives want to see. They are interested in business outcomes and value streams.”
(Related: Agile requires a transformation)
To get more out of agile, businesses are starting to scale it from the team level up to the enterprise. Scaling agile is different in an enterprise context, according to Lee Cunningham, director of enterprise agile enablement at VersionOne. According to him, at the team level, scaling agile involves adding additional cross-functional teams around a common business or product goal, whereas scaling enterprise agile includes operational, financial and cultural aspects. Enterprise agile also emphasizes individuals, interactions, working software, responsiveness to change, and customer collaboration.
“There is a difference between scaling agile and enterprise agile,” said Cunningham. “Scaling simply means we are adding some agile capacity, and you do that without really affecting the entire enterprise. We see a lot of enterprises that are scaling have a lot of teams, but their entire business enterprise isn’t really brought into the principles and practices. You can certainly have scaled agile without being enterprise, but if you have enterprise agile, it is certainly going to involve scaling.”
The business and business agility
The reason why so many organizations are starting to transform their business to agile is because it is becoming a safe bet, according to Ryan Martens, founder and CTO of Rally.
“It is obvious it is working,” he said. “The capacity and experience of people in our industry have gone up as we have been at this for a good solid decade. And there are more people who have some real success under their belt that gives organizations confidence in being able to move forward and make a commitment. They got the right people, they’ve seen it work and they feel pressure to move.”
Transforming an entire business to agile takes time, persistence and money, so why are more businesses going through with it? It is worth the headache in the long run, according to Chris Hefley, CEO of LeanKit.
“In any organization, being agile is a business decision,” he said. “When implemented well, agile can provide faster innovation, cost savings, risk-management advantages, and better organizational alignment toward a common purpose. Taking the values from the Agile Manifesto and applying them to other parts of the organization can have similar benefits.”
Businesses are starting to realize that there is a disconnect between how they deliver their products and services and how they are thinking about business in general, according to VersionOne’s Cunningham. “We look at agile not as an enabler of software development as much as we look at it as an enabler of the business,” he said.
“Bringing those concepts of individual interactions, focusing less on utilization and more on throughput, focusing less on projects and more on products I think is where the business mindset is going, and agile is a means of delivering products and services as a natural fit for that.”
It really is about adaptability, according to Eric Wittman, general manager of developer tools at Atlassian. With the market changing so quickly, organizations can respond more quickly and be relevant at the same time, he explained.
“At the end of the day, it is about delighting customers, and the way you delight customers is you deliver more stuff to them faster, and the stuff is actually more relevant to what they want,” he said.
How to scale enterprise agile
While agile at the team level has had proven successes, those successes are small compared to having agile at the enterprise level. An entire enterprise agile transformation is not easy; there is no one-size-fits-all approach when it comes to scaling enterprise agile, but there are some important factors organizations should understand when it comes to the transition process.
“It is not really about the destination; it is about the journey and how do you sustain that for a long period of time,” said Rally’s Martens. “The way to get the business agile is to get it to focused on a culture of continuous innovation and continuous improvement. That’s probably the only way because you can’t get there overnight, and where it is constantly moving as the tools and the organizational structures and the ways in which we do stuff are constantly changing as the technology is changing. It is kind of a never-ending hill climb.”
While scaling agile can be arduous, there are certain things experts recommend a business do to make the transition process easier on the organization and its employees. Those recommendations include:
Leadership needs to embrace the change. When an organization undergoes a transformation, it is important that the leadership stands behind it, according to VersionOne’s Cunningham. “Not only buying into it, but also being able to express the vision so people understand not only that we are making a change, but why we are making this change and why it is important,” he said.
According to LeanKit’s Hefley, if management doesn’t own agile, then an organization risks making only localized improvements to a small part of itself, which are unlikely to last. “The best ways to gain management buy-in are to clearly articulate the business benefits of agile, provide greater visibility and predictability, and then prove it with data,” he said.
Figure out where you want to start. Some organizations make the mistake of biting off more than they can chew, according to VersionOne’s Cunningham. When starting a transformation, an organization should figure out where it wants to start first.
“More often than not, it is a good practice to identify which sort of vertical slice of the organization we want to pilot this in,” he said. “That pilot, if you will, can experience agile and kind of fail fast and learn real quickly, and then those learnings can be leveraged as we start to expand and scale agile throughout the organization.”
Start small. “You are going to want to start in much smaller bite-size chucks with specific teams or specific organizations that either have done a little of this in the past or they are more attuned to being able to embrace this way of working,” said Atlassian’s Wittman. “If you want to have small successes you can showcase, make them successful and then you can see how that will start to percolate through the organization. And sometimes when people see another team being successful with a new way of working, they will adopt it without you even having to push them. It ends up being much like a snowball effect.”
Customize your process to fit your organization. “Where people fail the most is they will take a framework, and because it is documented and it feels really comfortable, they will say ‘This is our process,’ and they will try to use that process verbatim instead of customizing it to their organization,” said Steve Elliott, founder and CEO of AgileCraft, a provider of software for scaling agile in enterprises.
Have an open platform. “You really need to be able to adopt any type of agile or any type of development process or any type of tool framework,” said CollabNet’s Portelli. “Have a tool chain and process that is adaptable to whatever your business needs are.”
Don’t let the tools drive the process. Organizations that start by finding the tool first and then the process are scaling enterprise agile backward, according to Elliott. “The tools should not drive the process, and the limitations of the tools shouldn’t dictate how you are going to run that process,” he said.
“It should be based off the frameworks you are using and the decisions you’ve made on how you want to take agile to your organization and drive it through. The tooling is not going to make you an effective organization in and of itself; it can highlight problems and it can help, but you really need both.”
Take a holistic view. “Taking a holistic view of the organization as a system and approaching all problems as system problems, rather than people problems, will align people and management toward improving the underlying system,” said LeanKit’s Hefley.
Create a culture of collaboration. “What you want to do is make it easy for people to find code—code meaning all the business aspects and all the outputs—and at the same time you want to have it backed by a community,” said Portelli. “You want to have it backed by people who have passion and vision that will help you. The context is having all the history.”
According to Hefley, people need to have a shared vision of the work, frequent conversations about the work, and clear guides of risks and potential roadblocks.
Have feedback loops. “By quickly delivering small chunks of value, teams can adjust according to what they’ve learned and pave the way for greater speed to market, innovation, and risk-management potential,” said Hefley.
Seek out help. “Moving to agile is hard, not only for your software development teams but for all teams,” said Atlassian’s Wittman. “It takes time. If you are an executive or management or on a team yourself, and you want to embrace this new way of working, seek out great examples where companies have been successful and use those as sort of catalyst for change. But also be patient because it does take time.”
Provide a rhythm. “A regular heartbeat of delivery aligned across multiple teams can focus the organization on delivering value with the most coordination and fewer delays,” said Hefley.
Think about the transformation in phases and be patient. “If you try to reorganize an entire organization, change the way you build software and expect all of that to happen overnight, then that is one way to fail,” said AgileCraft’s Elliott. “You have to do the transformation in phases. There has to be some thought on how you are going to transform the organization, and it can’t be a three-month timeframe. It has to be over a couple of years where you get the framework in, you get the tools in, you get some success within your organization, and you figure out how to transform the process, tools, organization and how people work together.”
Rally’s Martens advised figuring out a way to turn the transformation into a road map, and finding some reasonable incremental changes that can be made along the way as milestones.
Does your approach work for your business?
When it comes to agile, there are many approaches an organization can take. It can use lean, Scrum, Kanban, pure agile or hybrid agile.
“I often say that agile is like ice cream,” said CollabNet’s Portelli. “Some flavors of ice cream don’t work for your business. In fact, most of the organizations we work with at scale are at best 50% agile and then 50% something else.”
Deciding what practice to pick depends on the business and its goals; what may work for one organization may not work for another, and that can be tricky because it is hard to tell what method to take, according to Ken Schwaber, founder of Scrum.org and co-developer of the Scrum process.
“There is no real measure in the standard business sense of, ‘Did you guys do well with that initiative with all that money you spent on Scrum or agile?’ ” he said. “This is problematic for me in particular and everyone in the agile initiative because we are starting to see lots of fads coming in, and some may be good and some may not be good, but there is really no way to tell.”
Enter evidence-based management of software development organizations. Evidence-based management started in the medical profession to distinguish between circumstantial and direct evidence, said Schwaber.
“So we started taking that same idea saying, ‘Hey, what if we did the same thing with software?’” he said. “We could have something called evidence-based management where we differentiate between circumstantial evidence like lines of codes or story points and number of bugs found, and direct evidence, which would be measuring the outcomes of software organizations rather than the internal operations of them.”
The importance of evidence-based management is the ability to collect direct measurements of outcomes when an organization introduces a new methodology or tool. It devises a set of measurements that would reflect a value that software is delivering to the organization, and it measures the change in value to the organization, according to Schwaber. It is the process of evaluating current valuable outcomes, selecting the outcomes to improve, identifying the practices that will create these improvements, implementing those practices, and evaluating the results.
“Suddenly software is critical for the way businesses compete and the way our society interacts and works, and that’s no longer an expense,” said Schwaber. “That is something which you survive or fail with, and we are getting that pressure from our customers that they want to know what the best thing to do is, and they want some proof.”
The three primary measures of evidence-based management for software development organizations are:
- Current value: How many dollars of revenue an organization is generating per employee, and how likely the employees are going to continue creating value and customer satisfaction. “That’s an okay set of measurements for any organization at any point in time,” said Schwaber. “The problem is we had companies that had great current value that folded within five to 10 years. Company after company that just did great, and then five years later they were broke. So we added two other legs to this value that we are measuring: time-to-market and ability to innovate.”
- Time to market: The ability to bring new features, functions and products into customers’ hands.
- Ability to innovate: Having a great company, being able to deliver products fast and having great current value can be meaningless if an organization can’t come up with sound ideas, according to Schwaber. The ability to innovate looks at a business’ entire product development budget, the percentage that goes to maintenance, the usage index, and defect density.
After all the measurements are taken, they are added together into a weighted calculation called an agility index. The agility index reflects the state of an organization’s value overall and in the marketplace, according to Schwaber.
“We take all these metrics and we add them together into one number that is called an agility index, and it is a number from 1 to 99.9,” he said. “It is most heavily weighed toward current value because obviously we are interested in the final outcome rather than your time to market, or ability to innovate, but it has all three of them amalgamated into one number, which hopefully goes up.”
An agile and waterfall approach
If it is possible to do a pure agile approach, said Emmet B. Keeffe III, CEO and cofounder of iRise, it is always his company’s recommendation to do that. But for projects that just can’t get there, he said a little agile is better than no agile at all.
“At the moment, we’re seeing a certain type of project where agile can be done. They’re the mobile projects and the digital Web projects. They’re very specific,” he said.
“But that only represents about 10% of a company’s software portfolio. How do we bring agility into customized billing or call center projects, to scale it across the portfolio? You have to leverage a hybrid approach. We are seeing a lot of organizations land on sort of a hybrid methodology which is part agile and part waterfall.”
Keeffe’s company iRise uses computer-aided simulation to help make its definition and design phases agile.
“I think it is an easier transformation because what you end up doing is putting the production of the simulation and the collaborative design process at the front end of waterfall, but the rest of the waterfall process you leave relatively untouched,” he said.
“Maybe we shouldn’t talk about ‘agile.’ The right word is agility. That’s what the business wants. Taking English out of the requirements definition process brings agility. That’s what we’re talking about in the world.”
