devopsy.kinsta.cloud

Author: Contributor

  • Continuous Testing: Shift Left and Find the Right Balance

    Continuous Testing: Shift Left and Find the Right Balance

    You may have heard the term “continuous testing,” but are struggling to understand what it is and how to achieve it. Project teams need to improve their ability to test and perform test automation when needed, not just when possible. Service virtualization allows teams to test earlier and more often in the life cycle, or “shift left,“ by mimicking unavailable systems. Combining test automation with service virtualization enables teams to provide immediate feedback on quality—so issues can be resolved faster and cheaper. Encouraging and embracing this immediate feedback on the quality of the solution enables businesses to deliver high-quality innovative solutions to the market quickly.

    In addition to shifting left by using service virtualization, finding the right balance of effort across all testing practices is crucial in achieving continuous testing. The diagram below shows the key test practices that enable continuous testing, and teams spend effort on each of these practices regardless of whether they want to. The questions below may help your teams understand where they are spending time, and perhaps where their time might be better spent.

    Testing

    • Defects – Are teams spending too much time logging, triaging or analyzing defects? What about time spent on defects that aren’t “real” defects—where there is a misunderstanding between the test and the code? Or what if they could prevent entire schools of defects from ever being created in the first place?
    • Test Management – Are teams spending time manually crafting status reports and rolling up test execution results? Or do they have a tool that provides that information in real time and allows stakeholders to drill down as needed? How do teams know if they are on schedule with their test effort, behind schedule or even ahead of schedule?
    • Test Automation – How efficient are teams at re-executing existing tests? Do they run most or even all of them manually? If they’ve automated tests, are they focused only on functional tests at the user interface layer, or are they running functional API-layer tests, performance tests and even security tests? Do they have a robust and maintainable test automation framework?
    • Analytics – How do teams know which tests they should run, when and even why they are running those tests at those times? How good is their test effectiveness–meaning, are they running the fewest number of tests that find the largest number of problems? Impact analysis is critical in selecting the right sets of tests to execute whenever they get a new build.
    • Test Environments – Are teams constantly waiting on test environments to be provisioned and configured properly? Do they run tests and discover after the fact that the test environment wasn’t “right,” so they have to fix the environment and then re-run all the tests again? Do they hear from developers, “It works on my machine!” but it doesn’t work in the test environment?
    • Service Virtualization – Are teams waiting for dependent systems to become available before they can “really” test? Are they using a “big bang” approach to conduct end-to-end system testing, where they throw all the components together and hope they work and interact properly? Can teams test exception and error scenarios before going to production? Are they testing the easiest parts first just because they are available, and delaying the high-risk areas for the end of the testing effort?
    • Test Data – Do teams have the needed sets of production-like test data to ensure they are covering the right test scenarios? Are there exception and error scenarios that we can’t execute because they don’t have the right sets of test data?

    If any of these problems or ideas resonate with you, here is guidance on how to get started on the journey to achieve continuous testing.

    First, identify your bottlenecks:

    • How good is your test efficiency – are you able to run the needed tests and provide feedback quickly?
    • How good is your test effectiveness – are you running the fewest number of tests that find the largest number of problems?
    • Bottlenecks may also be upstream or downstream from actual test execution effort – are you waiting on dependent systems, or test environment provisioning?

    Then, look at all aspects of your test effort and focus on the largest bottlenecks first.

    • How long are your delays in test environment provisioning, and are the environments accurate when they are provisioned? If delays are too long and environments aren’t correct, automate your test environment provisioning and configuration to eliminate manual errors and gain accuracy and reliability.
    • Are you waiting on dependent systems to start testing? If so, use service virtualization to simulate those unavailable systems so you can start testing sooner.
    • Are you unable to run all the needed tests before the next build is available? If this is the case, automate your high-risk regression tests to improve test efficiency.
    • Do you find performance problems late in the life cycle, or even in production? Outages can result in long-term damage to a business, so conduct load, performance and stress testing earlier in the life cycle.
    • Do you find significant problems when all systems are integrated? Identify and agree upon system interface and data definitions, and create automated integration level tests for the high-risk integration points.

    Teams that improve their test efficiency and effectiveness significantly reduce their expenses and the time it takes to get high-quality, innovative solutions to users. You can’t test everything, and you can’t automate all your tests, so it is critical to find the right balance. Also key is service virtualization, which allows testing to begin as soon as a build is made by mimicking missing dependencies. By combining test automation and service virtualization, teams can test earlier, or “shift left,” so they gather feedback faster than ever.

    Learn more about using service virtualization to shift left and avoid downtime in test environments in our upcoming webcast:  How Maersk Uses Service Virtualization to Shift Left and Avoid Test Downtime.

    About the Author / Marianne Hollier

    MarianneMarianne Hollier is an IBM and Open Group Master Certified IT Specialist in application development. She has strong, practical expertise in measurably improving the software development life cycle and driving the necessary cultural changes to make it work. She is instrumental in architecting, tailoring and deploying the IBM DevOps best practices as well as appropriate software development tools on many types of projects, from large to small, long to fast-track, agile to traditional. Marianne is especially passionate about all things testing—process, tools, culture and automation. Her experience is broad-based, spanning both custom projects as well as standard software packages that apply to many industries, including refining, pharmaceutical, telecommunications, health care, financial, automotive, government and retail. Connect with Marianne on LinkedIn or Twitter.

  • SAFe and DevOps – a recipe for a delivery smoothie!

    SAFe and DevOps – a recipe for a delivery smoothie!

    DevOps brings you the deep pink color of fresh strawberries and SAFe the rich, creamy texture of blueberry yoghurt!

    ‘Agile’ delivery is not always smooth. If not managed well, it can be a nightmare, as those of us who have seen rogue agile processes run amok know. That’s where the Scaled Agile Framework (SAFe) comes in. It blends with DevOps to bring agile delivery to the enterprise.

    A quick word about SAFe: Those familiar with SAFe would know that it divides the work of building a system into small time-boxed units. Each unit must typically be deliverable in around two weeks.

    For instance, if you run a factory then receiving and issuing material is likely to be part of what you want to automate. You may want to provide users with features, such as the ability to create issue vouchers online, modify vouchers, cancel vouchers, or search for a particular item while creating a voucher. Some of these features may be small enough to be delivered in two weeks. Others may need to be split up further into sub-features, and so on. Let’s suppose the item search feature is tiny enough to be implemented in a couple of weeks and can therefore be considered a unit (or ‘iteration’ in SAFe parlance). The system would be the sum of several similar units, each capable of being implemented in a couple of weeks. Typically, one would assign the units to various teams, and schedule them based on their inter-dependencies and various staff, infrastructure, and other resource constraints. This composite set of small units is called a ‘program’ in SAFe. More about SAFe in a later article.

    The DevOps culture: The SAFe methodology requires that each unit be made usable within the two week interval. That is, the unit must be developed and deployed to a production-like environment. The ‘agile team’ creating the unit must therefore have an ‘end-to-end’ perspective of the unit and not be constrained by artificial boundaries of development, testing, or operations. The members should have the skills, and be willing to work in each other’s domains, collaborate actively, communicate frequently, and provide feedback quickly and clearly.

    This active collaboration between developers, testers, and operations is what DevOps is about. An organization that has a DevOps culture will therefore find it easier to implement SAFe.

    Developing on cadence: A factor which makes project managers reluctant to use agile methodologies in large enterprise scale projects is the number of multiple units (and teams) operating in parallel. SAFe attempts to simplify the process of synchronization between teams by aligning the two-week windows so that they all start and end together. By ‘developing on cadence’, as this practice is termed in SAFe, the different agile teams can align common activities like planning, review and system demos. This makes it easier for the program to identify inter-team dependencies and assess how unit-level feedback and change requests can affect other units or teams. The cadence mitigates the complexity of synchronizing work across scores of teams.

    SAFe DevOps tools: While work synchronization helps, there are certain activities that still need tools. With often several hundred code changes being checked in every day, enterprise scale projects need sophisticated configuration management and deployment tools capable of tracking and maintaining the multiple versions of code, intelligently scheduling and triggering builds and automated tests, communicating feedback about test status, configuring and creating environments, creating installers, and deploying the builds to the appropriate environments. Tools like Docker make the deployment process quicker and more flexible. IBM® Rational® solution for Collaborative Lifecycle Management (CLM) provides a suite of tools capable of working across the spectrum of tasks and managing the complex delivery process end-to-end.

    Agility over the last mile: Because of the need to deliver usable code at short intervals, testers and operations personnel need to be as nimble as developers.   While developers may have achieved success in using Agile methodologies and have efficiently been churning out byte sized chunks of code at short intervals for a while, it is only more recently that operations teams have begun to accept agility as an achievable goal. DevOps, assisted by various collaborative and automation tools like CLM and Docker, has played a significant role in changing mind sets and transforming capabilities over the last mile.

    It is this end-to-end blend of the DevOps culture with SAFe, along with the various tools that are part of the DevOps ecosystem that will propel enterprise level software delivery towards the goal of smooth, continuous delivery.

    About the Author / Vidhya V Kumar

    Vidhya V Kumar

    Vidhya is an advisory software engineer at IBM.  An evangelist and practitioner of agile methodologies, continuous delivery, and documentation, she has around ten years of experience in the IT industry.  She is a subject matter expert in DevOps, Application Lifecycle Management, and Search methodologies.

  • 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

     

  • The Calculus of DevOps

    The Calculus of DevOps

    This is the second in a series of blogs, partnering with Lee Reid, who wrote the first installment “The Simple Math of DevOps” and Sanjeev Sharma both of who are outstanding DevOps Thought Leaders from IBM.

    I am picking up on Lee’s mathematical DevOps model to apply a calculus perspective, a “calculus of DevOps” if you will, (OK, not quite core Big Bang Theory Calculus but rather approaching it from the aspects of engineering queuing theory).

    One of the cultural challenges that DevOps poses is, that some aspects of it run counter to engineering principles that many of us learned with respect to capacity and response time.   When I worked at Bell Labs, we would apply queuing theory to determine how to best package information to be sent across the network. A basic premise revolved around a tradeoff between throughput and response time. On one hand, the more messages that were packed into the packet, the more the payload would improve capacity because the overhead of processing the packet of information would be spread across the messages.   However, waiting to accumulate enough call processing information meant that the packets would be transmitted less frequently, increasing the response time.

    A simple example of this would be making trips to the grocery store. If one wanted to spend the least amount of resources (time, gas, car wear, etc.) on shopping, then one would make less frequent trips and then buy a larger amount of food. So if the Smith family made one trip a month and spent 2 hours, then their average time per week spent on shopping would be 30 minutes.   If the Jones family went every week and spent an hour, then they would be spending twice the time and four times the gas on grocery shopping. However if the Smith family run out of an item (say cereal), they would have to wait, on average 2 weeks before this was replenished. The Jones family average on any item that they ran out of would be 3.5 days in comparison.

    So when the 2014 DevOps report was published[1] which states that areas that deploy more frequently get customer feedback more quickly, that is to be expected. But what’s not expected is that these organizations also have higher productivity.   So exactly what is happening here that seems to be in a basic conflict to the principles of throughput and response time?

    Keeping up with the JONESES

    If we think of a pre- DevOps state for a medium to large enterprise, it may be typical for applications to only be released (deployed into production) a few times a year to provide business functionality. (I assume there are more frequent releases for “unplanned work” like defects and other changes or operational work). For the sake of this discussion, let’s call this the Smith Application. So from a business perspective, the business wants to pack as much work into the Smith releases as possible given they only have a few cracks a year at getting new business functionality into production.

    SMITH APPLICATION CHARACTERISTICS:

    • Deliver Business Value 3 times a year (every 4 months)
    • Cost is C1
    • Business Value (BV) delivered is V1
    • Average time from concept (e.g. Story) being ready to be pulled from the backlog to the time it is delivered to the customer is 2 months plus any additional wait times (e.g. prioritization)
    • BV delivered per year is 3*V1
    • Cost per year is 3*C1

    Now let’s transport over to the Jones Planet where the application is released into production with new business capabilities at the end of every 2 week iteration.   In this case the business is more concerned with providing a constant demand flow into IT than they are with debating over whether a given feature/story is going to be included in this particular release.   Instead there is a constant prioritization (or continuous planning) process that ensures the highest value work is being fed into the IT pipeline.

    JONES APPLICATION CHARACTERISTICS:

    • Deliver Business Value 26 times a year (every 2 weeks)
    • Cost is C2
    • BV delivered is V2
    • Average time from concept (e.g. Story) being ready to be pulled from the backlog to the time it is delivered to the customer is 1 week plus any additional wait times
    • BV delivered per year is 26*V2
    • Cost per year is 26*C2

    Based on the previous engineering analysis, we would expect the following:

    1. SMITH annual cost (3C1) < JONES Annual Cost (26C2)
    2. SMITH annual BV (3V1) > JONES annual BV (26V2)

    So the tradeoff (we would believe) JONES is making by delivering more frequently is that they are spending more money and are delivering less business value on an annual basis.

    However the data from the previously referenced DevOps report is just the opposite. In fact the findings are that enterprises that deploy smaller units of work more frequently have much higher quality and much higher productivity (Capacity). So what’s going on here?

    A NEW PARADIGM

    If you go up to any IT team (even an agile one) and ask them why they don’t deploy business value more frequently, they will generally refer to the following types of wait states of waste that they encounter:

    • Waiting for work (lack of consistent flow)
    • Waiting for somebody else to do something (dependencies from other teams)
    • Waiting for environments (contention)

    One major root cause of this is the dependencies that arise from large enterprises packing a lot of work into infrequent releases. From a planning perspective, the process is elongated due to prioritization discussions because being on the wrong side of the line can mean delay amounting to months, in delivering a product to a customer.   Ask a business portfolio leader what their highest priority is for IT and I am guessing they can tell you in a matter of seconds. However, most large organizations can spend several months a year planning their annual portfolio of work for IT. Some organizations spend more than 50% of their new project build time prior to a single story entering an agile development team’s backlog!

    From a development perspective, packing a lot of work into releases means many more dependencies that have to be managed across initiatives and impacted applications. From a testing perspective, downstream environments (ST, UAT) have to manage much more information in terms of application versions and especially test data that complicate and slow down the process. The complexity of test data increase is proportional to the number of pairwise relationships that exist within the datasets required for testing.   As such, the testing complexity will increase non-linearly (perhaps proportional to the square of the dependent systems) and from a release and change perspective; there is a lot of coordination necessary given how much is being changed at one time.

    All of this work to manage all of the dependencies found in medium to large enterprises completely eliminates any potential savings one might get from batching work into a single delivery. In addition, the possibility of having to pull some work out of a release (due to quality or business readiness or some other reason) sometimes leads to complicated source code management (feature branches in some cases) that further complicate the process of merging frequently into the trunk. These types of practices also serve to drive up technical debt. So looking at the problem from this angle shows why results we are seeing make perfect sense.

    Productivity is inversely proportional to the number of dependencies in a release

    As Lee related to in the initial blog, a lot of an organization’s success depends on trust. And one factor of trust is clarity which speaks to understanding the changes that each release is bringing to the IT and customer environments. So a factor that is working against trust is the notion of delivering more things less frequently and better controlling change somehow, is a good notion.

    Trust is inversely proportional to the number of dependencies in a release

    There is another hidden component of waste associated with “big bang” initiatives. Go back to our grocery example for a moment. Chances are that the Smith monthly excursion results in buying some stuff they end up not using. Perishable items are not spread out very well when they aren’t purchased more frequently. Likewise in IT planning, we tend to put a bunch of stuff in our IT Delivery basket that we don’t know for sure that we will need and we end up with a lot of wasted effort for features that are hardly used or not needed at all. Some enterprise estimates are that 50-65% of what they put into large releases does not actually result in true value to the business. Doing more frequent releases allows a constant discovery process to better guide the usage of IT resources on what is truly of value.

    Waste is proportional to the size of a release.  

    In other words:

    Yield (Value per IT investment) is proportional to the frequency of releases.

    REVISTING THE MATH OF DELIVERY TIME

    So if we revisit Lee’s model

    Lee Reid Blog equationand apply the “Calculus of Release” as we stated above, there are increased costs associated with having larger and less frequent releases in medium/large enterprises.

    • Planning cost TPLAN
    • Development complexity TDESIGN + TDEVELOP + TBUILD
    • Testing Complexity TTEST
    • Release and Change Management Complexity TRELEASE + TDEPLOY + TEVALUATE

    TRUST % – Even if everything was proportional between the JONES and SMITH models, the component of trust that impacts clarity, consistency and collaboration, is much lower for large (SMITH) releases.  Given that TRUST has a multiplicative impact, this alone can account for the results found in the studies.

    CULTURAL CHALLENGE

    While clearly one needs to be sensitive to the changes being introduced into the business, having the ability for the business stakeholders to pull capability when they want it and having it available more frequently is not only good for customers but also has extreme benefits from an IT perspective in terms of increased productivity and reduction of technical debt. The challenge is to convince leaders in both the business and IT areas on the merits of doing more continuous planning and frequent deliveries.   Unicorns may have led the way in this type of thinking but it is actually the horses that will benefit most from this type of culture shift because it is the horses[2] that have the most to gain in mitigating the dependency factor which can undermine quality, productivity and cycle times.

    Read more about the topic in the next blog of this series The Art of DevOps by Sanjeev Sharma.

    [1] “2014 State of DevOps Reports”, Puppet Labs, IT Revolution, https://puppetlabs.com/sites/default/files/2014-state-of-devops-report.pdf

    [2] “The Phoenix Project”, Gene Kim, Kevin Behr, George Spafford, http://www.amazon.com/The-Phoenix-Project-Helping-Business/dp/0988262592

     

    About the Author

    CarmenCarmen DeArdo is the Director of Application Development Tools and Technologies at Nationwide Insurance. Carmen is responsible for driving continuous delivery utilizing DevOps, Lean and Agile techniques across Mobile, Distributed and Mainframe and other technologies. This includes recommendations and implementation of technologies used across the development life cycle (e.g. IBM Rational tool suite, open source technologies).

  • Why DevOps for the database must include three way analysis

    Why DevOps for the database must include three way analysis

    Deployment automation is critical to practicing effective DevOps. Without deployment automation, releases still require a lot of manual steps and processes. Processes and steps that aren’t reliably repeatable, are prone to human errors, and can’t be handled consistently with high frequency.

    However, the software best practices can’t simply be grafted onto database deployments. Unlike software code, a database isn’t just a collection of files. You can’t simply copy a database among your different development, testing, and production environments. Deploying a database also presents a greater business risk since it holds your most valued asset – your data.

    In order to capitalize on DevOp automation advantages for databases and to promote database changes safely and quickly, all the particular components of a database; its tables, functions, and content, need to be protected.

    Any successful DevOps database automation solution must be capable of intelligently dealing with conflicts and merges of code and cross updates from other teams. The solution must be able to ignore wrong code overrides and give the user ultimate control over which changes and merges are pushed out.

    unnamed (5)

    In order to achieve these goals a DevOps for the database solution must be able to conduct a three-way analysis on the source (that is, the object after the development work is done), the original (or “baseline”) state, and the target (or “Production”) environment, identifying the differences among these three states. Team members, gaining full knowledge of the complete scope of the project from the analysis, can review the results and options the solution presents to resolve any discrepancies. The user selects what action, if any, should be taken on the database. The solution then automatically generates the scripts to execute the chosen actions.

    In this way, the solution uses automated three-way analysis and automatic script generation to eliminate both the potential for human error in manual script writing, and the potential for technological error in automated object overrides.

    Reaping the Rewards
    Implementing a solution that encompasses all these automation features to meet the particular challenges of database deployments, would enable a company to practice a DevOps approach to effective database automation and realize the following benefits:

    · Reduced deployment costs through streamlining of development process management

    · Minimizing deployment risks by enforcing change policy and best practices, and configuration management and consistency

    · Improving responsiveness to customers and market needs with speedier roll-outs of task-based development updates

    · Enhancing cross-team communication with clear audit trails and transparency regarding work done on objects and the state of different environments

    Can you afford to be without it?

    About The Author ⁄ Yaniv Yehuda, CTO, DBmaestro
    unnamed (4)

    Yaniv is the Co-Founder and CTO of DBmaestro, the leading provider of DevOps for Database solutions which enable control of database development and deployment. Yaniv is also the Co-Founder and the head of development for the Extreme group, a leading IT services solutions provider group.

  • Five mistakes enterprises make while implementing automation

    Five mistakes enterprises make while implementing automation

    Automation, if done right, can add a ton of value to an IT organization.  Benefits include speed, quality, and improved productivity.  But only a few IT organizations have been able to truly reap the benefits of it.  Why is that?  What is it that these successful companies do differently while others continue to struggle?

    Here are 5 of the most common mistakes we see when organizations try to implement automation.

    1. Automating Infrequent Activities

    Automation works best when a manual task is well defined, predictable, and highly repetitive.  The first two dimensions are key in determining if an activity can be automated.  The third helps determine if it is worth automating.  Yet when organizations decide to automate, they focus on the first two and rarely consider the third.

    For example, automating code builds is a popular activity to automate.  It clearly meets the first two dimensions.  But if the project plan only calls for monthly builds…what is the point?  At best all you have done is saved the developers a few hours of work.  However, if the same automation is used for projects that require daily / weekly code builds.  Now you are literally eliminating hours of work.  Translate that to annual effort saved and you end up moving the needle.

    2. Automating In Silos

    Hand offs are the silent killers of efficiency.  However, most IT organizations are arranged as a series of hand offs (silos) – from requirement to development to testing to operations.  And like most silos, the focus is inward, resulting in optimized silos but sub optimized end to end process.  No wonder it takes weeks to get a new code through all the way to production with, in many cases, sub-par quality.

    The true value of automation kicks in when you stich various activities into a single process, that minimizes / eliminates hand offs, and orchestrates it across silos.  In essence, you are not just automating the activities but also automating the hand offs.  This in essence, is the heart of the entire DevOps movement.  To break down the silos, re-engineer, and automate the process.

    3. Forgetting To Reengineer the Process

    If you look at the data, most processes follow the classic 80/20 rule.  20% of the process time is spent on performing actual “work”, 80% of the time is wasted on motion.  Case in point…it used to take us days (sometime weeks) to open up a simple IP port.  The actual time to perform the work takes only about 5 – 10 mins, however getting the work to the SME literally took days (creating tickets, routing, approvals, finding SMEs etc.).

    Despite this fact, many organizations spend countless hours finding, agonizing, and optimizing the “perfect” tool (hint: there is’nt one) and spend little to no time on process.  In essence, if all you to is focus on the tool, then all you have done is optimize the 20%.  No wonder organizations scratch their heads when they put in automation and don’t get the expected results.  Automation and process reengineering are like two sides of a coin.  If you are truly looking to transform, you cannot have one without another.

    4. Not Planning For The Long Tail Of Automation

    Pssst…let me tell you a secret.  Creating automation scripts is easy…. after all it is the sexy part of automation.  The real heavy lifting begins once you have created it and now you have to constantly tweak and maintain it.

    Applications and its components, for better or for worse, are constantly changing.  Which means that the scripts have to be constantly tweaked.  Yet few consider the after math.  In fact, our clients have so many scripts that they simply don’t know what to do with it.  A better solution is to plan for the long tail ahead of time, set up a governance model that is responsible for updating, maintaining, and pruning the scripts and in turn protecting the investment that they have already made.

    5. Fear That Automation Will Take Their Work Away

    Fact – many of our clients are leery about automation.  Not because they feel it will not work, but are afraid that it will work too well.  And that success will eventually lead to good people losing their jobs.

    There are three key issues with this line of thinking.  First, the assumption is simply incorrect.  While automation will eliminate certain types of tasks it also creates new type of work.  After all you need someone to manage the automation.  Second, the genie is already out of the bottle.  Automation is here to stay.  Ignoring it will only make catching up to it harder.  And third, not implementing automation may have the exact opposite effect and speed up unemployment.  Look at Netflix (poster child for automation) vs. BlockBuster.  A better strategy is to start small now, while the industry is still trying to figure it out, and try to get ahead of the curve.

    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.

    His expertise is in DevOps, cloud, lean, application development, outsourcing, offshoring etc. and has published several articles on DevOps.  He lives in San Francisco Bay Area, is an avid blogger (when time permits), a speaker, and advisor to start ups.

    You can follow Mustafa on LinkedIn: https://www.linkedin.com/in/kapadiamustafa and Twitter: https://twitter.com/mkapadiatweets

  • How Continuous Delivery is Changing Software Development

    How Continuous Delivery is Changing Software Development

    When you start to implement a new methodology, it’s very easy to get bogged down by the specifics and lose sight of the overall goal. With Continuous Delivery, we see endless debate about whether to use Puppet, Chef, or Salt for deployment, or discussion about how to build a CD pipeline with containers. These are just technical challenges to overcome. They’re implementation details that have little to do with why CD is such a powerful choice for businesses.

    What’s the most important metric for your software? It’s not the speed of delivery, the number of features, the performance under load, or the defect count. It’s end user satisfaction. The question you need to ask and keep asking is – How well does your software cater for the people using it?

    The CD mindset keeps you laser-focused on that metric in two very important ways.

    Real representation for the end user

    Too many organizations are still just paying lip service to this concept. The developers and testers working on a piece of software often have no contact with end users, and that can mean that they have very little idea about their needs. If you really want to create a great piece of software for someone, then you have to understand how they work. What are their requirements and constraints?

    Traditionally, software development has been siloed. Individual departments have focused on their own tasks first. Developers may be delighted with their clean repository layout. QA may be satisfied with how complete the test coverage is. But neither of these things tells you about the end user experience. The system may be completely unusable.

    Personal contact is a great idea. If your team actually talks directly to end users, asks questions, and learns to empathize, then you’ll see the benefit in the product.

    CD also encourages greater visibility. Not just oversight for management, but for the whole team. Everyone, from development, through QA and operations, to the actual end users should get a look at how the overall service is being put together and delivered. Have channels in place so that anyone can contribute to service improvements, regardless of their area or expertise. Greater visibility over the process, and an ability to influence it, makes for a really cohesive, motivated team.

    Collecting, analyzing, and acting on the right data

    You can empower everyone on the team to make suggestions and you can say that end user satisfaction is paramount, but without collecting the right data you aren’t going to be able to realize the benefits of this approach. You need help understanding where the opportunities for improvement are, and it’s vital to measure the impact of what you’re doing.

    In the big data age, it’s common for companies to collect all sorts of statistics. It’s easy to automate the capture of technical operational details such as CPU load or memory usage, but how much do they really tell you? Though it may be more challenging to find out whether your end users are satisfied, it’s also a lot more important.

    Eliminate the risks of educated guesses and gut feelings. Apply a solid methodology to improve your service based on user feedback, just as you hone technical performance based on technical data. You don’t need to spend hours brainstorming new features. You can analyze end user interaction, find a pain point, create a hypothesis about the cause, tweak the system to address it, deploy the change, and measure how it really performs.

    Adopting this process and repeating it over and over will improve your service. Because you’re rolling out small changes, it can be done quickly and efficiently, with easy rollback if required. As long as you’re careful to measure your hypothesis and the effectiveness of your solution each time, there’s no downside.

    The ideas here are nothing new. Your marketing department most likely already conducts A/B testing and measures user interaction. But how many companies are really taking the holistic approach, applying these concepts also to software development and delivery?

    To make the end user the focus, and really leverage the potential of Continuous Delivery, the whole team has to pull in the same direction. Agile and CD methodologies help you cut down barriers, set shared goals, and keep the focus firmly on the customer to revolutionize the way software is delivered for the people who need it.

    About the Author/Andrew Phillips

    AndrewPhillipsAndrew Phillips heads up product management at XebiaLabs, a provider of continuous delivery automation. Andrew is an evangelist and thought leader in the DevOps, Cloud and Continuous Delivery space. He sits on the management team and drives product direction, positioning and planning.