Talking Scaling Agile and Continuous Delivery (PODCAST)

news scaled-agile
Posted by Huimin

21 March 2016

Our Director of Product Management, Suzie Prince, and Chad Wathington, our Managing Director, were recently guests on B2B Nation: IT Edition podcast to discuss being lean before adopting scaling agile methodologies, scaling agile change management techniques for leadership, and best practices for adopting Continuous Delivery. Here’s the audio:

Below are a few highlights from the conversation:

The main scaled agile frameworks that we see are SAFe (Scaled Agile Framework), DAD (Disciplined Agile Delivery), and LeSS (Large Scale Scrum).

There are also less formal things we’re seeing with things like Spotify’s Tribe process that they use. Across all of them, there are definitely two main forms that we see. The first is a top-down process. That’s where the process is rolled out to all of the teams at once. Then we see a more bottom-up approach where individual teams change themselves and bring agility to themselves and then those individual teams do their own thing. There are benefits obviously for teams to create their own way working.

You need a combination of the top-down and bottom-up approach.

  1. You need to have agility at every level. You can’t expect the organization to see benefits if only some parts of it change.
  2. You need to prioritize and communicate your business goals, but also your goals of changing the organization. Just pushing out a process without explaining what you’re hoping to achieve does not work. Often the more formal scaled agile frameworks have a good basis for this kind of communication, they have ceremonies that help explain the business goals.
  3. All of the frameworks emphasize the collaborative nature of agile is fundamental and it’s important that that’s not lost when you scale.

The attitude and belief system of leaders themselves is a very important scaling agile change management technique for leadership.

A lot of times leaders just sort of sponsor a change. It goes deeper than that. Jim Highsmith talks about that in his book, “Adaptive Leadership”. It’s about managers embracing the principles themselves and inspiring others. If you just get people to do agile in these practice sort of ways, you’re actually not being agile. He talks a lot about managers and leaders exhibiting the values first when you go through a change management process.

The second thing that’s important is piloting these changes in small places and making sure they work. You don’t want to scale something that doesn’t work. You get teams that are working in agile ways. You want to learn from those teams, create the right feedback loops between the teams and between management structures, so that you can see what works and apply it in different circumstances.

Classic change management as a discipline is overlooked.
People say, “Well, I’m a leader and we’re going to go make Agile happen.” There’s very good frameworks out there, like the Kotter framework with eight steps on how to run a change management process. People often don’t do that in rolling out software changes. In particular, with something like agile and scaling these lean practices and team autonomy, it’s important to do step four of Kotter’s model which is to enlist people outside of the leadership framework to drive the change and to enlist an army to drive the change.

The cultural shift that is DevOps, digital destruction and digital transformation are all important topics that people are talking about.
When you want to get the business benefit of agile software development, people started to look downstream to production, to operations, and to testing. Once you do that, you say, “Well, wait… how do I get this stuff outside the door?” and the DevOps movement in terms of that cultural combination between developers and ops is important. We talk a lot about continuous delivery, which is a specific set of practices in DevOps to help people get software out fast.

For a startup, a lot of these activities are green field. You don’t have an existing application in place that’s significantly large.
You can decide, “Hey, I want to move to a microservices architecture, pretty rapidly, and be able to implement it.” As you get larger, the legacy that you have to deal with, not only in terms of actual code and systems, but architecture and sort of cultural boundaries of how you set up your organization, become more and more important.

A small company should be able to move to Continuous Delivery-type practices very quickly.

For example, our product Snap, which is a continuous delivery in the cloud, is designed around small companies by being able to get in, use GitHub, get their code out to somebody like AWS or Heroku, and make that whole experience simple and transparent. That’s doable, right? If you say, “Hey, I’m a Fortunate 500 company with multi-billion dollars of an IT spend.” Moving to Continuous Delivery is a lot harder. There’s practices that need to be changed, your architecture, your actual code and things like that does need to be changed within your culture. That can be a multi-shift for even one division of a larger company, because there’s so many things to wrangle to get it right.

(This podcast was created and published by TechnologyAdvice, an Inc. 5000 company looking to help buyers find the best project management software, payroll systems, and more. Interview conducted by Josh Bland. If you enjoyed this topic, please subscribe and rate B2B Nation: IT Edition on iTunes. Find out more about Bluetooth World at

comments powered by Disqus