devopsy.kinsta.cloud

Tag: Lean

  • MTTR: The Magic Metric

    MTTR: The Magic Metric

    How do you improve with one metric quality, cost, performance, employee and, most importantly, customer satisfaction?  I think MTTR is one to consider, but with a DevOps twist (agile+lean+ITSM). The thing I love about DevOps is that it allows for people to think differently. DevOps is the movement driving organizations to find new ways of collaborating, communicating, cooperating and improving the way they use technology to create and support services.

    While many agree that MTT stands for “Mean Time To,” there is no common agreement on the R.  I like using 5 Rs, as they cover the life cycle of idea to realization (in the hands of the customers in a way they like).

    So what are the 5 Rs? Well, let’s work backward (shift-left thinking):

    • Review: What happened? How can we stop this in the future? How can we shorten the cycle?
    • Return: Do customers agree that all is well? How satisfied are they with not only our performance but the fact the event occurred?
    • Restore: The time and effort to get servers, network, applications, data, passwords back as they should be.
    • Repair: The time and effort to resolve the issue.
    • Respond: The time to notice, decide if we can fix or get others involved, and their reactions to begin getting things sorted.

    MTTR is a cycle of events. Breaking them down and understanding the value of each step enables you to reduce time, effort, waste and cost. How often do things break and why? Are they self-inflicted because we test poorly? How can you apply automation or self-healing? How good is your monitoring and alerting and response mechanisms? How great is your documentation? Do you rely on a certain person to fix things or can anyone? Knowing the answers to these questions can make issues become less frequent—or, at least, reduce the effort to address them when they do occur, as things will break.

    Knowing these answers also helps clarify priority of issues. Working back from the customer drives the flow of work to highlight faults. Why treat all issues as P1 all month? For example, payroll is only a P1 when you are getting paid, but the rest of the month it can be a P2. Working with customers will help ensure you are fixing the important things, not something someone wrote in a service level agreement that is rarely updated.

    MTTR is also a fabulous learning measure. DevOps is all about collaboration and that begins when people talk to each other, repair things or introduce a better test or monitor or alert to capture issues and customers are minimally impacted. Let your service desk own MTTR and see how issues get resolved better, faster and more safely.

    MTTR helps drive movement to virtual or cloud. MTTR can also help you improve your A/B use of infrastructure or services.  Have an issue? We’ll flip a switch.

    But the overall goal of any metric is to drive actions, decisions and improvement. MTTR is such a measure. Be brave, throw away your SLAs, get people involved for issues and use MTTR to make things better across the life cycle. Then celebrate the success of your journey!

    Let us know. Do you use MTTR? Can you measure each step and perform a retrospective?

    About the Author / Daniel Breston

    dDaniel Breston is the Chief of DevOps Transformation for Ranger4. Daniel has 30+years leading IT Service, Operations, Applications, Data Center and service partners in management of technology enabling business processes and functions. He has also spent 15 years of consulting and coaching leadership teams across the EU and UK in developing their people, processes and use of technology to deliver technology services better, faster, safer. Daniel has qualifications in IT Service Management (ITIL, COBIT,etc.), Lean and DevOPS.

  • Lean Security: How Better Development Can Protect Your Business

    Lean Security: How Better Development Can Protect Your Business

    If companies are to reach their strategic goals—reducing time to market, boosting sales, improving product market fit and brand image, and cutting cybersecurity costs—then it’s time for a new outlook on software security.

    Today’s business leaders must learn to see security for what it is: A differentiating factor. Companies with reputations for secure developmental processes and infrastructure will rise above those known for data breaches.

    Security as a Business Strategy

    The road to a more secure company—and realizing the perks associated with it—begins with lean security. This is an approach to information security similar to the Toyota principles of management and production that calls for environmentally aware engineering, simplified coding, automation of security checks and constant incorporation of feedback.

    Although some business leaders believe organizational security is inherently expensive, lean security doesn’t mean massive costs. Much like DevOps, lean security champions process improvements and cultural changes above purchasing new tools.

    Lean security does, however, require engineers to keep its principles in mind throughout the development process. In this way, security is much like sales: A sales representatives’ best strategy is to consider his goals from the beginning. Just as the salesperson isn’t trying to make any sale, the engineer isn’t trying to create just any product. For the salesperson, this means tweaking the sales process—perhaps by vetting leads before engaging them—to make profitable sales. For the software engineer, it means structuring the development process through lean security to create secure products.

    Done right, lean security results in a self-defending, simple system created by people who are aware of a product’s real-world security risks and the company’s business goals. Lean security recognizes your company’s data is always at risk, no matter the size of the company or team, and it works to create value through systemic protection. Here’s how to start:

    Improve Environmental Awareness

    Lean security approaches risk management as a team effort. Think about a hospital. Everybody working there — from the cooks to the nurses to the executives — has a responsibility to take care of patients.

    Software firms must function the same way: Everyone from engineers to salespeople to the CIO must keep data privacy, software security and business needs in mind throughout product development and a product’s life cycle.

    Environmental awareness means addressing security with the same sensibilities that you would your own life. Just as you don’t hand your credit card to random people, neither should you hand the keys to a software engineer who doesn’t know the risks of insecure development.

    More secure coding begins with a change of mindset. Once team members understand a product’s security risks, they start thinking about how to create a more secure environment. If a developer is creating a mobile app for a car, for instance, then they must recognize the app will be used in conjunction with a device that carries human life.

    Simplify Engineering

    Complexity is the enemy of security. Simplification, however, cannot just be limited to lines of code: It means organizing your teams—and thus, your entire system—in a way that improves time to market and tightens feedback loops.

    DevOps is a great way that business leaders can improve security through sensible reorganization. While the integration of development and operations teams has been lauded as a security boosting measure by software leaders at companies including Dell, CA Technologies recently studied DevOps’ business benefits. It found companies that have implemented DevOps techniques are 2.5 times more likely to improve customer retention, twice as likely to grow their revenues and 3.4 times more likely to improve their market share.

    In short, keep teams compact and agile and design with the end in mind. The more lines of code you add, the more complex teams you create and the more times you reinvent the wheel—and, ultimately, the less secure and less profitable your company’s products become.

    Automate or Die

    Automation is an essential component of lean security, and DevOps engineers are no strangers to automation. Threats are constantly increasing, and no engineer—or team of engineers—can discover and remedy them all manually.

    Look to Netflix for a great example of automated security. Once upon a time, Netflix addressed malware alerts by manually creating a help desk ticket and assigning an engineer to investigate the problem. The time from alert generation to eventual resolution, according to Netflix, often spanned more than a week. As Netflix’s security challenges increased in both diversity and complexity, it found itself spending exponentially more time and money combating these threats.

    Then, Robert Fry, Netflix’s senior information security architect, came up with a brilliant solution: He engineered FIDO, an orchestration layer that automatically evaluates, assesses and responds to security threats. FIDO detects threats, then scores them based on the attack’s intended target and other factors. FIDO then attempts to mitigate the event by closing a network port, ending a VPN session or disabling the account.

    Tools such as Netflix’s FIDO automatically detect risks in seconds, while it could take a human months to stumble across them. Think of security automation like a home security system: ongoing, vigilant security without the need for continued manpower.

    Measure Everything

    Although its origins are disputed, many credit English mathematician Karl Pearson with quipping, “That which is measured improves. That which is measured and reported improves exponentially.”

    Development teams should take Pearson’s wisdom to heart, and measurement must begin with identification of goals. Is your goal to reduce application downtime or decrease event response time? Then it’s essential to measure mean time to repair. Do you want to reduce code defect density? Begin by measuring the number of issues per thousand (or million) lines of code.

    Once you’ve identified goals, use software to track progress over time. Etsy’s engineers built a tool they call StatsD. The software helps Etsy monitor everything from login failures to coffee availability. The data is then displayed in handy graphs to help the team make sense of the information.

    Once you’ve taken baseline measurements, be sure to review your metrics on a regular basis. For instance, you might realize an application’s deployment times aren’t where you’d like them to be. Keep measuring results—and keep trying new things—to nudge those values into better territory. Just remember: You cannot improve that which you do not measure.

    The Business of Lean Security

    The value of a secure, simple system cannot be understated: It means getting products to market faster; it means better public perception and press; it means more satisfied customers who feel secure using your product; and it means fewer disruptions in engineers’ work schedules. At its core, lean security lowers a company’s overall exposure to risk and reduces its expenses.

    Companies are already staking their futures—and consumers’ safety—on code that facilitates transactions, drives vehicles and manages power plants. The Internet of Things will soon run everything from toasters to jet engines, and security will grow even more important. Protect your company from within through lean security.

  • 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?

  • Lean for DevOps: Is it OK to move the banana?

    Lean for DevOps: Is it OK to move the banana?

    There is an urban legend about a Lean deployment which, in the process of applying the 5S to a workshop, drew lines on the desk to indicate where each worker should keep their banana.

    Katie 2 5 S deskKatie 3 5S desk 2

    5S, for the uninitiated, is a set of principles by which Lean practitioners organize a workspace – which might apply to a virtual, shared workspace, or Sharepoint repository just as well as a back office space or factory floor.

    • Sort – identify and get rid of unnecessary items
    • Set in order – organize what’s left so that everything has a logical place – including deciding on the optimum spot for banana placement
    • Shine – tidy up and clean your new workspace
    • Standardize – document and put boundaries around your newly organized workspace so that it’s obvious where everything should go – including drawing a line around that banana
    • Sustain – establish systems, tasks and behaviors to ensure your work place remains neat, organized and free from clutter

    Katie 1These are great principles to apply to any shared workspace – and standardization will speed your adoption of DevOps principles. Standardizing the way we organize information allows for fungibility, so a Quality Manager can switch teams at short notice and quickly pick up the way their new team works, and access the information they need. Standardizing storage in a way is the principle behind Docker, and other modular code concepts. Standardization can reduce errors: if user requirements are captured in a consistent way it is easier to see at a glance if any essentially information is missing before we start work. And standardization ensures consistency, for example, applying a pre-determined decision tree and criteria to enhancement requests will allow prioritization decisions to be made quickly and equitably.

    But you can have too much of a good thing, Creative activities and problem solving tasks are often intuitive or require people to take a variety of approaches until they find one that fits. A checklist just may not help here. Furthermore, one of the aims of DevOps is to increase flexibility and speed to market. So if your standard start to get in the way of that, you’ve lost your way.

    As a Lean Coach I have struggled with the amount of churn I see in requirements during the development lifecycle: at first glance it reads like rework. But it is, in fact, a healthy feature of an iterative, responsive process. Many IT departments have sought to manage churn by trying to standardize it out – setting deadlines for new intakes, and arduous change control procedures. As soon as you layer governance on top of a process, you create a need for a shortcut, and an expedited route.

    I recently ran a Lean workshop for an IT team during which we identified that 30% of change requests were going through an ’emergency’ process.  Clearly the standard process wasn’t working.

    DevOps requires standardization on an ‘as needed’ basis. This includes a standard way to handle rapid change, and variation. That standard approach must be light touch governance: make the right way the easiest way. And I’ll stick my neck out and say that standardizing where a worker keeps their snack is a step too far.

  • Roll-up your sleeves – Launch a SAFe® Agile Release Train

    Roll-up your sleeves – Launch a SAFe® Agile Release Train

    Most organizations often begin their agile transformation with a series of low risk, stand-alone pilots. While these pilots may prove that teams can adopt small team agile practices such as “Scrum” or “XP”, however these pilots often don’t help prove that your organization can adopt agile at the enterprise level.

    Scaling agile to support larger more complex programs requires gaining alignment across stakeholders, providing program-wide transparency, and delivering end-to-end value with a large number of teams to work together (e.g., 100 – 500+).

    A few months ago, I had the opportunity to launch an agile release train (ART) for a large IT project (110+ resources) at one of the financial institutions that IBM provides agile coaching and mentoring for.   The organization had been following a waterfall approach for most of their larger projects until last year when they were purchased by a larger bank that was already undergoing its own agile transformation.

    IBM was brought in to assess their current progress and provide additional training and recommendations for rolling out to large enterprise programs.   Our mission was to assist them with:

    1. Defining a set of outcomes that supported the expected business benefits and assist them in successfully launching agile programs
    2. Identifying the value streams – the long-lived series of system definition, development and deployment process steps used to build and deploy systems?
    3. Defining the Agile Release Trains – the virtual organizations formed around these value streams?
    4. How to launch an ART and what Support IBM provides for SAFe

    Here are a multi-part blog to help you launch your own train:

     

    1. Launching an ART. Where to start?

    In its simplest form, agile offers a lightweight framework for helping organizations build software using a rapid delivery approach to providing business value. As a result these organizations are able to significantly reduce the overall risk associated with software development while providing high quality products and services.

    Agile is a powerful tool for software development, not only providing benefits to the development team, but also providing a number of important business benefits to the client. In addition, many agile project teams have been able to overcome many of the most common project pitfalls (such as cost, schedule predictability and scope creep) in a more controlled manner.

    The first step in our approach was to conduct a short agile assessment (or feasibility study) to verify the scope, identify the current challenges and recommend an adoption roadmap to support the transformation for the program (110+ resources).

    Having helped a several customers with agile transformation projects along with the challenges and business outcomes associated with those adoptions, I was immediately concerned about our ability to coordinate across multiple teams.

    The organization had several waterfall programs underway and had successfully piloted Scrum on some of their social apps. The leaders wanted our help to adopt a multi-team agile approach where some parts of the organization would stay waterfall.

    After performing a quick assessment we identified the following organizational concerns

    Reedy 1

    After reviewing some of the most common approaches at the time, we concluded given the organizational challenges that the Scaled Agile Framework (SAFe) would be our starting point.   SAFe, created by +Dean Leffingwell‘s Scaling Software Agility, is a proven, publicly-facing framework for applying Lean and Agile practices at enterprise scale.

    Reedy 2In most cases we have found starting with a small to medium size program is the best place to start when attempting to help an organization scale agile in their organization.

    Benefits of starting at the Program Level:

    • A couple of key business stakeholders usually have finally say on budget, delivery teams
    • Can select program within sponsors span of responsibility / influence
    • Requires more organization than going team-by-team, but significantly less effort than a “big bang” enterprise transformation
    • Makes visible the real challenges of agile at scale
    • Gives true, fact-based measures of enterprise agility… the ability to quickly deliver quality software incrementally in a large, complex enterprise

    Here are some of the challenges of starting at the Team level.

    • Have the organization / cultural impacts that a larger adoption would have
    • Provide the visibility to “move the needle”
    • Cover enough ground. Delays dealing with the real challenges of implementing agile at scale

    Here are some of the challenges with starting at the Portfolio level:

    • Working with too many In-Flight Projects
    • Taking on too are a structure to impact (.e.g, Chaotic Architecture and Bloated Technology Stack)
    • Working with teams outside the reach of the team to really impact them.
    • Requires lean-thinking leaders and an Agile PMO who understand lean economics
    • Can be delayed due to the complex organizational and cultural changes needed for a full enterprise transformation
    • Difficult to manage software “assets” in a Lean|Agile portfolio if asset development isn’t agile

    See here for additional information:

     

     

    2. Preparing for first Agile Release Train (ART) launch?

    For any IT project to be successful (traditional, agile or otherwise), it’s vital that it has a clear vision which can be used to guide the project team in the right direction. The team should review the vision regularly to ensure program is fulfilling what it has set out to accomplish.

    Here are 3 key steps that must be done before launching the ART.

    • Identify the initial set of Value Streams

    A Value Stream is a long-lived set of capabilities used to provide a continuous flow of benefits to the business. Value Streams are typically realized by 1 or more ARTs and are the primary organizational concept for understanding how value is delivered in SAFe.

    Reedy 3Here are some questions to help identify the Value Streams

    • What are the larger, ongoing programs or initiatives that will differentiate your business over the next 2 to 3 years?
    • How do external customers perceive the value you provide? For example what are the key products or services that you provide
    • Can you describe the strategic initiatives that have 200+, 100+ or 50+ more developers / testers working together already? Do they have a high degree of interdependence between the features and components?
    • What key business processes do you enable?   What internal departments do you support?
    • What key process, cost, KPI or business improvement initiatives are targeted in this upcoming year?

    For more information checkout:

     

    • Define Vision, Scope and identify Portfolio and Program Epics

    SAFe organizes large agile projects into an scaled agile program structure containing three levels: Teams, Agile Programs (also referred to as Agile Release Trains – ARTs), and Portfolio

    The Agile Release Train is the primary organizational and operational construct within SAFe. Each ART is a self-organizing team of teams, responsible for delivering business value. Ideally each value stream should be mapped to a corresponding ART, however in many cases ART may be needed to support multiple value streams or in some cases a single value stream may require the support from multiple ART to delivered the required business value.

    Reedy 4SAFe defines an artifact hierarchy of Epics – Features – User Stories.  The agile program backlog (a.k.a, ART) containing a prioritized list of features and stories.  Portfolio epics are large initiatives in SAFe that drive business value. These initiatives typically cross organizational and financial reporting (quarters, years) boundaries. Most organizations Business epics are large initiatives in SAFe that drive business value. These initiatives typically cross organizational and financial reporting (quarters, years) boundaries.

    Reedy 5

    Weighted Shortest Job First or WSJF comes from a comprehensive model defined by Don Reinertsen as a way to improve prioritization. In IBM’s solution, WSIF is automatically calculated based on the Job size, Business Value, Time criticality and Risk Reduction/Opportunity Enablement values provided. Then, the Program Roadmap is automatically sorted based on the WSIF score and gives a ranked view of the features’ backlog. WSIF is an useful tool to help with decision making process based on factual assumptions instead of personal feelings.

    Reedy 6

    Features are usually decomposed into User Stories, which flow to Team-level backlogs, and can originate at the Program level, or they can derive from Epics defined at the Portfolio level.  Features are prioritized based on Weighted Shortest Job First (WSJF) economic decision framework.

     

    • Ensure you have established “Whole Teams”

    SAFe is based on Lean principles where the minimal viable product (MVP) epics and features are identified scheduled based on both business needs and technical constraints / dependencies. Like Scrum, SAFe assumes each agile delivery team (typically between 5 to 10) people each have all the cross functional roles necessary to deliver working solution each sprint.

    Unlike Scrum, SAFe assumes some stories may depend on each other or that multiple teams may need to work on Epic before it can be delivered. Prior to launching the ART, important to ensure that each of the teams have been formed with the appropriate set of agile practices (i.e., Whole Team) and know how to execute the ceremonies associate with Scrum / XP.   Whole team is a philosophy that involves significant collaboration between the team mReedy 7embers and stakeholders.

    Each team includes all individual who materially define, develop and deliver software for a project:

    • Any and all contributors
    • Both direct and indirect participants, such as sponsors and key stakeholders
    • Together have the skills to successfully communicate the essentials of a problem and deliver an agreed solution

     

    Here are seven tips for building an effective agile team:

    • Does the team have the skills to get the job done – they are “whole”
    • Is the team as small as possible
    • Are the people dedicated to the project and is there a single product owner
    • Have a single team lead (who is not the product owner)
    • Are team members cross functional, made up mostly of “generalizing specialists”
    • May include specialists, hopefully on their way to becoming generalizing specialists
    • Are self-organizing within an appropriate governance framework

    The greater the deviation from this strategy, the greater your project risk

     

    3. How does IBM Collaborative Lifecycle Management (CLM) support SAFe?

    As part of the engagement, the IBM team led the effort to implement IBM’s Collaborative Lifecycle Management (CLM) solution to support the Agile Release Train (SAFe). IBM DevOps combined with SAFe provides a comprehensive process and tooling platform and framework that will optimize your end-to-end lifecycle, so you can synchronize development, testing and deployment across teams in heterogeneous environments, and collaborate across all roles in the organization in the planning and execution of software delivery.

    Reedy 8

    IBM’s SAFe support provides the following key capabilities:

    • Get up and running quickly with out-of-the-box infrastructureto lead a SAFe Program
    • Improve agility and predictability with dashboardsfor visibility to adjust business goals in real-time
    • Simplify change to culture and process with quick and easy access to SAFe guidance

    Reedy 9

    Each team works in fixed-length time-boxes, called iterations or sprints, which typically last from two to six weeks. At the end of the sprint, there is measurable product increment or (PI).

    Planning an iteration is simple: From the Product Backlog, the Product Owner (PO) and the Scrum team holds a Sprint Planning meeting to select the most important stories that can be delivered in the upcoming iteration. Once the set of stories are identified, the team breaks down the work into smaller tasks and assign it to individual team members.

    Reedy 10

    The Agile Planning capabilities in RTC, can assists you doing this by several means:

    • Plans are accessible to everyone in the team – Be transparent.
    • Plans reflect the team’s position and direction – Know when you are about to fail.
    • Plans are live as they ground on work items – No unnecessary planning artifacts to be taken care of.

    IBM’s approach included a set of accelerators specifically designed to help organizations adopt a Lean mindset to take their current agile projects to the next level. Agile Planning includes a set of development practices that allow teams to plan and deliver high quality software rapidly. For more details see: see the following value-added assets:

    Finally for those teams that are using Scrum methods, here is an article on using Scrum with Rational Team Concert (RTC)

    About the Author/ Reedy Feggins

    Reedy FegginsReedy is a Lead Agile Coach and Software Architect with certifications as a SAFe SPC, Certified ScrumMaster and PMP® certified project manager with over 20 years’ experience leading successful IT projects, employing a combination of Agile, Waterfall, and RUP processes. At IBM he currently works as a Agile Coach leading large and medium agile transformations. Reedy has published papers in several magazines as well as been an invited speaker at conferences. His experience as a trainer has led to the development of several custom workshops on topics ranging from Project Management to Process Adoption.

    Connect with Reedy on twitterlinkedin

  • Steer SAFely – So how do you do it?

    Steer SAFely – So how do you do it?

    This is the third blog in the DevOps – Scaled Agile series. In the previous blogs, we discussed the characteristics of a successful enterprise agile transformation and provided specific guidance on applying lean and agile practices at an enterprise level. We covered the “why” and a bit of the “how” at a high level, making the case for the need to address all aspects of a scaled agile transformation –people, process, and tools – to achieve success.

    By now you should be asking “where’s the beef?!” You get it… now you want to do it. Great! Because we have tooling that can help. Yes, tools are just one aspect of the transformation to a continuous delivery model, but man, wouldn’t it be nice to have tools that just support enterprise scaled agile methodology out of the box so you don’t have to think about that part and get on with the hard stuff – like the cultural aspects of this transformation?

    The Scaled Agile Framework® (SAFe®) provides the “rules” for scaling lean and agile across the enterprise; the tools support those rules to get you up and running quickly.

    Let’s start by breaking down the organizational structure: SAFe v3.0 describes a methodology for scaling agile and lean across three organizational layers:

    • Portfolio: Where investment decisions are made. This is the heart of economic planning, where programs are aligned with the enterprise strategy. There may be multiple portfolios in an enterprise, even within a line-of-business. The decision hinges on strategy and funding; a Portfolio has its own strategy and its own bucket of money.Amy Blog 1 pic 1
    • Program: Where funding and strategy meet planning and execution. The Program has the resources allocated to deliver on the strategy. Programs are long-lived and require a persistent structure and mission, so they are not exactly equivalent to business-driven “projects”, which might typically have start and end dates. That said, Programs deliver capabilities in support of “projects” through their contribution to Portfolio Epics. And we will discuss more on this later.
    • Team: Where the real work gets done! Teams are solely responsible for defining, building and testing their own user stories that contribute to value delivery for a Program. They are independent and self-governing, but they do operate in lock-step with other teams to deliver software aligned with the Program vision and the Portfolio strategy.

     

    With me so far? The tooling that supports SAFe encapsulates this organizational structure, giving you places to capture things like budget, strategy and roadmaps at a Portfolio level along with the “change” artifacts – the work items that identify what will be delivered by the Programs and how it will be delivered by the Teams. By providing a system to hold the data, we can also then provide visibility into status and health of executing Programs and the means to report on trends to demonstrate measured improvement – or not! – as your transformation evolves.

    Let’s explore the tooling bottom up, as that is typically how most organizations get started with SAFe.

    SAFe Program/ Teams

    SAFe Programs and Teams are supported in IBM Rational Team Concert. A process template is provided that you can use to create a Program project area with Teams as team areas within the Program. Alternative topologies, such as Teams in their own project areas or even using third-party tooling, can also be supported.Amy blog 2 pic 2

    The process template provides:

    • Project Area Initialization
    • Work Items & Attributes
    • Plans (Roadmap, Kanban, WSJF Ranked List)
    • Reports
    • Process Guidance

    Everything you need to quickly initiate a new program and kick off program increment planning, is available and ready for your team to get started.

    SAFe Portfolio

    In the next release of the Rational Collaborative Lifecycle Management (CLM) solution, IBM will provide support for the SAFe Portfolio, rounding out our SAFe V3.0 support. As with the Program process template, the CLM Lifecycle Project Area template will provide a Portfolio tooling infrastructure that joins change management with requirements and quality management to fully support the execution of the Portfolio. Through a set of template, we provide you with:

    Amy blog 2 pic 3

    • Portfolio Artifacts & Attributes
    • Plans (Roadmap, Kanban)
    • Reports
    • Process Guidance

    As a starting point, the Portfolio includes a set of Programs as team areas, allowing you to easily identify the resources involved in each Program.

     

     

    SAFe Key Concepts

    In the last blog, we discussed three key SAFe concepts that we believe are required to achieve success: Kanban, WSJF for relative ranking, and PI Objective to capture and assess value delivery. Each of these concepts is supported by the tooling.

    Kanban System

    At both the Portfolio and Program levels, the tooling provides a Kanban plan view to enable your team to drive relative ranking and prioritization discussions based on the Kanban System.

    Amy blog 2 pic 4

    WSJF

    To help your Program drive backlog planning, the WSJF Ranked List view is provided with the capability to actively lead a planning session making changes in-line to create a ranked list of Features.

    Amy blog 2 pic 5

    PI Objective

    The PI Objective is a work item artifact provided by the Program process template, allowing you to capture planned and actual value delivery consistent with SAFe guidelines. In the next release, we will also provide a new calculated attribute that captures the percentage of value (actual / planned) so that we can provide trending reports that demonstrate the Program’s ability to deliver value over time.

    Stay tuned for more with the next few blogs in the series coming soon. Till then do read the last 2 blogs if you missed them earlier – Scaling Lean and Agile for the enterprise: All hands on keyboard!!! and Steer SAFely – Driving collaboration across multi-disciplinary teams.

    Also, learn from the experts here:

    To learn more about our ongoing SAFe support, visit the SAFe Landing Page: http://ibm.biz/safesupport. We look forward to your feedback! And please join IBM at AgileDC, October 26, 2015, Washington D.C. Submit a proposal through August 15, 2015. URL: http://agiledc.org/2015-call-for-proposals/

    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 Systems – Application Platform 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 28 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

  • Steer SAFely – Driving collaboration across multi-disciplinary teams

    Steer SAFely – Driving collaboration across multi-disciplinary teams

    This is the second blog in the DevOps – Scaled Agile series. In the first blog, Scaling Lean and Agile for the enterprise: All hands on keyboard!!!, we discussed the characteristics of a successful enterprise agile transformation and described why engagement and commitment across all disciplines in the organization is not just optional, but required, to ensure you deliver differentiated value. Business and IT must be in sync because, as we have learned through experience, successful agile team-based development does not by itself guarantee organizational success.

    What does it mean to “be in sync”? How do we do it? Well, you Steer SAFely, of course. I know, a cute play on words, but just think about it for a moment. Consider a typical “day in your life”. From the time you wake up, you navigate through your day crossing paths with others along the way and continually adjusting in response. Your husband beats you to the shower, so you go get another cup of coffee. A guy crosses three lanes of freeway traffic (in front of you!) to get off at an exit he’s nearly missed, so you slow down a bit. You get a last-minute request to do something by the end of the day, so you engage with a colleague to get it done. Some of this is more reaction than collaboration, but nonetheless it is a siAmy blog 1mple analogy for Steer SAFely: Steer, which implies a series of continual adjustments to enable you to maintain course, and SAFely, which applies guidance and best practices as you Steer. The notion mirrors some of the basic concepts embraced by the IBM DevOps framework:

    • Being aware of your surroundings (understanding dependencies)
    • Recognizing and avoiding risks and roadblocks (monitoring and adjusting based on feedback)
    • Working with others (collaborating)

    Clear as mud? In a nutshell, to Steer SAFely means, as an enterprise, you are applying lean and agile principles to accelerate value delivery. To be successful requires collaboration of multiple disciplines across business and IT, continuously, from planning to development to deployment to delivery and then back to planning in response to feedback.

    Let’s explore how you do this.

    Step 1: Shift how you act and make decisions:

    1. Focus on delighting the customer instead of making money. Making money is the result, it should not be the goal. This notion is specifically enforced in the SAFe Portfolio layer, which requires the organization to take an economic view to help guide business priorities based on an understanding of the value of something versus its cost.
    2. Reconsider the role of bosses. Management’s role is to enable those doing the real work to be as efficient as possible by recognizing and removing impediments quickly, end-to-end. Agile used to mean “no management”, but enterprise agile is not the same. You need managers but their role is different. The SAFe tiered approach clearly describes the responsibilities and activities of managers at each level so that there is no confusion.
    3. Avoid steering top-down or bottom-up. Neither of these methods leads to success. Instead, drive collaboration horizontally across the organization and involve all disciplines early and often in the decision-making process. SAFe explicitly addresses this notion through a set of well-defined events and activities that are designed to engage the entire multi-disciplinary team.

    Amy 2

     

    Step 2: Ensure the transformation completely addresses all aspects of the environment:

    1. People: Establish an organization-wide culture with the right set of skills to embrace lean and agile values – everywhere, across all teams, every day
    2. Process: Apply lean and agile principles in the planning, development, deployment and delivery of value and then monitoring feedback to improve – continuously
    3.  Tools: Provide a framework that enables the implementation of lean and agile practices – easily

     

    The trick is to balance efficiency and effectiveness so that you can answer these questions in a positive way:Amy 3

    • Are we moving as fast as possible? Efficiency in execution is achieved through lean practices to minimize waste and maximize time in value added work.
    • Are we driving in the right direction? Effectiveness in execution is the result of smarter steering by quantifying value and cost tradeoffs through continuous feedback and better delivery analytics.

    Step 3: Adopt (at least) these three SAFe concepts:

    Kanban System: Kanban embraces lean principles to ensure that you invest just enough at the appropriate phase of your lifecycle within your capacity to do so. SAFe describes a phased analysis approach bounded by Work in Progress (WIP) limits and grounded in economic thinking to quickly rank work based on not only value but also cost.

    WSJF: Weighted-Shortest-Job-First is a value assigned to each of the key SAFe artifacts: Portfolio Epic, Program Epic and Feature. This value essentially defines an estimated return on investment and enables your team to consistently and relatively rank work across the Portfolio to drive priorities down to the Teams. Use of WSJF enforces the economic view in planning because it ensures that both value and cost are considered as you prioritize work.

    PI Objective: SAFe describes a Program Increment (PI) Objective artifact at both the Program and Team levels as a way to document expected and realized value in a relative way. Here, as with WSJF, consistency and relativity are most important, not precision. PI Objectives are also a way to capture the notion of acceptance criteria, which could guide solution-level validation.

    To learn more about our thoughts on SAFe and DevOps, try this: SAFe® with the Power of IBM DevOps.

    And please join IBM at AgileDC, October 26, 2015, Washington D.C. Submit a proposal through August 15, 2015. URL: http://agiledc.org/2015-call-for-proposals/

     

    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 Systems – Application Platform 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 28 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

  • Scaling Lean and Agile for the enterprise: All hands on keyboard!!!

    Scaling Lean and Agile for the enterprise: All hands on keyboard!!!

    Lean and Agile methodologies are nothing new, but in the last few years we have seen the emergence of several frameworks combining elements of both. The IBM DevOps framework is one clear example. Combining principles of Lean and Agile into a single framework enables scaling of the core benefits to the entire organization, not just pockets of experts dispersed across functional silos. The goal?

    • faster release cycles, increased responsiveness, reduction of waste, lower cost base
    • increased software quality, customer-centric feedback loops, cross-discipline collaboration

     

    Roger blog1.png

    That said, these process transformation initiatives too often remain confined within the Engineering or IT side of the house. And given that more and more large scale software projects (mobile and web) are driven and managed out of the Marketing or LOB organizations, we need to get to a place where Engineering/IT and the Business share a common vision and framework for continuous software delivery. This blog will discuss key areas where the Business needs to engage to truly scale these benefits to the organization level.

    Let’s take a look at the key principles behind these frameworks and highlight those which mostly impact the behavior of analysts, project/program managers and LoB executives on the business side:

    • Optimize the whole: Development teams cannot get it right by themselves. The business must be actively engaged to ensure customer/user needs are properly understood, in-turn ensuring the intended outcome of the application/system is well communicated and understood, and eventually the overall effort is continuously steering toward the right business outcomes
    • Eliminate waste: Identifying/removing wait time to reduce overall turn around and cycle times (active participation during needs/requirements analysis, timely inputs into work prioritization, immediate feedback on early prototyping/release). Discover the hidden factory!!!
    • Empower people: Let the real user directly represent their needs, and build interaction systems and processes that make it easy for those with the needs to engage across the lifecycle

    The most common symptom that engineering and the business are not in sync is a constant flow of “management urgencies” that are forced into the current sprint or iteration. These “must do now” urgencies are a massive source of distraction for the teams executing the work on both the business and the engineering side. Directly responsible for substantial loss in productivity across the whole chain, as well as a prominent source of friction in relationships between business and IT, these distractions and interruptions can be avoided with the right level of orchestration and collaboration.

    So which are the crucial touch-points where the right level of engagement from the business can generate the most impact?

    • Early definition of business needs: This is not about producing lengthy system requirements documents, it’s about interaction with software architects and designers early and often to properly describe the needs/expectations of the target users/customers, it’s about making sure the overall context is defined and understood. There will be several opportunities to get into detailed requirements as the work unfolds.
    • Early involvement into definition of success/acceptance criteria: When I was a BA, little humbled me as much as thinking I had done a good job describing a business requirement only to then freeze when I was trying to define objective criteria that would serve to develop user acceptance test plans. Forcing the definition of acceptance criteria at the time requirements are defined often surfaces areas of the needs that could be better defined or drives important exchanges between engineering and the business.
    • Early and on-going engagement into prioritization: Gone are the days when setting up priorities was the result of a monthly or quarterly exercise; customer/user behaviors change continuously, so should your alignment to their needs. Prioritizing monthly or quarterly is like driving your car on the freeway in a pitch dark night and turning on your headlights every 2 mins or so to get an idea of where you heading… a lot can happen in 2 mins driving at 100km/hour. Prioritizing is also no longer an exercise in faith/best-guesses/loud voice in the room…. this new world is about constantly adjusting based on validated learning; running A/B testing, driving early prototyping and experimentation, monitoring application usage, social media analytics all serve to drive the right backlogs/priorities of teams across the software delivery lifecycle.

    So where to start?

    Roger blog

    This transformation is a journey, not a one-time call to action, different paths can be taken depending on your organization’s goals, culture and priorities. We’ve helped hundreds of organizations over the years plan their way forward, helping them structure teams and investments while respecting their constraints and objectives. Be bold, take this on-line DevOps Practice Self-Assessment! Or visit our blog on IBM’s support for the Scaled Agile Framework (SAFe).

    Also, do visit us at Agile 2015 to experience IBM DevOps solutions for collaborative development, continuous testing and continuous release and deployment.

    About the Author/Roger LeBlanc

    Roger LeBlancRoger is the Strategic Offering Lead, DevOps Application Platform driving the Enterprise Scaled Agile solution. He joined IBM following the acquisition of Systemcorp ALG, serving as Managing Director, Professional Services and has since been involved in ensuring a smooth transformational journey for the clients. He has a credible perspective and proven track record for meeting executive stakeholders expectations and goals. Roger has contributed to revenue growth and customer successes as well as provided strategic oversight and guidance of customer engagements.

    Connect with Roger on linkedin

     

  • Will DevOps Kill IT Outsourcing?: Part 1

    Will DevOps Kill IT Outsourcing?: Part 1

    Part 1: DevOps and outsourcing like oil and water

    After nearly two decades of steady IT outsourcing for the sake of savings and efficiency gains, the shine seems to have worn off from this once glittering phenomenon. And according to many experts, DevOps and continuous delivery practices are playing a big part in many enterprises’ plans to reverse course on outsourcing key functions in their technology stack.

    “DevOps transformations emphasize collaboration, which is often at odds with outsourcing arrangements,” says Jeff Gallimore, founding partner at Excella Consulting. “Outsourcing arrangements often reinforce stovepipes and silos rather than break them down. And silos are speed killers and barriers to improvement.”

    According to a report out earlier this spring by outsourcing research firm Information Services Group (ISG), average outsourcing contract values saw their worst first quarter in a decade, dropping by 27 percent year-over-year. Big deals over $30 million were particularly hit hard, declining by 25 percent in both number and value.

    Even without the tidal wave of Agile and DevOps practices seeping into enterprise IT over the last few years, many organizations are already predisposed to take a second look at their outsourcing contracts, says Gallimore, who sees time and again that many businesses aren’t getting the value they thought they would from their outsourcing deals.

    “I hear many more negative experiences organizations have had with outsourcing arrangements than I do positive ones,” he says. “Poor quality. Higher-than-expected management overhead required. Inflexibility. Process challenges. All are reasons cited for why the arrangements didn’t live up to expectations.”

    The anecdotal stories are also piling up of big name enterprises pulling more of their IT resources back in house after years of outsourcing. For example, General Motors made waves three years ago when its CIO Randy Mott said he would completely invert the outsourcing ratio the car company had by 2017. The firm continues to make headway in changing from 90 percent outsourced IT to 90 percent insourced, with many of the positions advertised these days focused on DevOps and innovation-related roles. Similarly, David Smoley, CIO of pharmaceuticals firm AstraZeneca, went public with his goal to shift the company from 70 percent dependence on outsourcing to 30 percent, along with a commitment to Agile and lean development.

    As organizations increasingly witness the business boosts gained through a more collaborative DevOps delivery model, they are seeking ways to adopt continuous delivery practices across their entire software delivery lifecycle. But they’re finding that these practices are often wholly incompatible with the outsourcing arrangements they’ve developed, says says Jonathan Braunhut, chief scientist at KEMP Technologies. As he explains, many organizations will need to “unwind” these arrangements if they want DevOps to work well because in many cases the contracts and SLAs that govern them are inextricably tied with waterfall development.

    “Outsourcing in an enterprise setting is often implemented in a way that advances outdated waterfall-like practices and processes that are antithetical to continuous delivery,” Braunhut says. “The very wall between dev and ops that the DevOps movement seeks to eliminate can become codified in outsourcing agreements, as a reasonable means of achieving an enforceable and accountable contract.”

    More specifically, outsourcing tends to fly in the face of DevOps’ lean ethos, which is to “minimize handoffs and waste and increase quality by thinking about the overall system and flow,” says Gallimore, who believes that traditional contractual arrangements simply can’t operate with the kind of agility necessary to establish speedy and iterative cycles of continuous delivery.

    Perhaps even more fundamentally flawed in the outsourcing relationship is the idea of ownership. As many organizations finally recognize the value that IT brings to the table—more likely now to serve as a revenue generator than a cost center—it doesn’t make as much sense to give up so much ownership over the technology and tech-enabled services that could potentially transform the business.

    “To be most effective, enterprises need to own the transformation, and it has to be a truly collaborative effort across disciplines–business leadership, engineering, system administration, security & compliance,” says Thomas Enochs, vice president of customer success at Chef. “Collaboration and transformation are difficult to achieve with outside third parties or vendors. They need to own and drive the change themselves, and not be dependent on others.”

  • Lean for DevOps: Mapping the tributaries and deltas of demand

    Lean for DevOps: Mapping the tributaries and deltas of demand

    Here at IBM’s Lean practice we use a diagram called ‘Mississippi’ to analyze demand. It is not so-called because it originates in Mississippi – in fact I’ve been given to understand that this tool was developed, and named, in our UK practice*. Instead, it’s called the Mississippi because, like that great river, demand comes from many different sources (or tributaries) and can leave a process through a number of different points (the delta). And, apparently, at times the Mississippi delta reflects tidal patterns and flows upstream. In the same way, demand can route back into, or upstream within, a process – for example, in the shape of rework.

    We want to analyze the volume and frequency of demand for a number of reasons. Understanding demand helps us to:

    • Identify ‘runners’ (everyday requests), ‘repeaters’ (less frequent, but not unusual requests) and ‘rarities’ (infrequent requests). This might be in terms of user groups, applications, or type of request (for example – small changes vs major project). When we design our improved future state, we will design it for runners and repeaters. Sometimes the impact of exceptions can be so painful, team’s lose sight of how infrequent they are, and design a process to prevent or manage those rarities – which will be inefficient for all those runners and repeaters.
    • Identify failure demand – Where are additional requests re-entering the process, as rework? Where is there process activity which doesn’t ‘go anywhere’?
    • Illustrate channels in and out of the process, so we can identify potential control points, or illuminate a lack of filter, and see where demand might be routed in via unexpected channels.
    • Tell us what we don’t know: which elements of demand are we unaware of? We need to understand all demand so that we can build and resource (load level) a process which can meet that demand. Sometimes finding out what we don’t know is a lesson in itself.

    These benefits are as relevant to Lean for DevOps as in any other area.

    It’s hard to say what you’ll learn from conducting this analysis, until you’ve done it, as every Mississippi is different. But to demonstrate some of the valuable lessons I’ve learned from drawing up Mississippis, here are some real life examples:

     

    Lightbulb moment: 'Churn is a fact of life - we need a better way to handle it'
    Lightbulb moment: ‘Churn is a fact of life – we need a better way to handle it’
    Lightbulb moment: 'We need to start saying no to enhancement requests'
    Lightbulb moment: ‘We need to start saying no to enhancement requests’
    Lightbulb moment: 'We have way too many changes taking the emergency route: a faster 'normal' route will reduce that demand and the associated risk.'
    Lightbulb moment: ‘We have way too many changes taking the emergency route: a faster ‘normal’ route will reduce that demand and the associated risk.’

    In their different ways, each of these helped make the case for a shortening of the SDLC, closer coupling of development to business demand, and a more nimble deployment process.

    *If you’ve seen this in use outside of an IBM engagement, I’d love to hear about it! Find me on Twitter to set the record straight.