DEVOPSdigest

If you are old enough to have watched "I Love Lucy," you likely recall the famous chocolate factory episode in which Lucy and Ethel were fighting a losing battle to package more chocolates. Lucy's major problem with the task was simply that she didn't have enough people helping her. And that's mostly true with manufacturing. Factories scale well and have a strong tendency to get more efficient as they get bigger.

So why is it, then, that building software seems to have the opposite effect of reducing efficiency as you scale up?

Dean Leffingwell, the creator of Scaled Agile Framework (SAFe), summed it up quite well. He noted that building large scale systems is fundamentally a social event – not a manufacturing event.

In fact, you could make the case that Agile at its core was the first realization of that. Consider what Agile represents:

■ Individuals and interactions over processes and tools

■ Working software over comprehensive documentation

■ Customer collaboration over contract negotiation

■ Responding to change over following a plan

But remember, Agile originally was predicated on small – not big. And to get the most out of people in a large social event, you need an underlying structure. For example, you may not have thought about it, but big sporting events, large conferences and weddings all have quite a bit of structure. A football game has four quarters and halftime. Conferences have keynotes and sessions. But software development doesn't have structure. People don't walk into a large organization and intuitively know how to participate in the social event of building software. To date, there simply hasn't been an underlying structure.

It is possible, however, to have a repeatable underlying structure to the act of building large scale software. And that underlying structure is SAFe, which was predicated on the original notions of Agile. And Agile is really the first methodology that articulated that software is about people – a social event. So, by definition, SAFe is trying to apply the principles of people at a much larger scale.

Looking One Layer Deeper

But, even if you believe in SAFe as I do, you still have a high likelihood of failure unless you look one level deeper. Because to bring the structure to life, you also need what I call "currencies for communication." Consider a relay race in which the baton is the sole currency for communication. If it is dropped, then communication is over. The structure of the race is there – but it is brought to life by the passing of that baton – the currency for communication.

Currencies for communication are shared in common for at least a moment, form the basis for communicating and are ever more important as social events get larger. So what are the currencies for communication for scaled software development? The artifacts that are managed in tools – the defects, the requirements, the epics, the stories, the test cases.

And in software, many of these currencies for communication have to "morph." When I pass the baton to the next runner the baton is exactly the same. But in software, I need my top level corporate goals (make more money) to morph into "epics" that then morph into more detailed "stories." And then my stories get decorated with defects and test cases.

Software development, project management and DevOps tools are the holders of the currencies for communication – the artifacts. But different tools came into being by looking at the social event from different perspectives. It is like looking through a prism at the social event. Every tool fundamentally is looking at the software/social event through its own prism.

Each prism is legitimate. In fact, all are needed to have the best possible outcome. But each tool takes a certain perspective: What a software developer needs and the associated prism is quite different from the portfolio manager's prism.

So we've got all these different tools that collectively house all the necessary currencies for communication. But what is fundamentally missing is a way to pass the baton between the prisms with ease and the allowance for morphing over time.

Integration with SLI Strategy

SAFe needs one more piece to "crack the nut" of building large scale software effectively, a software lifecycle integration (SLI) strategy.

A SLI strategy looks at the underlying structure of SAFe, identifies the currencies for communication at the different pass-off points – and ensures smooth passing that allows (and in fact encourages) morphing.

The good news is that SLI Patterns can help. These patterns:

■ Identify the people (roles) at a particular juncture in the social event that need to communicate.

■ Identify the artifact(s) that will act as the currency for communication for that situation.

■ Acknowledge and provide guidance on how currencies might morph and how to maintain the relationships between the currencies.

■ For each juncture, an SLI pattern recognizes that the tooling on either side of the juncture will often be different.

■ Identify the style of communication.

Read: Pass the Baton SAFe(ly) - Part 2 outlining 3 examples of SLI patterns that you will encounter as you embark on your SAFe implementation journey.