devopsy.kinsta.cloud

Author: Mustafa Kapadia

Are You a Product Team in Name Only?
A simple litmus test can help determine whether a product team is the real thing or wearing a different name.

Marketers have been trying to dress up spam, ever since the odd can-shaped meat was invented. It has been called “special processed American meat,” “shoulders of pork and ham” and even “spiced ham.” But, no matter what you call it, Spam is still spam.

Dressing Up is Not Just for Canned Meat

Something similar has been going on in IT. We are getting makeovers as well.

Instead of putting in the hard work of changing culture, organization and operating model, we are simply just relabeling the status quo.

For example, projects are now called products, development teams are called squads, meeting are called standups, small sprints are called MVPs and everything is now an experience. The list goes on. But the underlying structure and organization has not changed.

Maybe executives are hoping that the change in name might just bring about the culture change that they are seeking. But at the end of the day, these newly coined product organizations are still slow, costly and risky, and companies continue to publish subpar code.

Separating Truth from Fiction

So how can you tell the difference between a real product organization versus one that is pretending to be? How can you tell if the organization has put in the effort and time to make the real changes versus just a name change? Consider this litmus test:
1. The team is made up of cross functional SMEs, which includes all the various skill sets (Business, UX, Dev, Test, Ops Etc.) required to ship a product/increment.
2. There is a dedicated product owner and a scum master.
3. The product owner is the single owner responsible for both, output (business KPIs) and input (resources) and everyone on the team and within the organization knows about it.
4. The scrum master helps the product team stay on track, removes impediments and shields the team from external distractions.
5. The squads are judged on their impact to business metrics (business KPIs are tied to every new feature released).
6. The teams are autonomous; they (not someone from the outside) decide how much work to commit during a sprint.
7. The team keeps the backlog well-groomed and accurate, and resolves issues without escalating to management.
8. The executives trust the product team to do the right thing within a sprint.
9. Minimal viable product is the default delivery mode and cycle time (development to release) is no more than a few sprints.
10. For every feature the team has agreed on the definition of done, its business impact and how to measure that impact before it goes into development.
11. Product team uses continuous integration (which includes a agile development, branching strategy, on-demand environment, automated build and test and strict quality gates).
12. Feedback is part of the product team’s DNA; failure is expected and is considered as an opportunity to learn.
If your team espouses the above characteristics, congratulations: You passed the test. More importantly, your organization has done most of the heavy lifting and created a truly high-performing product team. That’s no small feat.

However, if your team does not share many of the above characteristics, then you have your work cut out for you.

Good luck.

— Mustafa Kapadia
June 27, 2018
What is an Agile IT Organization?
Agile IT is the new sexy.

Don’t get me wrong. It has always been around. But with the rise of digital transformation, it has taken on a renewed urgency.

For example, Domino’s Pizza has repeatedly said that the reason it was able to beat the competition was a result of its investment in building a more responsive IT organization.—an IT function that heavily relies on Lean, Agile development and DevOps best practices.

But what does it mean to be a faster, nimble, and more responsive IT?

Agile IT Characteristics

Based on our experience, it comes down to the following characteristics:
1. Bring new software/functionality to market quickly—all the way from idea to production.
2. Experiment first mindset. Cut big ideas into small projects (MVPs) and deliver iteratively.
3. Deliver experiences not just features.
4. Measure success in business impact, not IT KPIs. This applies to both the idea and the teams.
5. Create small, dedicated, cross-functional teams. They are more nimble than functional silos.
6. Reward individuals based on their contribution to team goals (i.e business KPIs).
7. Decentralize decision-making.
8. Make continuous improvement part of the company culture. Failure is learning, not something to be punished for.
9. Create short feedback loops so that you can be responsive.
10. The sum of the parts is greater than the parts. Speeding up development and not operations drives minimal benefits.
So how do you reboot IT capabilities to get them to be faster, nimble and more responsive? It’s more than just investing in new technologies; it’s about defining new ways of working. It starts with how work is defined and structured, how it is performed and how success is measured.

In our next article, we will go into more details on the new ways of working, including explore how IT needs to change its mindset, set up new operating models and measure itself differently.

— Mustafa Kapadia
December 22, 2017
Why Does DevOps Require A New Operating Model?

For many, redesigning the operating model is table stakes for a successful DevOps transformation. But have you ever wondered why? Popular wisdom will have you believe that the main reason for operating model redesign are to…

“Improve collaboration between business and IT”
“Realign metrics”
“Take full advantage of the new tools”
“And even jump start culture change”

While these are all good reasons, frankly they miss the point. Experience suggests there is a more practical reason – match ownership with desired output.

What do we mean by that? Well first, lets look at how the current model works.

There a no real owners in IT

DevOps is about optimizing the flow of work across the Software Delivery Lifecycle. But who owns this end to end flow – idea conception to release? Who owns the cycle time? And who it responsible for improving it?

The short answer is everyone. Business, architects, and engineers own the planning phase. Developers own development and testing. Operators own releases. The PMO owns the project plan. And the business owns the funding.

And yes in theory all of these groups are supposed to get along. Unfortunately it rarely happens. Incentives and metrics force them to optimize their silos but not the overall flow. the current operating model encourages tribal siloed mentality. It’s the reason why finger pointing is elevated to an art form and “CYA” is your ticket to getting promoted.

One can argue that the CIO does own it all. But, in my humble opinion, CIOs have to tend to hundreds (if not thousands) of applications. Making it impossible for them to play an active role on a daily basis.

Which brings me back to my earlier point…having too many owners is just as good as having no owners. Rectifying this misalignment is the main reason why so many CIOs choose to change the operating model. Even when it may seem risky at the onset.

In fact many have found that fixing the ownership problem actually accelerates the DevOps transformation.

If you want to make dramatic progress create a single owner for each application

There are lots of names for this type of operating model. Some call it a product model, others call is squads, IBM calls it cell. But the essence is the same – for every application, create a single owner, that manages a cross functional team, has end to end authority, and is measured on business outputs.

This owner is responsible for the entire delivery lifecycle. They manage both the inputs (resources, process, tools, infrastructure etc.) and the outputs (business impact, features, time to market, quality, productivity etc.).

This does four things. First, managers that are the most familiar with the application and its users can now finally optimize the inputs in order to maximize the outputs. Second, by pushing authority to the front lines, you create a sense of true ownership. Pride (or shame) are powerful motivators for quality.

Third, by decoupling the teams you get rid of bureaucracy, give rise to friendly competition, and localize the risks. And fourth, the reason why most CIOs go through with the change despite the risks, it provides you with a one throat to choke.

You can, of course, continue to implement DevOps in the current operating model. But it’s almost impossible to overcome the operating model inertia. A move to a product model can actually accelerate your transformation. The model serves as a catalyst for the organization move past the “old way” of working in silos and create “new ways” of working with the flow.

Create your one throat to choke and see how quickly things change.

— Mustafa Kapadia

June 22, 2017
Transforming the Annual Budgeting Process For DevOps

The annual budgeting and planning cycle is the one process that touches all of IT. It has impact on how decisions are made, teams are organized, work is delegated, projects are started (and/or ended) and responsibilities are allocated Yet, few people think about realigning and transforming the budgeting process for DevOps.

The Problem with Current Budgeting Processes

The annual budgeting process is inherently flawed. It requires executives to predict the future (sometimes 12 months in advance), allocate resources accordingly and lock in the funding. And if that is not bad enough, once budgets are set, they spend the rest of the time reconciling between today’s needs and yesterday’s predictions.

Add in personal agendas and organizational politics, and you end up with a system that sucks time, energy and ambition. For an organization looking to be more nimble and responsive, our current budgeting process has the exact opposite effect.

Budgeting Process for DevOps: 3 Options

Some organizations are taking a much different approach to help cope with the dynamic demands.

1. Shorter Cycles and Frequent Reviews

Learning from our European friends, some organizations are moving to a shorter budgeting and review cycle. The traditional construct of annually funding projects remains, but plans and allocations are revisited quarterly or on a rolling basis. Both business and IT are continuously reprioritizing what features to fund and jointly collaborating on making go/no-go decisions.

The benefit of such a system is that it allows teams to allocate funds dynamically within the project—it forces teams to think in terms of a minimum viable product, and mistakes in allocations can be quickly corrected. However, there are two major drawbacks. First, funds cannot be reallocated across projects, forcing executives to still wait for the annual cycle. And second, if the quarterly review process is not streamlined, it can create a climate of constant budgeting, where managers end up spending more time jockeying for funds instead of doing real work.

2. Product-Based Funding

Others have been experimenting with product-based funding. Here applications and the associated resources are grouped into product teams and are given a share of the total budget. This budget is primarily managed by the chief product owner (represented by either the business/IT), which then further distributes it to her product owners. Just like in the last model, the chief product owner collaborates with the business to decide on go/no-go activities. In addition, it also allows chief product owners to reallocate funds across both products and projects within their portfolio. And the product owners are responsible for executing on the minimum viable feature sets within their allocated funds.

The benefit of this model is in its simplicity. Instead of making bets on projects, CFOs just have to decide on how the budgets are spread across various product groups. Chief product owners and product owners have freedom to allocate their share as they see fit. As a result, budget decisions are pushed as close to the front line as possible, allowing for greater flexibility and improved market response times.

A prerequisite to this method requires IT to move from the functional organizational model to a product model—not an easy task. As for the drawback, product owners have a tendency to fund the new/sexy work while ignoring routine maintenance work. To get around this, some organizations force teams to reserve a piece of the budget for maintenance and paying down technical debt.

3. Venture-Based Funding

While not my favorite, venture-based funding is a model a small handful of companies are experimenting with. Just like Silicon Valley-style venture capitalists (VCs), an executive board funds ideas for minimal viable products. Based on the effectiveness of the product, additional funding is granted to the teams.

The promise of this model is to seed lots of ideas and fund only the ones that work. The benefit is greater transparency and reduced financial risk. The drawback is that most companies are not wired like VC firms. A “sink or swim” culture gives rise to other problems. When viability is all that matters, why should employees follow any of the corporate rules, security policies, best practices or infrastructure requirements, to name a few? And if the idea is good, what prevents the developers to seek out actual seed funding and create a new competitor?

Changing your budgeting process for DevOps is not an easy undertaking. There are significant risks and short-term disruptions to address as the new process takes hold. But one thing is sure, a DevOps transformation must eventually include a budget transformation as well.

About The Author / Mustafa Kapadia

Mustafa Kapadia is the Service Line Leader for IBM’s DevOps practice, a business advisory practice focused on helping large enterprises transform their software & application delivery. He has over 17+ years of experience in the tech. space, both as a service provider and a management consultant.

Prior to joining IBM, Mustafa was a management consultant with Deloitte’s Strategy & Operations practice. He lives in San Francisco Bay Area, is an avid blogger (when time permitting), a speaker, and adviser to start ups.

Connect with Mustafa on LinkedIn | Twitter

June 16, 2016
Designing A DevOps Strategy: A Balanced Scorecard Framework
Despite all the hype about DevOps, little has been written on a formal DevOps strategy. Too often DevOps initiatives starts with tooling discussion and gets stalled in technology. The larger vision is rarely discussed. The goal of this article is to provide enterprises, large and small, with a framework for creating that vision and unlocking the promise of DevOps.

Elements of a DevOps Strategy

A holistic DevOps strategy, at the most basic level, must answer the following questions:
- Where should we focus our efforts? Where do we begin?
- What are we trying to solve?
- What is our goal? How are we going to solve it? How long will it take?
- How is this going to impact the larger enterprise? Who are our stakeholders and what do they value?
- Is this worth doing it? What are the benefits and costs?
If implemented correctly a good strategy provides an organization with focus, creates a common (unbiased) view of the current problems, develops the future state, unveils opportunities for growth and results in better business outputs.

DevOps Strategy Map: A Balanced Scorecard Framework

A Balanced Scorecard typically consists of four high-level perspectives that highlight key practices and objectives that are needed to build a strategy. We choose this framework primarily because it does three things really well. First, it provides a disciplined approach towards creating a strategy. Second, it links the key activities together and describes the cause and effect between them. And third (and most important), its easy to use and follow.

A scorecard is usually read from the bottom up. Enclosed below is a Balanced Scorecard modified for DevOps.

DevOps Strategy Map

1. People, Process & Technology

In DevOps we have the luxury of plenty: an abundance of applications, technologies, competing initiatives, bottlenecks, nebulous problems, tools, etc. The objective of this dimension is to narrow down the application options (system of record vs. system of engagement) and target the problems that really matter (value stream mapping exercise). By doing so, we bring clarity and focus to the organization and greatly improve the chances of success.

2. Critical Capabilities

The next step consists of three activities – create a vision (which includes a future state value stream), determine where to invest, and build an implementation plan. Three things to keep in mind as you go about doing this exercise. First, pick hard targets for your vision. Instead of “improve speed” try to get to “improve speed by 25 percent”. Second, pay particular attention to capabilities gaps. Gaps can then be used to determine areas of investment, approximate budget, and a key input into your ROI model. Third, make sure to prioritize the bottlenecks. Putting the priority list on a timeline can be quickly translated into an implementation plan.

3. Perception by Key Stakeholders

Identifying your key stakeholders, determining their priorities, and aligning your strategy accordingly is the next crucial step. Some of the key stakeholders to consider are business/end customer, CIO and the IT leadership, development, operations and security. Once identified, match the value drivers from the vision to each stakeholder. This along with the output from the previous section will highlight pitfalls of your future state solution, its feasibility, and political objections.

4. Value to the Organization

The financial benefits section serves as the keystone for the balanced scorecard. By using output from the previous sections the business case brings the entire strategy together. As for the benefits themselves, they come in both hard and soft forms. The most common benefits we see are listed in the chart above. To get to ROI, combine the hard benefits with the investments from the previous section.

One Last Thing

The strategy map is meant to be iterative—the great thing about a DevOps solution is that it is not a “one size fits all” approach. Play around with all of the above steps. Move things around, change scope, update solutions and redefine vision until you come up with an objective that is both transformative and achievable for your organization.

DevOps is a journey that’s two steps forward and one step back. Good luck!!

Special thanks to Sunil Joshi and Emily Pence for helping create the Strategy Map. To find out more on how to use this map, joins us at IBM Interconnect.

About The Author/Mustafa Kapadia

Mustafa Kapadia is the Service Line Leader for IBM’s DevOps practice, a business advisory practice focused on helping large enterprises transform their software & application delivery. He has over 17+ years of experience in the tech. space, both as a service provider and a management consultant.

Prior to joining IBM, Mustafa was a management consultant with Deloitte’s Strategy & Operations practice. He lives in San Francisco Bay Area, is an avid blogger (when time permitting), a speaker, and adviser to start ups.

Connect with Mustafa LinkedIn | Twitter
February 18, 2016