devopsy.kinsta.cloud

Tag: devops organization

  • Why You Should Rip Up Your Org Chart and Reorganize Around Value Streams 

    Why You Should Rip Up Your Org Chart and Reorganize Around Value Streams 

    To compete in the digital economy, teams must optimize both efficiency and effectiveness–it’s a tough ask. The traditional dominator hierarchy is a problem because organizations that use command and control create silos and handoffs that stifle innovation at the team level. Coordinated autonomy releases the creative spirit of individuals–but how can leaders assure alignment with their vision?

    One way to eliminate the delays and waste associated with silos and foster autonomy is to arrange around value streams. A value stream is anything that has a customer or anything that delivers a product or a service. All value streams begin with ideas and end when a change is delivered. Or, even better, when our cherished customers realize the intended value outcome. The original intent of Agile was to provide “value” to our customers faster … but we hardly ever talk about what this value is or measure its existence.

    Traditional organizational charts arrange resources according to expertise. This means that work is handed off to different teams as it progresses through the value stream. Value streams exist whether or not people call them that and whether or not they actively manage them. Every time a hand-off occurs, it creates an opportunity for delays or errors. It also means it’s hard for people to understand the end-to-end system. Instead, they do as they are told to optimize their piece of the puzzle without really understanding how their actions impact work that’s upstream or downstream.

    More progressive ways of working, like Agile and DevOps, do promote cross-functional, autonomous teams, but they typically leave a big gap between planning and delivery and are not always smart at connecting feedback from customer experience back into planning. Value stream orientation promotes team diversity by recognizing the individual background (cross-functionally) into the value delivered to the customer.

    Organizing around value streams is the foundation for nurturing the value stream-centric ways of thinking and working that drive both efficiency and effectiveness. Then, customer experience is improved and higher levels of organizational performance are achieved. This is because:

    • Putting customer experience front and center brings higher retention and referral rates
    • Elevating the concept of flow (see below) gives teams permission to prioritize removing waste
    • Balancing innovation with improvements reduces technical debt, toil and unplanned work so employee experience is better, too
    • Connecting planning to delivery to feedback in a continuous loop aligns teams and helps with decision-making

    Flow is about how fast ideas can move through a value stream and be made available to the people they’re designed for. It’s about outputs and efficiency. Customer experience tells teams about the outcomes of their work and their effectiveness. Used together, these measures ensure the teams are doing the right things right and moving in the right direction.

    In this model, leaders share their authority and empower their teams. They support teams’ self-discovery of improvements and make sure those local learnings go global. They help their teams understand how much time they spend innovating compared to reacting or improving. Then the leaders can help their teams reduce distracting and stressful unplanned work and instead invest in increasing capacity for innovation in the future.

    Follow these steps to become a value stream-centric organization:

    1. Identify your value streams
    2. Identify who is involved in each step of your value stream
    3. Make your value stream visible by visually collaborating with your value stream team
    4. Use tooling to gather value stream data and generate insights for your team
    5. Meet regularly to inspect and adapt your value stream

    All organizations are composed of value streams, regardless of whether they have been made visible, and most large organizations have complex networks of interconnecting value streams. These dependencies are not easily decoupled. They’re not easily visible, either. But once you’ve mapped them, you can start seeing where they connect and manage the dependencies. Ultimately the goal is to break these dependencies since they cause delays and risk, but it’s hard to do that when they can’t be seen.

    Connecting the organizational vision with the value streams becomes much easier with this model. Organizational structures are flattened. Leaders understand which value streams they are accountable for and how they work. The time between having an idea and getting feedback on how it’s received is shorter and amplified. They can see the work being done, measure what impact it’s having and make better decisions about what to innovate or invest in next.

  • Transforming the Annual Budgeting Process For DevOps

    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-KapadiaMustafa 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

  • Having DevOps In Your Job Title Is Doing You Harm

    matrixThis post was originally published on my personal blog in May 2013.  But I think this topic is important and wanted it to be my first contribution to devopsy.kinsta.cloud

    I used to be Director of DevOps…twice. Both times, I changed my title later. I even ran a DevOps team…although the team was already called that when I took over.

    I have fallen victim to the the abuse of the DevOps title, and I see it all the time. In the DevOps twitter hashtag, people contacting about DevOps job opportunities…it’s got to be a real thing, right?

    I mean, we totally have people that are doing DevOps these days, right?  I know that I can find all kinds of job descriptions for DevOps Engineers from many types of companies.

    But, there is one very important reason why you might want to think twice before using “DevOps” as part of your job title.

    My friends (rightfully) give me grief for the fact that I self-assigned my title at Dyn to be the Director of DevOps (I still feel bad about it). I really hate job titles in general and this is what happens when you don’t care about what your title is.

    How the story goes is that when I received the offer from Dyn, my original title was Director of System Automation and Release Engineering. Since I was pretty sure that wasn’t going to fit on a business card, I took the job and asked that we change the title later. Fast forward a month, as after talking and trying to formulate my job description & title for about 20 min, I say simply enough, ”F this. Just call it DevOps, I’ve got other things to do.” I was far too busy to really care much about an arbitrary title.

    Fast forward a few weeks to Monitorama, and I was chatting with Mike Rembetsy. After talking for two minutes about how the new job was going, he said, “Oh, that reminds me, you need to change your job title. It’s terrible.” I tried to convince him for about three more minutes, mainly trying to express to him that it doesn’t matter. He then dropped the knowledge bomb that gave me the aha moment.

    When you are the Head of DevOps, you “own” DevOps. If DevOps fails, it is your failure, when it should be a failure of the entire company to change, adapt, and accept the cultural shift.

    That is the major problem with being the “head” of DevOps, or the “Director/Manager/VP/etc. of DevOps.” If DevOps fails inside your company, it’s a really easy way for the executives to say “Well, you are the head of DevOps so obviously it failed because you failed.”

    The reality is that DevOps is a culture that should be accepted by every facet of your organization. Everyone needs to embrace the changes of a DevOps culture, and there can not be a single owner of it.

    Soon after that conversation, I relaunched my team and title in general to be the “DevTools Team” (a brilliant Etsy recommendation). The more I thought about it, it accurately describes the work that we do. We build the tools needed for Developers (and Ops/QA/NetSec) to spend more of their time writing code, and less time dealing with distractions.

    I know some people want to have a DevOps team, or want to call their team the DevOps team. Jez Humble wrote a wonderful blog post last year that I highly recommend that you read. He summarizes that there are scenarios that a “DevOps” team label works, and I do agree with what he says. But don’t just label a team DevOps, assign a new Manager of DevOps and wonder why three or six months go by and things are still bad. Things are still terrible because all you did was change a team name, or give a brand new team a name, or in some cases , just created a new silo called the “DevOps Team Silo”.

    Well, what am I supposed to call myself?

    Here are some of the examples that came up during the Open Space:

    • Site Reliability Engineer
    • Automation Engineer
    • Release Engineer
    • DevTools Engineer

    I don’t know why recently there is a need to move away from the same job titles we’ve used in the past, as if there is some negative connotation towards them. It’s not that the jobs have really changed much; it’s that we’re just getting better and more efficient at doing them with the tools at our disposal. The tools have grown so quickly, it has enabled us to be much better at our jobs, but only if you are willing to learn something new.

    • System Administrator
    • Operations Engineer
    • Network Engineer

    In the end, titles really don’t matter very much, and they shouldn’t matter much. But they can actually have a more powerful (negative) impact internally by making you the owner of a culture that should be accepted by everyone. But there is one point that I believe is so important it needs to be repeated:

    If DevOps fails, it should be a failure of the entire company.

    Check out my talk “How to Keep the People You Need,” where I discuss recruitment and retention of your hard to fill positions. Also check out the panel on DevOps with Twitter’s Rich Paret from Dyn’s Geek Summer camp.