Tag: lean for devops

  • 3 Rules for Successful SAFe Adoption

    3 Rules for Successful SAFe Adoption

    Startups and enterprises alike are redefining—some say disrupting—markets, industries and customer experiences by delivering innovative ideas at a rapid pace and responding to feedback. Often they fail, but they fail quickly and adjust. You know the ones: Spotify, Etsy, Netflix, Airbnb. How do they do it? What can we learn from them that will work in our own organizations? What is different? In a nutshell, all of these successful organizations innovate completely, not only in terms of what they do, but also how they do it. And the common thread is the application of lean and agile practices to improve their culture and deliver innovation to customers faster than the rest of us.

    Today’s business imperative is to be the disruptor and more and more organizations are turning to enterprise scaled agile as a set of practices to help lead transformations to achieve that goal. The Scaled Agile Framework (SAFe) is the industry-leading enterprise scaled agile framework with a proven track record in thousands of organizations for several reasons, not the least of which is the incredible breadth of definition and collateral so that you just don’t have to make this stuff up yourself. Nevertheless, there is not an one-size-fits-all framework and SAFe is no exception. But there are three key concepts prescribed by SAFe that, if you do nothing else, will help you be successful in your evolution toward becoming that disruptor.

    Go SAFe or Go Home

    1. Apply Lean Principles at an Enterprise level
    You’ve likely heard the term “MVP,” or minimum viable product. This is about investing “just enough” to deliver a capability—a solution, product or application—and get feedback. It is about avoiding the pitfalls of over-engineering. This is perfect embodiment of lean thinking. By focusing on investing only as much as necessary to get feedback quickly (and doing this continuously) you not only reduce or eliminate wasted resources but also speed time to feedback. Lean is also about the notion that “capacity rules”—in other words, only invest as you have capacity to follow through. Otherwise, what’s the point?

    2. Apply Economic Thinking
    Traditional methodologies typically focus on priority to rank at all levels, from business initiatives and projects down to team-level work that delivers changes into products and applications. In the agile world, story points (or complexity) also might be used. So what’s the problem with this? First, it is only a single dimension. What about business or customer value? What about cost of delivery or reducing risks or enabling market opportunities? Is timing a factor? All of these aspects should be considered when ranking because, at the end of the day, organizations are looking for the “biggest bang for the buck.” By applying economic thinking, you are maximizing the business’s ability to deliver the most value at the lowest cost in a timely manner.

    3. Focus on Delivery of Value
    I’ve often heard that revenue generation is the primary goal when organizations look to speed delivery cycle times. In fact, the goal should be delighting the customer; revenue is a bonus, a side effect of happy customers who use your stuff and pay for it! A focus on improving feature delivery is too narrow. What you really want to do is improve time to value. That means articulating what value means, associating the notion of value with features that are delivered, assessing that value and then tracking so you have insight into your organization’s ability to deliver value and get better at it.

    SAFe embraces all of these concepts through artifacts and activities anchored in lean and agile practices. Try it, you might be surprised at how impactful this can be in improving your ability to innovate and be the disruptor instead of being disrupted.

    Read how a typical enterprise dipped its toe in SAFe water to drive delivery of a critical project, and be sure to visit the SAFe landing page to learn more.

    About the Author/ Amy Silberbauer

    Amy SilberbauerAmy is a Solution Architect charged with the definition and delivery of the Enterprise Scaled Agile and IBM DevOps Plan solutions and strategy for the IBM Watson IoT line of business. She is a recognized subject matter expert on scaled agile and software development lifecycle solutions, including enterprise modernization, SOA and collaborative DevOps. She has been with IBM for 29 years and has two decades of software development experience as an engineer, architect and manager. She is a certified SAFe® Program Consultant experienced in leading and consulting on multiple internal and external SAFe (Scaled Agile Framework®) transformations.

    Connect with Amy on LinkedIn.

  • Lean for DevOps: Measuring the meaningful

    Lean for DevOps: Measuring the meaningful

    At a recent Lean project report out to stakeholders, a piece of analysis was presented which showed the quantity of metrics being captured, in various areas, at different organizational levels. IBM’s Watson had been used to generate the chart, and it told an interesting story. But that story needed some translating.

    metrics eg
    ‘Look at all those metrics under ‘Managers”, said one Director, with enthusiasm. ‘Seems like they’re looking at a lot of different performance measures for their people’.
    ‘Yes,’ said the Lean Coach, ‘but is that a good thing in itself?’
    Another Director chimed in, ‘Well, when I look at how few metrics are being captured on timeliness I wonder how anyone knows how they’re doing.’

    As an IBMer, and Six Sigma Blackbelt, I’m pre-disposed towards data. Information can be power. But with too much being reported, it can be hard to see the wood from the trees. Performance metrics are intended to allow teams and leaders to improve their performance. For many of those people, reading charts and interpreting data may not be a core skill and it certainly isn’t how the organization wants them to spend their time. So those teams generating masses of performance metrics may not be doing themselves, or their leadership, a service.

    The key is to identify the critical few metrics. Ideally leading indicators of performance issues, rather than lagging ones. Leaving aside areas like SLA adherence and budget management to those responsible for governing them, these are the handful of metrics I would suggest a DevOps team needs to watch on a daily basis:

    • Number of bug fixes for top 20 systems
    • Number of critical issues, average time to close and longest time to close – looking just at the average may mask longer running issues
    • WIP: number of projects in each phase of the SDLC
    • Customer feedback for top 5 systems – preferably actual user feedback; failing that whatever you can infer from app usage. Top 5 systems may change over time as you launch new functionality or as usage changes according to the business calendar.
    • Percentage of projects who deliver 100% of their agreed scope
    • Core application availability – actual availability to users, not SLA adherence

    What do you think? What do you measure?