4 minute read

Rob Cummings' keynote at DevOps Days Boston 2017 explored how Simon Wardley’s Pioneers, Settlers, and Town Planners model applies in enterprise engineering and large organizations. The general idea is:

  • Pioneers: explorers of new ideas, create prototypes, prove the need
  • Settlers: stealers of new ideas, move prototypes to MVP, prove feasibility
  • Town Planters: manufacturers, MVPs to industries, prove scalability

[caption id="attachment_792" align="alignnone" width="1912"] Bits or pieces?: On Pioneers, Settlers, Town Planters and Theft[/caption]

The Problem: Overly Simplistic Approaches

Bi-modal IT splits the org into Mode 1 (systems of record) and Mode 2 (systems of innovation). Mode 1 has less line of sight to customers and is governed by enterprise architecture and governance. Mode 2 often runs into Mode 1 when .... The problem is that often, there's no flow between Mode 1 and Mode 2. Bi-modal is overly simplistic.

The book "Thinking in Systems" is a great place to start your journey beyond these modes. Transition states and feedback loops exist already in your org, but realizing where they are and how they could be improved takes practice and group engagement.

Paul's advice: System's thinking is a much broader topic that, if you haven't actually studied, it would serve you well to listen to The Fifth Discipline by Peter Senge. As context for my presentation in April on IoT testing, this made me realize that systems thinking was a necessary mental tool moving forward.

Everyone Innovates...Sometimes.

Pioneers live outside standards, fail often, and don't necessarily make decisions based on metrics. Find the new horizon. That's how they innovate, they bring ideas from outside in.

Settlers make prototypes real, building trust in the org, kick off ecosystems around the adoption of ideas, but sometimes suffer from adoption problems. They bring ideas further in to the org.

Town Planners focus on ops efficiency, build services and platforms that Pioneers rely on for future innovations. They're metrics heavy and bring reality to the operation of ideas.

Fostering Friendly Theft

The Wild West is a "theft-based pull model". There are no mandates. Theft occurs from right to left (pioneers on the left). re-use from left to right.. This is a good thing. Everyone is excellent and everyone both should participate in empathy. Foster feedback loops and maintain pull culture.

The Wild model exists within a team, not as separate departments. Again, for DevOps we're not talking about traditional cost centers and departments; we've got mixed teams that are aligned on a shared goal with their own perspectives on how to do things best, together.

Paul's Take: DevOps Requires Buy-in from Everyone

For DevOps to work, a team needs to understand and adapt to their organizational ecosystem. So while the micro-mechanics of the Wild West help us pull new ideas in on a continual basis, there has to be an understanding that extends across the whole org.

Many conversations at DevOps Days Boston 2017 on day 1 expressed the need for "buy-in from the top", but effective DevOps also requires buy in from everyone. Teams need to align the virtues of DevOps to how they can positively impact the organization. It does no good for an SMB VP of Engineering to apply DevOps if the purpose of doing so hasn't been clearly articulated in terms that other dependencies (like the developers, operations, sales, marketing, finance, and support) understand. But when you do so, it's much easier to carry people with you in planning and execution.

DevOps is Organizational, Operational, and Orthogonal. Applying it in isolation only decreases the value it brings to us.

Scaling to the Enterprise

Rob shared an anonymized anecdote from a large company where the Wild West model was adopted:

A small group of pioneers realized "we need to fix this, can't meet customer needs". They knew how to do it and got CIO sponsorship. The team got to MVP status with code. Unfortunately, the Wild West model was not immediately adopted beyond that initial release.

"We were trying to push the model onto the team." Even though everything done up to that point focused on ease-for-enterprise (weekly demos, code was open sourced, process transparency), adoption took time.

Eventually, another team took the ideas and model, shipped their thing to production, then other teams followed. "Now we have a 'proliferation problem'...people started customizing tools and artifacts." Teams often stuck with some favorite tools, and in DevOps culture, tailoring is huge.

But not everyone wants to build their own house. For example, code pipelines...yuk. So Planners came in and built a commodity pipeline platform. This requires talent, people who have skill and can scale, understand operational efficiency.

Summary

Here are a few anti-patterns that will reduce friction and increase your flow.

  1. Using enterprise architecture to prevent waste and force adoption.
    Don't use it as a gate to get to production!
    .
  2. Relying on innovation labs or CoE for pioneers.
     Teams outside your org toss things in that often don't work inside the org. Be super-public so settlers are likely to steal. Change CoE to "Center of Practice", inclusive, then everyone can be excellent.
    .
  3. Don't forget that your org requires a systems thinking approach.
    Create flows not barriers. Each role is filled with excellent people.

 

More reading:

[wonderplugin_slider id="1"]

You may also enjoy