5 principles to becoming a collaborative agile devops team

Agile and devops are not just practices and technologies—they are designed to change how people in IT work together

5 principles to becoming a collaborative agile devops team
Getty Images

There’s a lot of work IT teams take on when committing to agile and devops practices. Agile teams are likely to mature and scale their practice by defining the scrum master roles, adding estimating practices, and maturing how they use agile management tools. Devops teams might start by implementing CI/CD pipelines, then implement automate testing, and then look to add more informative application-level monitoring and alerts.

You might hear a lot about the culture and mindset of IT organizations around agile and devops. If you’ve been around IT long enough then you’ve probably witnessed the struggle between development teams that want to release quickly and IT operations that wants to control changes so that infrastructure and applications run reliably. Agile and devops are not just practices and technologies—they are designed to change how people in IT work together.

As your IT organization is embarking on agile and devops transformations, how do you know that people are truly collaborating? How should teams behave differently and what should you be doing to advance the collaboration, culture and mindset of teams?

Here are five principles that will help guide this collaborative and culture transformation.

1. Collaborative teams solve the right problems good enough

Have you ever witnessed teams so focused on a technical solution that they lose site of what problem they are solving and why? Or how about when a problem is being worked on and there are key people left out of the conversation? What happens when teams overthink a technical problem and define a solution that’s overengineered or too complex to implement?

These all represent situations where the team dove right into problem-solving without stepping back and thinking strategically. Collaborative teams establish disciplines around problem solving by:

  • Defining the opportunity with a clear statement of the objective and why it is important.
  • Understanding user needs and values that should be considered in the solution.
  • Reviewing the opportunity in the context of others and deciding what’s a higher priority.
  • Using Jeff Bezos’s two-pizza meeting rule and designating a diverse team to solve the problem.
  • Understanding constraints and leveraging relevant data to zero in on feasible options.
  • Time-boxing efforts to solution and considering multiple options.
  • Communicating results and recommended next steps.

2. Great teams are customer-focused but also address technical debt aggressively

The best teams look to strike the right balance between delivering on strategic initiatives, responding to customer needs and issues, and addressing technical debt. That’s easy to say, but very hard to achieve in practice when there are users screaming about issues, leaders demanding about hitting deadlines, and security teams wanting vulnerable systems and applications patched aggressively.

Strong teams are hypersensitive about how they prioritize their day and use their time efficiently to address demanding priorities. For example. they look to reduce unnecessary meetings, eliminate unnecessary steps in their procedures, and invest in their own workflow automation.

It’s also easy for teams to let technical debt lag behind demanding business needs, but the best teams don’t let technical debt accumulate. The take pride in their architecture, in how systems are performing, and the craftmanship of their code. They find crumpling infrastructure unacceptable, and they mitigate rather than worry about security and other risks. They take responsibility for what they are building and what was built before their time.

3. Self-organizing teams drive standards that they establish

One of the Agile Manifesto principles is “The best architectures, requirements, and designs emerge from self-organizing teams.” The best teams put this principle to practice by finding the right balance between self-organizing, experimenting, and developing proofs of concept versus developing standard practices, architectures, and methodologies.

This isn’t as easy as it looks. For smaller teams, it’s hard to find enough time to truly define, document, communicate, and measure a standard when so much of everyone’s effort is just getting the day-to-day work done. For larger organizations, teams taking an idea and scaling it so others can use it requires communication and collaboration well beyond their core responsibilities.

Yet, that’s exactly what great agile and devops teams do. Self-organizing teams are given significant empowerment and flexibility to do the right things well. With that flexibility should come the added responsibility of establishing best practices and following standards.

4. Great teams develop KPIs and use retrospectives to drive improvement

Good teams always look to improve their process, practices, and collaboration. Great teams do this by formalizing key performance indicators (KPIs) and improvement processes.

How is this done in practice?

  • IT organizations select and measure key performance indicators especially around weak practice areas that are affecting productivity, quality, or other operating principles.
  • KPIs are reviewed regularly and teams capture additional feedback on process improvement at retrospective meetings. The most important feedback is prioritized for process improvements.
  • When organizations have multiple teams, ones that excel in specific KPIs are asked to mentor underperforming teams.
  • Optimized KPIs are dropped and replaced with other improvement areas on a regular basis.

5. Great teams solve conflicts in small groups, celebrate wins in larger ones

Adapting IT doesn’t happen without its speed bumps and conflicts. There are debates on priorities, standards, technology platforms, and implementation methodologies.

The best teams recognize conflicts and look to address them with small, informed teams. They look to address conflicts quickly by adopting a mindset of “What if we pick path A and it’s wrong?” versus “How do we know definitively the optimal path?” In other words, they are open to taking measurable risks and failing fast rather than being blocked by conflicts and not addressing them.

On the other hand, great teams celebrate the small stuff in big ways. Many organizations are using technology more strategically and that puts significant pressure on IT to deliver more frequent application changes, resolve operational issues faster, and improve the overall quality of user experiences. It’s easy to forget about today’s successes because leaders will always ask, “What’s next” and “How can you do better?”

The best teams recognize their accomplishments and drive culture change by getting their stakeholder and colleagues celebrating their wins.

Copyright © 2018 IDG Communications, Inc.

How to choose a low-code development platform