If you're already planning your DevOps journey, surely you've been inspired by success stories like Flickr, Netflix, and Etsy. In the best cases, those stories describe where they started, how long it took them, and how things changed. However, following those examples is hard because the journey is so unfamiliar. A common problem is the journey is described as one big leap, where all the invest is characterized as "culture change" and all the DevOps benefits are lumped together. Fortunately, we can use an adaptation of the agile fluency model to help break apart some discrete steps. The reality is: there are some distinct stages, each with different benefits and different kinds of investment.

Mapping agile fluency to DevOps, we propose four stages:

  • Orient to value for your organization
  • Automate, as a team
  • Measure business value
  • Optimize for the whole 

Stage One: Orient towards value for your organization

Just do a Google search on "why devops" and you'll find all kinds of justifications. However, DevOps is not a goal in and of itself. It needs to fit the unique goals and direction of your organization. Even if your management desires the common justifications, these justifications become unique when applied to your products and services. Shipping your product faster is not the same as Etsy deploying 50 times a day. Shipping your service with better quality is not the same as Netflix maintaining sub-second MTTR.

To the extent that DevOps is an extension of agile, this first stage is the same for both.

It's about knowing what your company values, and planning in those terms.

We've seen teams where everyone is focused on only the part they play. It's frightening to accept responsibility for business results, when you're accustomed to just accepting assigned tasks. It takes a lot of trust in management and other team members. That's why this first stage focuses on changing team culture. Scrum and kanban both provide good guidance and structure for making this kind of change.

Working on the right thing is a benefit to everyone. Working on assigned tasks makes everyone feel like a cog in a machine. When we have clear line-of-sight to what the business values, we know our purpose, feel like we're truly part of a team, and find motivation to contribute to vision of the whole organization. Benefits don't end at feeling better. Managers call it "greater visibility." It means is they have enough information to adjust their management style to fit the business context. They can redirect people and teams when business priorities change.

It should take 2-6 months for a team to become fluent in aligning to and tracking in terms of business value. If you go longer, maybe you need to try something else. If Scrum isn't a fit for your team, try kanban. If going it alone isn't enough for your team, try an agile coach. And if the coach you have isn't focusing on the right things, try another.

Atlassian has developed a playbook of great practices that help teams adopt new ways of working that can help improve a team's overall health. The ones that best fit this first stage are:

  • Project Poster: To understand what problem you're solving and why you're solving it; and to guide your thinking, share ideas, and define what success looks like.
  • Elevator Pitch: To set your team up with a consistent and simple explanation of your work and the value it delivers to your customers.
  • Demo Trust: To create a safe space for open discussion and honest feedback; and to help leadership teams scale across projects by providing guidance when it has the biggest impact.

Beyond developing shared understanding of what an organization values, a team may also struggle with turning big business goals into smaller pieces of work that can be delivered in small chunks. We're fond of applying agile techniques like user stories, specification by example, and impact mapping.

In the Atlassian tool set, we reach for Confluence and JIRA Software to help break big ideas into small increments of work. Confluence makes setting those business goals a collaborative process then keeps those goals ever-present as the team's target. Once oriented around business goals, JIRA Software helps track progress.

You don't have to build full fluency at this level before starting a competency in a higher one. That said, be realistic. Fluency is where we fall back when we get frustrated. If a team gets frustrated because it has taken on too much learning at once, it may regress to habits that obscure value and hide progress. Make sure the team has enough competence in "orient to value" that it can get back on track quickly.

Stage Two: Automate, as a team

The mismatch between individual knowledge and learning-as-a-team is a characteristic of the 2nd stage. It isn't about a team culture change like the first stage; it's about a team learning technical practices together. This is a different kind of investment. You may need to attend workshops together. You may need a different agile coach with technical chops. You may need to establish a "technical owner", as a parallel to product owner, to arbitrate decisions and prioritize automation options. Even in a team full of seasoned developers, you might struggle with lowered productivity for a few months before reaching fluency as a team.

Just as the investment is different from the first, this stage also yields a different kind of benefit. It's about focusing on delivery of value. Typically that is measured by shipping on market cadence and capturing value frequently. Frequency leads to revealing obstructions early. Management notices teams at this stage because they have low defects and high productivity.

Extreme programming has long provided a bundle of agile technical practices that apply to this stage: coding standards, unit tests built with test-driven development, automated acceptance tests, pair programming, serial and continuous integration, collective code ownership, and refactoring. It's difficult to keep practices and tools separate in this stage. Except for pair programming and collective code ownership, automated tools closely match the Extreme Programming practices. I use IDEs and static analysis tools to enforce coding standards and perform refactoring, and language-specific frameworks to make it easier to create unit tests and acceptance tests. Of course, both unit and acceptance tests are automation themselves.

At Atlassian, we use Bamboo and Bitbucket Pipelines for continuous integration to run all those automated tasks, as often as every commit. Good tools elevate the practice, making things more visible and aligned with business value. This is where software development turns in upon itself. Where economical, team practices become encoded as automation. This kind of automation is largely what developers bring to DevOps.

For some teams, those extreme programming practices might be enough to deliver value. Many open-source and shrink-wrapped software products are done when they are packaged and tested. But many more software products need to be put into production before the business realizes value. This has long been the case for software built in large organizations to support business operations. That's why thought-leaders in the agile community have advocated for thinking about operations as part of agile. Yet it seems only recently that DevOps has drawn mainstream attention to the role operations plays in delivering value.

Jez Humble and David Farley advocated for continuous delivery as a holistic view of delivering value. Their book extends automated testing and continuous integration into an automated deployment pipeline. In the Atlassian tool set, Bamboo supports this idea by having specialized deployment projects. These model a deployment pipeline with environments, like development, QA, staging, and production. Bamboo can track the deployment of an application into each of these environments. It's then aware that a release is made to production. Although the building blocks of automation are often the same as continuous integration, tracking the pipeline requires a richer information model. With each environment comes another audience that needs to understand how the automation works and when it's performed. In other words, the tool needs to be approachable for not only developers, but also testers and operations.

Stage Three: Measure business value

Orienting to business value in the first stage is not the same as measuring business value. It's one thing to go in the right direction, it's another to have frequent measurement that helps with course correction. This becomes increasingly important as a team embraces automation. The faster the software team gets at delivering software, the more critical it becomes to have autonomy in determining how well they are delivering valuable software. Orienting to business value means you know what the business wants. It takes even tighter collaboration with the business to know how to measure the value of those things.

Bringing business, dev, and ops together to measure value often requires a change in organizational structure. The change in organizational structure brings business thinking and operational insights into a development team. This stage has many of the benefits attributed to DevOps: better product decisions, higher value deliveries, and more reliability. Previous stages give many opportunities to practice measurement, such as measuring team velocity or the delivery pipeline. Measuring business value should feel a lot like automated acceptance testing, except applied in production. Automating as a team means you know how to build "sensors" and aggregate data. Development teams must collaborate with operations to get to the right data. Fortunately, monitoring is a competency of most operations teams.

At Atlassian, our product teams measure Net Promoter Score and monthly active users. It has been a long journey to survey and monitor not only our cloud offerings but also the behind-the-firewall products. The transparency benefits should be readily apparent. The measurements are concrete business metrics that can be used to make business decisions. The objectivity and comparability of these metrics has replaced the politics of decision making with mutual trust. Product teams can negotiate rapidly to shift plans and align with what is best for the company as a whole. Data drives decisions at the speed they are needed by product teams. To exercise our measurement muscles, we run the play "Goals, Signals, Measures" to make sure our teams are focused, can distinguish the signals from noise, and know what a successful outcome looks like. 

Of course, this kind of change typically takes a long time. The cost is often measured in social capital expended on incorporating business and operations expertise into the team. The team will need to avoid the negative connotations of "turf wars" or "fief building." If you want the rewards of this level, start cross-team collaboration early, even as you're working on earlier stages. It takes a long time before measuring business value begins paying dividends.

New organization collaborations usually mean new practices. The operations focus on "keeping the lights on" often means their work is more on demand than software developers. As a result, operations have a natural focus on flow. Some software teams may need to shift to even shorter batches to better fit with this reality of operations. This is why the DevOps community often favors kanban. That said, there are many practices and tools appropriate at this stage. Lean Startup provides many good ideas for running experiments and measuring results. Lean Software Development also provides good guidance to help teams take a disciplined approach to optimizing value delivered through measurement. At this stage, DevOps' CALMS acronym is fully realized, adding lean and measurement to culture, automation, and sharing.

The tools for measurement are evolving rapidly. The scale of some organizations demands big data. However, many organizations don't need the most expensive and cutting-edge big data tools. Instead, they need to focus on slightly different data gathering mechanisms. The key idea is logging. Everyone already has logs from running applications in production. In fact, they often have so many that steps have to be taken to regularly dump the overload of information. What makes logs so important is the time-centric structure. This time-centric nature is also reflected in business data warehouses, with time as a primary dimension. More and more, measurement for business, development, and operations is aligned on this time dimension. "If it changes, graph it." The trick is finding the tools that can aggregate over the right time scale for your organization.

Stage Four: Optimize as a whole

If you're standing at or before the first stage, it can be hard to imagine "optimize as a whole." The Phoenix Project concludes with Parts Unlimited at the apex of this journey. Getting to this stage requires the biggest kind of change: culture change for the whole organization. There are few non-fictional guiding examples in the industry. The idea of optimizing as a whole means cross-team decisions don't require top-down authority. Teams that can measure business value well provide objective insight to the whole organization. That means teams can use data from other teams to optimize their role in the system. The organizations that achieve this stage invest in inventing and sharing new practices, instead of following existing ones. Atlassian's Team Playbook is an example of practices we have discovered and now share.

Optimizing as a whole makes teams much more dynamic. Roles and responsibilities can shift fast. Atlassian practices dynamic teams with quarterly ShipIt days. In 24 hours, people form teams, set their sights on a problem to solve, build a solution (not always software), and ship it. This practice in self-organization and self-direction prepares Atlassians to react to new information and to deliver creative solutions in their everyday work. This explains how organizations that master optimizing as a whole realize the business benefit of being innovative. They are masters of experimentation and learning.

It may take time and effort to reach this stage, but the rewards are worth it. And it's possible for every organization, but the efforts start with motivated individuals and teams.

Are you ready?

For stage one, you need to orient to value for the business. Is what you hope to gain by embracing DevOps recognized as valuable by the business? If not, seek first to understand. Then try again in the language of your organization.

For stage two, you need to automate as a team. Is your team ready to make the investment in learning together?

For stage three, you need to measure business value. Is your team ready to invest in building the necessary technical skills and understanding of the business domain?

For stage four, you need to optimize as a whole. Are the members of your team ready to shift to new work and to subject themselves to rapid feedback?

For the journey as a whole, is your organization ready to make the right kind of investment? If not, set a more modest target of a lower stage. Then try again with a more focused option. Success will win the ability to try for the higher stage later.

Once you get started, remember the power of conviction. Forget that you can fail. Build the bridge as you walk on it.

Posted by Ian Buchanan

読了時間 8 分