Skip to content
This repository has been archived by the owner on Jun 19, 2020. It is now read-only.

Latest commit

 

History

History
68 lines (45 loc) · 6.99 KB

our-devops-transformation.md

File metadata and controls

68 lines (45 loc) · 6.99 KB

open source

ALM | DevOps Rangers find better ways to deliver value by transitioning to DevOps

The community of Ranger volunteers, give professional guidance, practical experience and gap-filling solutions to the developer community. To enable the community to respond to change and deliver value faster, they're transitioning to DevOps using Agile practices and DevOps capabilities using Visual Studio Team Services (VSTS) and Microsoft Azure.

Situation

The Ranger program was created in 2006 as an internal community to "connect the product group with the field and remove adoption blockers". By 2010 the program evolved to include Microsoft Most Valued Professionals (MVP), expanding the community to a geographically distributed community, spanning the globe. By 2009, the community had over 200 members, resulting in collaboration and planning challenges, bottlenecks due to dependencies and manual processes, and increasing delays and dissatisfaction with the developer community.

The community is divided into roughly a dozen active teams. Each team is committed to design, build, and support one guidance or tooling project through its lifetime. In the past, teams typically bottle necked at the team management level, due to a rigid water-fall style process and high dependency on one or more program managers. The program managers intervened in decision making, releases, and driving the why, what and how for projects. Also, a lack of real-time metrics did not enable the teams to effectively monitor their solutions. Users typically alerted the community of bugs and issues.

It was time to find a better way of doing things and delivering value to the developer community.

Solution

"DevOps is the union of people, process, and products to enable continuous delivery of value to our end users." - Donovan Brown"

To address these challenges, the community stopped all new projects for a couple of sprints to explore Agile practices and new products. The aim was to re-energize the community, find ways to promote autonomy, mastery, and purpose, as outlined in DRiVE, by Daniel H.Pink, and overhaul the rigid processes and products.

Mature self-organizing, self-managed, and cross-functional teams thrive on autonomy, mastery, and purpose" - DRiVE, Daniel H.Pink.

Getting the culture, the people, right was the first step to embrace DevOps. The community implemented the Scrum framework, used Kanban to improve the engineering process, and visualization to improve transparency, awareness, and most importantly, trust. With self-organization of teams, the traditional hierarchy and chain-of-command disappeared. Self-management encouraged teams to actively monitor and evolve their own process.

In April 2010 the community took another pivotal step. They switched and committed their culture, process, and products to the cloud. While the core focus of the free by-the-community-for-the-community solutions remains on guidance and gap-filling solutions, there's a growing investment in open source solutions (OSS), such as arm templates and feature flag samples to research and share outcomes from the DevOps transformations.

Continuous integration (CI) and continuous delivery (CD) replaced rigid manual processes with automated pipelines. This empowered teams to deploy solutions to canary and early adopter users, without intervention from program management. Adding telemetry enabled teams to watch their solutions and often detect and address unknown issues before users noticed them.

The DevOps transformation is an ongoing evolution, using experiments to explore and validate people, process, and product innovations. Recent experiments introduced many pipeline innovations that are continuously improving the value flow. Component scanning automatically, continuously, and silently check security, licensing, and quality of open source components. The use of deployment rings and feature flags enables teams to have fine-rained control of features for all or specific users.

In October 2017 the community moved most of their private version control repositories to GitHub. Transfer of ownership and administration responsibilities for all repositories to the ALM | DevOps community, gives the teams autonomy and an opportunity to energise the broader community to contribute to the open source solutions.

Teams are empowered to deliver quality and value to their end users.

Benefits

Embracing DevOps enabled the Ranger community to become nimble, realize faster-to-market and quicker-to-learn-and-react processes, reduce the investment of precious family time, and proclaim autonomy.

See Our journey of transforming to a DevOps culture for a detailed journal of the transformation, a summary of positive experiences, and known challenges that need to be addressed in future.

Here's a list of observations, listed in not specific order:

  • Autonomy, Mastery, and Purpose are core!
  • Start with something tangible and iterate - avoid the big-bang.
  • Tangible and actionable metrics is important - ensure it does not turn into noise!
  • The most challenging part of transformation are the people (culture).
  • There's no blueprint - every organization and every team is unique!
  • Transformation is continuous!
  • Transparency and visibility is key!
  • Use engineering process to reinforce desired behaviour!

Table of transformation changes:

PAST CURRENT ENVISIONED
Branching Servicing and Release isolation Feature Master
Build Manual and error prone Automated and consistent
Issue detection Call from user Proactive telemetry
Issue resolution Days - weeks Minutes - days Minutes
Planning Detailed design Prototyping and storyboards
Program management 2 Program Managers (PM) 0.25 PM 0.125 PM
Release cadence 6-12 months 3-5 sprints Every sprint
Release Manual and error prone Automated and consistent
Sprints 1-month 3-weeks
Team size 10-15 2-5
Time to build Hours Seconds
Time to release Days Minutes

But, we're not done! Instead we're part of an exciting, continuous and likely never-ending transformation.