Tag: agile delivery

  • Product IT Operating Model: The Next-Gen Model for a Digital World

    Product IT Operating Model: The Next-Gen Model for a Digital World

    Digitization presents many new opportunities for businesses to create value. At the same time, it forces IT to rethink the way it operates. Modern CIOs need an operating model that understands the blurring lines between IT and business and is designed for agility and speed. The product-centric IT operating model is rapidly emerging as the answer.

    What does the model entail? In the product IT operating model, product lines are funded based on their strategic value to the organization, from the top-down, and are supported by dedicated management and delivery resources. The entire product team is measured on a common set of goals, which include customer experience, time-to-market, efficiency improvements, quality of software and availability and reliability of production environments.

    5 Dimensions of Product IT Operating Model

    Adopting a product IT operating model requires organizations to take an integrated approach toward product-based development and embark on a journey of continual improvements. While scaling agile DevOps that aligns business outcomes with engineering effort, enterprises must focus on these five key dimensions:

    1. Organizational Change Management (OCM): Successfully transitioning from the traditional IT operating model to a product-based development approach requires organizationwide change management. An experienced IT service provider, can prove to be a key ally in ensuring a smooth transition.

    2. Culture: Culture is an intrinsic characteristic of any organization, and instituting small but effective cultural changes coupled with OCM is the right approach to transition, rather than a “big bang” change. That’s also what some of the well-known enterprises across industries are doing.

    a. Teams and Collaboration: The alignment of large teams across multiple organizational groups delivers to a common plan on the pace of change and helps to continuously embed innovation and experimentation for improved services.

    3. Structure: Product-focused and highly talented teams across design, architecture, DevOps and operations are key to enhancing business capability. By measuring the entire team on same set of goals, it is easy to enhance customer experience, efficiency and quality of software while creating a stable production environment.

    Structure also means aligning traditional application portfolios to specific business outcomes and bringing together all the capabilities and resources required for an organization to deliver on its business outcomes.

    4. Technology: If business models, organizational structures, people and ways of working are the gears that run the enterprise IT engine, technology is the grease that enables this engine to run smoothly, without friction. Two key aspects of technology include:

    a. Application Programming Interfaces (API): API-based architecture provides an extensible framework of building blocks, which in turn can be used to build powerful applications or software products. Easy maintenance is a hallmark of API-based architecture, as it can be quickly migrated further to any other target architecture.

    b. Cloud, Microservices and Containers: Modern organizations need on-demand scalability. Cloud and microservices enable just that without disturbing ongoing business operations. However, it is important to first understand an organization’s product vision and road map, business priorities, competition, pace of market transition in their area of business and industry trends before choosing cloud or container-based infrastructure.

    5. Process and Automation:

    a. Agile Delivery Model: This is a critical prerequisite to building a minimal viable product (MVP), ensuring rapid delivery of critical enhancements or delivering a suite of product features in appropriate increments. Industry-standard agile practices such as LeSS and SAFe should be used, as they allow complete flexibility to tweak the model on the fly.

    b. DevOps and DevSecOps: A DevOps culture is fundamental to adopting a product IT operating model. Continuous integration and delivery (CI/CD) require DevOps to be fully interwoven into the software development life cycle (SDLC), along with the right tools and governance mechanisms. This ensures high-quality products are delivered within short deployment lead times, along with the ability to fix production issues with low mean time to restore (MTTR) and ensure minimal to no change failure rate. DevOps also enables new-age practices such as automated testing, self-service access to infrastructure and automated performance management.

    DevSecOps goes hand-in-hand with DevOps. It ensures security aspects are built into the products across the delivery pipeline, so the products are not only fault tolerant but also fool-proof, to a large extent. An experienced DevOps team builds and integrates security tools, solutions and processes to safeguard the organization.

    c. Test Automation and Test-Driven Development (TDD): By integrating test automation into the development process, the product IT operating model allows organizations to create high-quality and quickly deployable products. Additionally, TDD enables governance to be integrated into the delivery pipeline by developing quality code in line with test cases written to describe user requirements more precisely. Tests are fully automated to ensure quality of code.

    d. Service Health: With KPIs focused on the financial health of engagement, it’s easy to set a budget based on business capabilities and product levels to meet business goals effectively. The KPI framework encompasses key KPIs such as business, financial, learning and innovation and employee engagement outcomes, while staying flexible enough for different contracting models.

    Delivering Value in a Changing Business Environment

    Digitization mandates that IT deliver on three important aspects: Improve time to market, optimize costs and increase quality.  Adopting a product IT operating model helps IT deliver on the mandate by enabling a fail-fast way to deploy software quickly and cost-effectively, without sacrificing quality. However, given the extent of change involved in the shift, it is not something that can be achieved overnight. It must be underpinned by a journey of cultural change and continuous learning, using tools such as design thinking-driven, persona-based change journeys, alignment workshops and targeted campaigns and communication. Partnering with an expert system integrator can help organizations jump-start the process and ensure on-track transition with minimal disruption to business.

    — Gagan Jain

  • 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

  • What’s the cost of build versus buy DevOps?

    What’s the cost of build versus buy DevOps?

    Nearly every business today relies on faster, innovative technology to succeed in the marketplace. How about the coffee you drink, or the movie you’re watching, or the phone on which you’re watching it? Name every business or walk of life. You can argue that technology serves to make it better. If DevOps helps deliver the best services and experiences to you, then should companies making the coffee, movies, and phones also make their own DevOps solutions?

    I completely empathize with the challenges the developers and DevOps teams face in transforming a team or company from traditional development and delivery to an agile lifecycle. I experienced this firsthand at Trend. I led a business unit that acquired a SaaS company for online backup and storage; this young company updated and deployed code several times a day. To integrate their processes into ours was painful. I wish ElasticBox had been an option then. I cringe when I consider the time and costs of lost productivity, wasted development time, and delays in getting to market.

    Faster deployment nirvana

    Every day, I speak to several technology companies. Speed is at the top of their mind. They all experience the pain of not deploying and delivering applications to the cloud fast enough. Most have some number of cloud applications, some customer-facing and many internal on both private and public clouds. To give you an idea of how widespread this pain is, see the 2014 451 Research report. The 451 Research team reported that more than 60% of businesses wanted to deploy more frequently.

    But moving from agile development to agile delivery across an application lifecycle comes at a cost. Companies calculate the cost implicitly and explicitly. I’ve heard feedback from prospects who say explicitly: “I love your product, but I can build the same thing with my developers in xx country.” They usually have many smart development resources and tend to be born-in-the-cloud companies. Others tell me, “This is not our core competency. We don’t want to maintain a cloud application manager. We want yours.”

    Build versus buy DevOps

    At what cost do companies decide to build versus buy a cloud application manager from ElasticBox or one of our competitors?

    • First, you have to answer this question: What is your company’s core competency? Do you really want to divert resources to build your own cloud application manager versus invest in your core offering?
    • Second question: What is the urgency and need? If you have time on your side, taking a year to build your own solution may make sense. If you need a solution tomorrow, then what is the cost, in terms of market impact, competitiveness, customer satisfaction, of delaying a year.

    Once you answer that, you calculate the total cost of owning (TCO) the complete lifecycle of build versus buy. These values must encompass all the phases of building and ownership: acquisition, operation, change management, training, ongoing maintenance and internal support. Time and time again, enterprises only look at the initial build or acquisition cost and fail to fully calculate the ongoing implicit costs.

    Recently, I met with a VP of Engineering who had built a barebones deployment solution a few years ago. Now she bemoans the fact that the costs of maintaining a less-than-perfect solution is too much. Her TCO calculation included the developers, ongoing maintenance, workflow delays, meetings, support tickets, delayed product launches. Her decision to now buy is a no-brainer.

    I’m not arguing that it’s always better to buy than build. But consider the factors—core competency, time-to-market delays, and TCO. We want enterprises to keep building great software that complements their core value proposition. When it comes to agile delivery, consider an experienced partner who handles the same problem for dozens of enterprises. Simplicity, flexibility and speed—those are the barometers of agile delivery success. So developers feel productive, applications deploy faster, and your customers relish the delicious cup of coffee as they watch Netflix on their iPhone.