devopsy.kinsta.cloud

Tag: scaled agile

  • 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