Framework and standards are the ‘Essence’ of agile at scale

Since its creation, the agile software development methodology has been increasing in popularity. With its almost universal use, agile has now become less of a different and new methodology and more just the way developers operate. In other words, it is now standard practice for most teams to be using agile.

With that in mind, we must ask the question: where does agile go from here? Is agile at its end, or is there more room to grow?

In a talk given by Ivar Jacobson a few months ago in St. Petersburg, Russia, the man best known as a father of use cases, UML and Rational Unified Process posed the following question to the audience: Are we driven by fashion? He spoke about the history of software development methodologies and how we have followed a zig-zag path moving from one to another throughout the years.

Twenty-five years ago, everyone was crazy about object orientation, Jacobson explained. Five years later, the focus was on components. Techniques such as UML and Rational Unified Process were widely used. Fifteen years ago all of the major companies were using CMMI. Finally, we got agile, and now, agile at scale, he said.

Jacobson discussed the most adopted method frameworks for scaling agile, which are SAFe, Nexus, Disciplined Agile Delivery, and Large Scale Scrum. SAFe is the most widely used of those, he said. “These methods all bring something good to people who adopt them,” he said. “That is not the problem. So what is the problem?”

He cited six problems with these methods in his talk:
1) We are at methods war for 50 years
2) Practices are locked in method prisons
3) Method prisons are controlled by method gurus
4) All methods are monolithic
5) Every method’s description is home-grown
6) Methods have no common ground
“This,” he concluded, “is immature and foolish.”

“Take for example point 2. Every method is just a composition of practices. Examples of practices are user stories, continuous integration, DevOps, microservices, pair programming. The problem is, they are not separated. They are all in one soup, all integrated more or less tightly. You can’t take out one practice and replace it with another. Since they’re locked in the prison, you can’t take out practices and reuse them in another context. It is not very practical. The specific practices are described in a language that is method specific, embedded in a soup that is the method’s.” He said “it is immature and foolish.”

In his talk he described how all these problems could be eliminated by the new OMG standard Essence, which is a common ground for software engineering methods. His company uses this platform to address these problems with the additional key values being that methods are significantly easier to learn, adopt and change. “Moreover, he said, you can measure progress and health of your endeavor in a method-agnostic way and your organization becomes forever learning.”

In a press release in December, Ivar Jacobson and Jeff Sutherland, co-creator of Scrum, announced that Scrum has been “Essence-ized” to provide Scrum with a navigable glossary. Similarly, Scott Ambler, the founder of Disciplined Agile Delivery, is working with Ivar Jacobson International to bring Essence to key practices in his method.

Jacobson said that SAFe is a very important part of the consulting side of his business. “SAFe has a lot of values, and it really helps many organizations,” he said. “And, it has the potential to become even better if adopting Essence.”

According to a report created by cPrime, Scaling Agile Report 2017, 45 percent of respondents chose SAFe as their framework of choice for scaling agile.

According to its website, “The Scaled Agile Framework (SAFe) helps businesses address the significant challenges of developing and delivering enterprise-class software and systems in the shortest sustainable lead time.”

“SAFe is a very prescriptive way of enterprise planning and reporting,” said Matt Schenck, Global Solutions Engineering Manager of Atlassian in the Scaling Agile Report. “My take, after working with many of our customers, is that many folks who say, ‘we’re doing SAFe’ are really just trying to do portfolio management for Agile. Metaphorically, if I have a papercut, I’d say I’m using a Band-Aid, but it might not be a brand specific adhesive bandage. More specifically, companies are struggling to scale Agile beyond teams, and are borrowing many of the key principles of SAFe without fully committing to the entirety of the framework.”

“SAFe provides a way for organizations to take large scale initiatives or important products and take them to market sooner with the right features,” said Zubin Irani, CEO of cPrime, a SAFe Gold Partner. “It allows organizations to align all of the teams needed to pull that off.”

“I would say that what makes SAFe unique is the breadth of coverage from team to program to portfolio,” said Dean Leffingwell, created of the SAFe Framework and its chief methodologist. “Enterprises don’t just want to have agile teams, they want to be an agile shop.” In other words, it’s not really effective to just have a few agile teams within the organization. The whole organization should be practicing the agile methodology.

Leffingwell explains that teams want to be able to evolve more quickly. “That involves things like a portfolio of strategy, turning large epics into smaller initiatives that can run very quickly through the pipeline and be discovered,” Leffingwell said. This is the vertical depth of SAFe, he explained.

The horizontal depth is evolving along with the industry in order to incorporate trends that originally were created and appeared in parallel with agile development, Leffingwell explained. According to him, the first of those trends is lean startup and the second trend is DevOps.

“Massive movement is causing really large companies to rethink the way they organize and make their investments and innovations,” Leffingwell said. He believes that the thirst for innovation is what is driving this initiative. “You see very large enterprises now rethinking how they innovate,” he said.

The DevOps side is all about using “agile DNA to very quickly turn ideas into code,” Leffingwell explains. “Deploying to DevOps practices is a real, relatively unique end-to-end process. From portfolio ideation or program ideation through to release we provide comprehensive coverage for all of that.”

“I actually think agile is going to drive DevOps transformations and all of the tooling required around it,” said Irani.

While it may seem like everyone is using agile, there are still a few sectors such as the defense industry, the medical industry, and large-scale system builders, where agile is still a relatively new idea to them, Leffingwell explains. There is about a ten year gap before practitioners in those industries become part of an agile team, he said.

“I would just guess that if I walked into an average large shop of any kind, you’re probably going to have 10 to 20 percent of the people really executing agile and 70 or 80 percent still waiting for permission, waiting to finish a program, or change administration or management, and so on,” Leffingwell said.

Leffingwell said that one of the challenges organizations face when trying to scale agile is getting everyone in the organization on board. Teams can decide they want to adopt an agile methodology. They can say “we’re going to talk about this more frequently, we’re going to plan, we’re going to get feedback,” Leffingwell explained. “Well, you go one level up in the organization and somebody managing that will say ‘well I need to know what the outcome is before we start,’ and one level above that somebody is looking at a portfolio of programs and saying they need to know exactly how these programs are going to deliver it.”

“The deeper the organization, the harder it is for them to understand this transformation and transition,” Leffingwell said. “I still think it’s very natural for middle or senior managers to ask what they are going to get out of agile and when they are going to get it. It is the most natural question you can ask.”

Another challenge that organizations face when trying to scale agile is that it’s a massive commitment, the scope of which is not always understood by everyone involved, said Irani. “A lot of people think they know what scaling agile really means, but then in actuality they don’t really know,” said Irani. “I think they go into a transformation thinking they have a clear picture of what that is gonna look like and then when they get into it they realize they were completely misjudged. So a lot of it is just education, from the top to the bottom level, and I think that’s where people struggle.” He goes on to explain that the knowledge gap between what executives and team members or staff want is quite large.

Irani explains that technology challenges can add to this misunderstanding. There is a large amount of technical data and tooling involved with can add to the confusion, he said.

According to cPrime’s Scaling Agile Report 2017, a lack of general understanding was the biggest reason that organizations were prevented from scaling agile, with 34.8 percent of respondents citing this as a factor.

The same report indicates that company culture makes up for 65.6 percent of the roadblocks to scaling agile and lack of experience with Agile accounts for 45.6.

“I’ve seen organizations say they’re Agile, yet still make their teams conform to all the waterfall phase gates without modifying them for the Agile process,” said SAFe expert and trainer
Ken France, CEO of Blue Agility, in the report. “I’ve also seen where they still require integration and user acceptance testing at the end, which means…they always have a large slowdown at the end.”

“I think much of the challenge is still ahead of us,” Leffingwell said. “The buzzword is accepted, but the real agile behaviors in the larger enterprise are still mostly to come.”

Agile estimation is the key to a successful SAFe implementation
With all of the benefits of SAFe, getting it right is key. Using agile estimation can help.

“For organizations that are implementing SAFe, they’re really trying to coordinate a lot of different stakeholders within the organization and the real benefit they’re looking to get out of it is a much more nimble delivery,” said Larry Putnam Jr., co-CEO of QSM. “To be able to do that, we’ve got all these different stakeholders that we have to coordinate. That becomes really complicated and estimation is kind of the communication vehicle for these different stakeholders.”

Putnam explains that the highest level of an organization is the business and its stakeholders. The stakeholders or senior managers within an organization need to ask in what direction the business needs to go and how software will support that. These needs are usually articulated at a high level, said Putnam.

“Those are going to get apportioned across different value streams, and they’re really looking at the whole portfolio of what’s going on within the enterprise,” Putnam said. “In order to implement all those capabilities the business wants, you’ve got all these different cross-functional teams that are working on different pieces of the system.”

Putnam said that there is a minimum capability, usually referred to as minimum consumable value, that businesses need before they will go through all of the overhead of a formal release.

Businesses need to translate what they need at that high level into what systems they need to utilize in order to get that value. “Estimation, then, allows you to take that high-level scope and figure out: What is the duration that I could deliver that within and what is the cost to do that?” Putnam said. Business won’t fund two-week iterations at a time, Putnam explained. They will fund projects based on major capabilities that will be released and entered into production. “That is really where estimation is crucial because it can help you figure out what is the appropriate timeline for those teams to implement all of the things that meet the strategic goals of the organization so that they can do their budgeting and planning at that level,” said Putnam.

He went on to explain that within organizations there is a natural tension between people at the low-level, such as developers, and those at the enterprise-level. He explained that agile estimation can provide a buffer between the two groups by getting everyone on the same page.

Both groups must know what is needed and what a reasonable timeframe for it is.

“Estimation allows you to figure out for all of these capabilities the business needs, what the resource demand is that’s going to be required to deliver that, and how that matches up with the capacity that’s available within the organization today,” Putnam said.If the strategic direction that we are going in in the future requires different types of labor, estimation can help us figure out what are the types of people that I need to be going out and looking for and hiring to support the demand in the future,” he said.

“It’s all about coordinating and trying to get the benefits you’re looking for through this continuous delivery concept. I think one of the things about agile that has been attractive is that it takes a lot of this process away from the teams and allows them to spend more of their time delivering value to the client,” he said.

“Any time you are trying to roll things up to an enterprise level, there’s a certain amount of process that you have to bring back in to coordinate all these different stakeholders and drive out the risks associated with deploying something across the entire organization. I think estimation and metrics and measurement play a big part of that in helping you manage that enterprise implementation and transition,” according to Putnam.

He explained that it’s important to be able to quantify what benefits you are getting over time. “Are we getting our releases out more timely? Are we becoming more productive? Are we delivering better quality systems over time? Measurement and estimation allows you to answer all those questions. And those are generally things that the senior people in the organization are asking and care about.”

Other scaling frameworks available
Nexus: Nexus is a framework based on Scrum that is used for scaling Scrum. The framework guides multiple Scrum teams on how to work together deliver results in every sprint. It uses an iterative and incremental approach to scale software development.

Disciplined Agile Delivery: The Disciplined Agile Delivery framework provides guidance that helps organizations streamline processes and provides a foundation for business agility. It shows organizations how different business activities interact with each other. Disciplined Agile Delivery explains what those activities need to address and provides options for doing that.

Large Scale Scrum (LeSS): Large Scale Scrum offers two different frameworks for scaling agile. LeSS focuses on directing the team’s attention onto the product as a whole rather than on individual parts. LeSS is designed for up to eight teams, each with eight people on it, while LeSS Huge is designed to work for up to a few thousand people working on a product.