Sorry, you need to enable JavaScript to visit this website.

How to successfully scale agile and devops - part 4: driving success with process

How to successfully scale agile and devops - part 4: driving success with process
April 13, 2020

Welcome to my fourth and final blog in the series “How to Successfully Scale Agile and DevOps”. Earlier, we had discussed the importance of scaling Digital/Agile, and the major propositions of the “People” and the “Technology” dimension of driving agile at scale.

In this post, we wrap up this series by taking a deeper look at the third element of this equation, the one that brings everything together – the “Process” dimension. It’s only fitting that this dimension is placed at the conclusion of the series, since it’s the overarching framework within which the People and Technology dimensions operate. As a result, it is perhaps the most vital element when it comes to generating actual business results.

Motivation – The Foundation of Change

We begin with the simple question – how do you bring about agile processes in an enterprise?

As we would all agree, Agile model is more a philosophy and a way-of-life than a methodology with a bunch of steps. Philosophies and ways-of-life can only be adopted by humans and not machines. So, the process aspect is more about driving the change in people than anything else. Hence, the key foundation of a process change at scale is all about motivating people at scale to adopt the defined process.

I’m reminded of the ideas put forth by Daniel Pink in his masterful book “Drive” which perfectly illustrates the gaps in how we motivate and inspire people and offers meaningful solutions to these problems. I’m particularly interested in the three core aspects of the book that have proven invaluable in my own experience. Namely, the idea of autonomy, mastery, and purpose, as the real foundation necessary to drive motivation in any process reform. At HCL, our foundations of the “Process” dimension have been based on these same pillars. My work in implementing these process changes across large organizations have yielded substantive results; whether for one of the banks in the , a large car manufacturer in or the leading digital bank in South Asia.

Foundations of the Process dimension in DevOps has been based on the pillars of autonomy, craftsmanship, and purpose.

Driving Motivation Across Organizations

While many frameworks have proven useful in terms of driving enterprise transformation roadmaps, many of them do not address some key fundamentals relevant to an enterprise journey. Some organizations have adopted models such as Holocracy or Sociocracy in recent years. But we believe that these models are very nascent in their structure and unsuitable for true enterprise-level needs. And more importantly, they haven’t been tested enough in the crucible of the real-world market to prove themselves worthy.

It’s worth remembering that the most effective agile framework doesn’t only tell us what changes need to be implemented but also provides a roadmap and indicators of how to achieve these changes. Therefore, when it comes to implementing changes in Process, the tenets of autonomy, mastery, and purpose, are far more prescient. The methods involved in enacting each of these elements can be surmised as follows:


As Daniel Pink says in his book, “Control leads to compliance; autonomy leads to engagement”. Therefore, to truly make lasting changes, autonomy needs to be rooted in the DNA of any organization and team. This entails a complete redesign of the underlying structures to help empower people. It offers them the freedom necessary in making their own decisions, especially if scaling agility and DevOps is the goal.

While there are various ways for organizations to redesign themselves, in our experience, a combination of organization design constructs from Scaled Agile Framework (SAFe) and the Spotify agile model to elaborate on Team level redesign have proven to be effective mainly due to their simplicity, which is essential when driving change at scale. A key aspect of this simplicity that works in Spotify’s favor is its clean and simple messaging, which manifests as easy terms of the four organizational units – squads, tribes, chapters, and guilds.

By reorganizing people into these groups, we can drive greater efficiency and productivity during the entire development cycle. Squads operate like scrum teams with about 6-9 people dedicated to one feature/capability, operating in an autonomous and self-organized manner. Though it sounds easy, it is by far the most critical and toughest journey in the Agile scaling journey. How do we break large enterprises into a cluster of hundreds or thousands of squads? Two recent experiences from customers in and Switzerland proved that getting an incorrect team structure could prove disastrous where the organization found their velocity slower than traditional models with the additional burden of harnessing a demotivated team after the redesign. Incorrect structures will result in driving high dependencies between squads which will eventually slower the rate of deployment of new features to business. There are two critical learnings to ponder when we redesign organization:

  • Use of business architecture to redesign teams where typically squads are aligned to L4/L5 capabilities in the enterprise business architecture model.
  • Designs and structures need to be agile by themselves. It is critical to continuously measure dependency affinity between squads and redesign Tribes if found necessary.

For one of our customers who were struggling with showcasing improvement in feature velocity post taking an Agile journey even after having set up the organization into squads, just a redesign of the squads enabled us to reduce the release cycle times from 12 weeks to 3 weeks.

The final key learning on Autonomy we had is the notion of “Aligned Autonomy”. Autonomy does not mean that squads can choose their own Agile methodologies, tools and sprint cycles to deliver features. We have seen chaos engulf when large organization drove autonomy literally. Aligned Autonomy would ensure:

  • Common cadence: Squads follow the same Agile methodology across the enterprise or at the minimum MUST align to a common cadence. Common cadence ensures that squads are aligned, ceremonies like Program Increment planning become meaningful, understanding and aligning metrics across squads becomes easier and driving Agility at enterprise level becomes measurable and seamless.
  • Aligned roles and team structures: Standardizing roles across the organization and minimizing them greatly helps in driving autonomy faster. Also, having standard squad sizes help. I know of a customer who drove standardization of squad sizes by designing team tables that could exactly seat only teams that adhered to standard size.
  • Common Tools: If not others, I would advise to have a common tool to track both user stories and tickets when we restructure to squads. As much as possible the CI/CD or DevOps pipelines across squads must be alike to  enable faster collaboration and seamless tracking.

The concept of Aligned Autonomy might be against the core principles of Agile but if we want to drive agility at an enterprise level, we have found this to be a must.


Mastery as a concept within our framework is something that we’ve already had the opportunity to explore in our earlier discussions especially on the People dimension. It has to do with the process of identifying and nurturing people and teams to be good craftsmen/women in the job they do. It’s all about getting full-stack engineers and creating high-performing squads that I had discussed earlier.

Though this area started-off with big challenges, this is an area where we can leverage engineering toolsets to make the exercise objective and thus adoptable. Since the time I published the People part of this blog series and now, we have had tremendous success in driving mastery at scale across many of our customers. This validated our faith in the approach. Since I had elaborated at length on this in the People part of this series, I will skip it here.


The third and perhaps most important aspect of the three pillars to drive agile at scale is the enforcement of a personal purpose at every level of the organization. Once more I’m reminded of Daniel Pink’s words – “While complying can be an effective strategy for physical survival, it's a lousy one for personal fulfillment. Living a satisfying life requires more than simply meeting the demands of those in control. Yet in our offices and our classrooms, we have way too much compliance and way too little engagement. The former might get you through the day, but only the latter will get you through the night.”

How can a CEO ensure that the engineer in a squad understands the purpose of their existence in the organization and are able to relate their contribution to the roadmap drawn out in the Portfolio layer? How can we continuously measure the alignment of squad output to organization objective?

We have seen the following practices enable answers to the above questions:

  • Communication from the top: Organizations who managed to successfully transform themselves always had a direct channel of communication from the board or CxO layer to the larger organization. This communication is open and live and should clearly articulate the objectives of the organization for next quarter, year and 5 years.
  • Urgency: Unless there is a sense of urgency for change driven from the top, transformations fail. We have been through multiple such experiences.
  • Bottom-up business case: In the new team structure, once the organization objectives are advertised from the top, business cases must be created by the squads themselves and aggregated at each level. This gives a sense of purpose and accountability from all squads.
  • Open feedback: In the new redesigned Agile organization, it is extremely important for teams to have a view into each other’s business cases so that dependencies are managed between themselves and objectives are pre-aligned. It is a good practice to have all business cases available for everyone to see and critic in a collaborative tool.
  • Obeya: We can then leverage Obeya as a concept to continuously measure the progress of a squad or tribe to the business cases they have signed-up to and solve impediments if any.

The above is not a complete list but we have found organization adopt all or some of it and reap benefits in being able to drive purpose within each squad and thereby achieve meaningful velocity.

Thus, my view on the process dimension of scaling Agile model is not about advising which Enterprise Agile framework an organization must adopt or what Agile methodology they should adopt. I had briefly spoken about the latter in one of my earlier blogs and the State of Agile report gives enough indication that , SCRUM and Kanban are the most preferred. My view is that an organization that successfully manages to drive Autonomy, Mastery and Purpose at an enterprise level, would be an “Elite” organization as defined in the State of report. Adoption of these attributes is never big bang and it always follows the bubble-effect of starting small and scaling out.


This brings us to the conclusion of this blog post and the series “How to Successfully Scale Agile and DevOps”. As we’ve observed, the true challenge of scaling agile and dev-ops requires us to take an approach that addresses People, Process, and Technology in equal measure. It’s not only about creating a cross-functional, autonomous team consisting of full-stack engineers who are masters in their craft who come together to deliver business value with purpose than code, it is about transforming an entire organization into such teams.

I hope this series of blogs has offered you an insightful glimpse into the immense possibilities that scaling agile and DevOps has to offer and given you some useful information that can help drive decisions that make your scaling journey one filled with success. I wish you happy learnings, and please find time to post your comments, experiences and queries so that we can learn from each other.