GitHub Enterprise Server 3.6 is now generally available.
Your organization's leadership has made the decision to commit to a DevOps methodology. The CEO is calling for the company to deliver value faster, customers are demanding more and expecting results immediately, and internal teams are starting to understand the benefits of integrating deployment, operations and support for faster and more reliable results. It's time to evolve, but change won't be achieved by directive alone. The move will take planning, commitment and strong management.
Start with Part 1: What Does Value Stream Management Mean to the CIO?
Feeling the constant pressure to deliver faster and more frequently, without compromising value, companies are looking for a way to control the overall process from the development level up to c-suite leadership. To make it work, they are turning to value stream management (VSM).
In the structure of VSM, the CIO oversees broad strategy from the top while development teams tactically work to get the job done. Yet, to synchronize the two, there needs to be a layer that communicates between them: a management layer. A successful management layer sits in the middle overseeing development and reporting up to the CIO about how everything is going. Essentially, it's the layer that translates the development methodology into the development process. However, being in the middle creates a specific set of challenges that the management layer faces and must get under control in order to succeed.
Making Things Normal Again
The first challenge management faces is overseeing a series of teams, some which are DevOps oriented and some that need to be trained and introduced to the new philosophy. It's difficult to corral these diverse teams under one directive. There needs to be a common language and nomenclature to address the different teams and get everyone working in the same direction. One term for this is “normalize.” In this context, normalize means taking what teams A, B and C are doing and creating a standard way of looking at things so that metrics and statistics can be combined to produce an overall picture that illustrates how everything is going.
Along those same lines, teams also have become more autonomous and smaller, so the problem gets amplified because normalization has to happen across a broader and more disparate set of teams and methodologies. This is hard to do. Not only is it hard, but it also takes a lot of time to gather and normalize the metrics so they can be reported on.
All of that falls to the reporting-up part of the job. The other part of the management layer's job is not just gathering information to report up to the CIO but using the same information to drive teams to improve and embrace their new roles in the DevOps workflow.
Being pulled in two directions like this can be maddening and difficult but it's where the benefits of managing the value stream become real. Results are realized when reporting goes up to the CIO and cycles back down to the delivery process to be acted upon and create improvements. VSM provides the visibility in the organization to achieve that feedback loop of information.
Enforcing the Rules
Another challenge the management layer is expected to handle is around implementing governance. The management layer is where the rubber meets the road for governance. It is responsible for enforcing and ensuring governance in a reliable way without affecting frequency, throughput, velocity or quality. Governance ensures there is a way to verify that all the policies and practices have been enforced and if an audit is ever called for it will take minimal amount of work to comply. Jobs are on the line at this stage. If audits don't get passed, people get fired.
On top of bringing teams together and overseeing governance, the management level has to deal with the metrics of testing and QA. Waterfall teams are tried-and-true, but to evolve an entire organization, management is tasked with automating as much as possible and shifting activities to the left in the development cycle. Ultimately, this boils down to efficiently mapping value, diligently looking for waste and incorporating those efforts into the metrics and process of delivery.
Understanding the metrics of the value stream and reducing waste are the bread-and-butter metrics of the management layer. The person in a VSM management role acts as an investigative reporter seeking out metrics that signify a problem of inefficacy or an opportunity in value.
To do that, they need something deeper than a report. This is the difference between reporting and analytics. A report is static, it shows the right now. Analytics shows time and allows comparisons across multiple data sets. This needs to be available at every step so managers can zoom into a team, or multiple teams, and see how they are doing and know which ones are doing better and why. This allows them to take learnings or strengths from one team and apply them to another team. What's working, what's not. The management layer is the layer that makes this happen.
The key challenge for the management layer is to ultimately solve "What does quality look like?" and measure it in terms of its impact on productions and operations. When delivering new features, teams need to know that they aren't bringing down other parts in the system. Quality also needs to be measured from the perspective of the end user: "Did they have an experience that was trustworthy?"
The value of the management layer is that the CIO level wants a static picture, but also wants a view of progress over time. Frankly, that's as far as the CIO needs to dig in. The way that the data was made and the systems behind it are the work of the management layer. That is where the understanding digs deep enough to have a meaningful influence. And for the development layer, it can ensure that everything is geared toward delivering quality software faster.