CI Tools and Best Practices in the Cloud

Continuous Integration

Subscribe to Continuous Integration: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Integration: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Continuous Integration Authors: Yeshim Deniz, Mehdi Daoudi, Elizabeth White, Liz McMillan, Pat Romanski


Scaling Agile and DevOps in the Enterprise

Best Practice for Enterprise DevOps and Agile

The original blog post can be found here.


In a recent Continuous Discussions (#c9d9) video podcast, expert panelists discussed scaling Agile and DevOps in the enterprise.

Our expert panel included: Gary Gruver, co-author of “Leading the Transformation, A Practical Approach to Large-Scale Agile Development,” and “Starting and Scaling DevOps in the Enterprise”; Mirco Hering, a passionate Agile and DevOps change agent; Rob Hirschfeld, CEO at RackN; Steve Mayner, Agile coach, mentor and thought leader; Todd Miller, delivery director for Celerity’s Enterprise Technology Solutions; and, our very own Anders Wallgren and Sam Fell.

During the episode, the panelists discussed lessons learned with regards to leadership, teams and the pipeline and patterns that can be applied for scaling Agile and DevOps in the Enterprise.

Scaling Agile vs. Scaling DevOps

Talk about both the technology and processes when it comes to DevOps, says Hirschfeld: “One thing I would say is that people often get confused about with DevOps is DevOps is very much process-focused. But, it’s okay to talk about the tech. I’m the type of person that says let’s actually think about the tech. It’s okay to be excited about Chef, Puppet, Ansible, CI/CD pipelines and all those things. I think it’s healthy to infuse DevOps tech with DevOps the process.”

DevOps is all about plumbing the last mile, explains Wallgren: “One of the things we’ve seen quite a bit with our customers and in talking to people is that (probably unintentionally) Agile became a local optimization for engineering and development. We got into the whole aspect of product ownership and Scrum and stories and all of that stuff. One of the things I talk about very often is how, practically speaking, DevOps has become a lot about plumbing the last mile. Plumbing the last mile from when you check in a piece of code to when it’s available for the customer. Engineering teams have become pretty good at delivering functionality. They would have two week spreads to deliver functionality, but then it would take 90 days to put it into production. There was a lot of work in progress on the factory floor so to speak. We’ve got a little bit better at recognizing that as a problem. It’s one of those lessons where you haven’t really solved a problem until you solved it all the way through to the end user. Agile was all about that from the beginning, but I think practically speaking a lot of us looked at it as a way to solve engineering problems, and left the whole delivery to customer part as an exercise for the art people to solve.”

It’s not just about Agile vs. DevOps, scaling itself is a whole other ball game, per Hering: “I think scaling is entirely different to just doing Agile or DevOps. Someone told me once if you have four people in a room, you don’t need a methodology or any kind of formalized way of working. I think as soon as you get to complexity – to scale, to distributions – as you’re working across many different locations, that’s when you really need to start formalizing. Where people struggle is either not having anything formalized, or being overly prescriptive and completely drowning out of the innovation part. That’s why we are struggling with that because it’s the tension between those two and that’s very much the same for Agile and DevOps.”

Gruver discusses the challenges of releasing code when scaling up: “The challenge became when Agile scaled into the enterprise, releasing code in tightly coupled systems became more difficult. You either started with small teams that were able to do that or you went into organizations that had challenges and architecturally changed it towards small teams that can independently develop, qualify and deploy code. The reality is most large organizations don’t have that architectural decoupling, so they have to coordinate the work across a large number of people and that is challenging. So, when Agile scaled into the enterprise a lot of people left that behind because it was hard. I think DevOps really started to gain momentum because Agile dropped that basic principle as it scaled in the enterprise. It became a lot more about technology with Jez Humble’s book around Continuous Delivery and infrastructure-as-code. Those were the types of things that were making it difficult for release code on a frequent basis and maintain quality.”

It isn’t enough just to say you are Agile, says Fell: “If you think about the Agile manifesto, I think number 12 is ‘Enable a Continuous Delivery of valuable updates to the end user.’ Even back then they knew that just being Agile in itself is not enough, you have to actually deliver that to somebody and taking those practices and pushing them downstream.”

What does it really mean to be Agile? Miller explains: “The core of being Agile is to be able to incrementally deliver. So, I’m going to go put my developer goggles on and see how many times I can tell you where I checked something in and everybody gets late, and my answer is, but it works on my machine. It might not work in an environment or it might work on half of the people’s machine – I think that DevOps helps to cure that. Are you really Agile? Unless you’re continuously delivering, I think that’s a state where everybody wants to be in. One of the first questions I ask when I’m going into an organization that says they are Agile is, ‘What’s your release cycle look like?’ A lot of times I hear, ‘Oh we are Agile, we release every three months.’”

Mayner talks about the Agile mindset: “When we began the Agile conversation we heard it said a lot that it really is much more about the mindset. The Lean Agile mindset, both at the practitioner level, at the leadership level, and throughout the organization. I would say as we’ve moved into the DevOps conversation it’s really the same. I’ve seen a lot of conversations around technologies and practices, but to understand why this works differently, why this is more than just different tools and different labels for things, it’s a much deeper, richer conversation.”


For more on leadership, teams and best practices, check out the full blog post here.

More Stories By Anders Wallgren

Anders Wallgren is Chief Technology Officer of Electric Cloud. Anders brings with him over 25 years of in-depth experience designing and building commercial software. Prior to joining Electric Cloud, Anders held executive positions at Aceva, Archistra, and Impresse. Anders also held management positions at Macromedia (MACR), Common Ground Software and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7 and various Shockwave products.