devopsy.kinsta.cloud

Tag: Lean

  • Not Everything That is Necessary Adds Value

    Not Everything That is Necessary Adds Value

    Since the Lean production method for manufacturing arose in the 1930s, organizations everywhere have been seeking ways to apply it to reduce waste and increase productivity. This model has served thousands of companies well, from manufacturing and product design to software development. Yet, one difficulty that comes up when discussing or applying Lean in software development is the debate about what is and isn’t considered value-added work.

    Some people get defensive when certain activities are labeled non-value-add (NVA). Others argue that if a customer expects an activity and is willing to pay for it, it must be value-add (VA). From my perspective, software engineers, business leaders and others must accept the reality that it’s entirely possible for necessary processes to add no tangible value. We must understand the intent of Lean within these classifications. In doing so, we can get past the defensiveness and disagreements and move on to improvement.

    Let’s explore a few examples of NVA activities that are unavoidable—and therefore necessary—to a successful software development value stream:

    • Resolving important defects
    • Rework to meet client specifications (i.e. after clarifying requirements)
    • Project time tracking and billing (i.e. for time and materials projects)
    • Complying with regulatory mandates
    • Testing

    Some customers expect these activities to be performed. Software professionals generally agree that all of these NVA activities can be necessary. Yet many Lean proponents will continue to insist that they are NVA and should be minimized. So, where does that leave us?

    Distilling ‘Value’ to Its Essence

    Regardless of how important or necessary NVA activities might be, from a Lean perspective, unless an activity is adding value to the finished product, it is technically an NVA activity. Testing is an NVA activity. Defect correction is an NVA activity. Complying with regulations, although important to protecting profit margins for the company—and an activity that might incent customers to select your product over your competitor’s due to their reduced risk—is nevertheless a NVA activity.

    This is where we enter the grey area of “necessary but NVA activities that actually add a lot of value.” One prominent example is resolving defects that cannot be postponed. You’re probably shaking your head and thinking, “No way. Resolving defects increases quality which makes the finished software product more valuable to the end user. Therefore, it must be a value-add activity.”

    The answer is actually, “No, it is not.” Why? While the cost of defect resolution may be incorporated into the final price tag of software, there is no line-item charge for it. Most purchasers will not pay extra for defect resolution. They’ll feel that quality software is essential to their project and defect resolution should be included.

    Furthermore, they believe quality should be built-in— designed into the product and the process used to build it. That makes it an NVA activity. It’s necessary to the delivery of quality software but it doesn’t add value in the Lean sense of the term.

    The truth, whether or not business leaders want to acknowledge it, is that NVA activities are built into almost every product or service. When someone goes to pick up a prescription at the pharmacy they are never asked to pay an extra research fee. When someone test drives a car and decides to purchase it, they aren’t charged for the gas they burned during the test drive. Both of those activities were necessary for the final outcome to be satisfactory to everyone, but they added no value to the effort.

    The same is true for successful software delivery. Lean approaches form the foundation for modern software development, but being Lean doesn’t mean that you have eliminated all NVA activities. In fact, quite the contrary.

    Lean suggests that perfection is never achieved. A Lean organization values continuous improvement and is always looking for ways to reduce NVA activities. For all software projects, some elements will always be NVA. The perpetual existence of both value-add and non-value-add are facts of life.

    Optimizing Necessary Activities

    Despite the fact that these activities might be necessary and, therefore, part of the project cost, they don’t have to be excessive. Responsible software professionals and the companies for whom they work will make an extra effort to reduce waste and optimize outcomes in all NVA activities.

    Reducing or eliminating waste is one of the most important tenets of Lean software engineering. Waste can be found everywhere, from too many people working on a project and ineffective communication to an excessive number of manual processes, backlog mismanagement and rework.

    Breaking the Stigma of “Non-Value Add”

    Companies must develop quality software and sell it at a price that pays for the effort. In my experience, the way to do that is by evaluating every activity. Consider whether it is VA or NVA and whether it is essential or non-essential. Then reduce or eliminate the NVA as much as possible, even if it’s essential, and optimize the VA.

    Software professionals should be ready to defend the importance of the many necessary but NVA activities that go into a quality outcome, while remaining unapologetic about calling them what they are—a process, procedure or other activity that adds no value.

  • Does Agile Methodologies Work for IT Infra?

    Does Agile Methodologies Work for IT Infra?

    Recently, I had a fascinating conversation with my old friend Joe–the name has been changed but the conversation is real and unedited–an IT Infrastructure program manager from a large IT service provider.

    After a bit of chit-chat on weather and football, we started talking about infrastructure in a typical large enterprise.

    Joe: I am not sure how agile applies to infra space, I can understand it works well for software development, but not in IT Infra space.

    Me: OK, why do you think so?

    Joe: Well, we have lots of coupling between components, infra projects tend to be big migration or upgrade moves and highly risky. I know many large enterprises in Europe that we work for and many of them haven’t looked at agile in the infra space.

    Forty minutes and couple of beers later…

    Joe: I have to send four reports every Friday afternoon on status, risks, issues.

    Me: Why do you need so many reports?

    Joe: I can’t share all the same info to the client that I share internally. There are some risks that we manage internally. My client wants the info on Jira and confluence. My regional manager wants it on an internal tool (some five-word acronym that I forget!). My account manager wants it as a PPT, as this is an important account and he says this needs to be tracked closely. My global manager wants it on a different tool, inherited from a previous merger as my employer was recently acquired by another service provider.

    Basically, most of my Friday is spent copy pasting information across these reports. Then I spend most of Mondays reconciling the numbers and responding to follow-on queries, and Tuesdays justifying the cost of resources, change in resource costs because many projects are usually in Amber or Red. I think it usually works well if I have a good PMO.

    Me: How many people do you have on the current programme?

    Joe: We have four PMs and seven infra resources on this infra upgrade and migration programme. There is a different provider who looks at the application changes and they have a team of managers and developers etc. The seven infra resources I referred to are also busy with BAU work.

    Me: So, you have seven part time infra people who are the actual doers, one programme manager, four PMs and PMO, client side vendor manager(s) and you are running half a dozen projects.

    Joe: Yes, as you can see, we can’t be agile in infra.

    Me: Why do you need projects? And, why do you need so many of them?

    Joe: What? No projects? Surely, that’s how it is always done! How do we ensure control, governance?

    — Aditya Vadaganadam

  • Will ITIL V4 Bring Order to a DevOps World?

    Will ITIL V4 Bring Order to a DevOps World?

    It is difficult to dispute the importance that the ITIL (Information Technology Infrastructure Library) approach has had on the world of ITSM (IT service management). After all, the best practices established by ITIL V3 have come to be the accepted way ITSM providers conduct business—so much so that many other IT processes have come to look to the ITIL framework to bring order and control to complex processes.

    Yet, ideologies such as DevOps have struggled to adapt to the somewhat rigid doctrine of ITIL V3, instead favoring Agile methodologies to meet the rapid deployment of updates and the iterative cycle of software development. Perhaps, the Agile-versus-ITIL differences can be attributed to how life cycles should be managed and how the management of those life cycles impact both development and operations in the IT space. Nevertheless, change is coming to the world of ITIL, which may help to make the framework more suitable for DevOps practices, and perhaps make ITIL and Agile symbiotic in the field.

    The ITIL V4 framework is scheduled to be released in Q1 2019, some two years after it was announced by AXELOS at the Fusion 2017 conference. “ITIL is the most firmly entrenched ITSM framework in the infrastructure of large, complex organizations, with many—if not most—Fortune 500 companies using it,” said Cathy Kirch, president of itSMF USA, the organizer of FUSION 2017 and the leading independent professional forum for IT Service Management professionals in the United States. “Currently, ITIL and complementary practices, such as DevOps, Agile and Lean, are used successfully in conjunction with each other; however the next evolution of ITIL will promote and underpin dynamic collaboration.”

    The More Things Change, the More They Stay the Same

    ITIL V4 doesn’t propose to completely rewrite the ITIL V3 narrative; in fact, the core elements are expected to remain the same. ITIL V4 will simply include new material on integration with additional best practices aimed at mitigating some of the biggest criticisms around ITIL V3, the less-than-ideal relationship with the ITSM community and failure to keep up with recent trends in software development and IT operations.

    In essence, ITIL V4 will address those criticisms by shifting V4 to a community-driven initiative and integrating other practices such as Agile, DevOps and Lean into traditional ITIL best practices. That means ITIL may become complimentary to those other frameworks and begin to embrace other services management best practices in the context of new technologies, such as serverless, containers, microservices and multi-cloud.

    With the DevOps community picking up steam, the Agile Manifesto and Lean development displacing ITIL V3 in some practices, it will be interesting to see what impact ITIL V4 will have on the IT industry as a whole. While it is far from ITIL’s last gasp, ITIL V4 will face significant challenges in a DevOps world that is constantly changing. However, with more than a million ITIL V3 certificate holders worldwide, ITIL V4 will definitely garner a great deal of interest when it hits the streets on Feb. 28.

    — Frank Ohlhorst

  • Is Your Organization ‘Fit for the Future’?

    Is Your Organization ‘Fit for the Future’?

    Takeaways from a recent conference suggest more work is needed in DevOps adoption among organizations

    This was a question explored by CIO Platform Nederland and the DevOps Agile Skills Association (DASA) in a recent event I attended, hosted by Transavia. Many organizations have already embarked or are about to embark upon Agile transformation initiatives, driven by growing business demands. This event focused on sharing experiences, learning from the practical examples (successes and lessons learned) from Transavia and ABN AMRO, and exploring the way forward to successfully create a high-performing IT culture that is “Fit for the Future.”

    The event was well-attended—unsurprising, really, when you remember the wise words from the late Robert Stroud, former Analyst at Forrester: “To unlock the promise of DevOps, CIOs must lead and support a cultural change within their technology management organization, but as any leader knows, changing institutionalized behavior is the toughest of all management challenges. CIOs must recognize when a trend becomes an imperative for survival. DevOps has become this imperative.”

    DevOps and Agile transformations being seen as imperative for business survival. But not just business survival, according to the “2017 State of DevOps” report, which declared, “By 2020, half of the CIOs who have not transformed their teams’ capabilities will be displaced from their organizations’ digital leadership teams.”

    Rik Farenhorst, CIO of Transavia and chairman of the DASA Leadership Forum, presented lessons learned from Transavia. He stressed the importance of changing mindsets and giving equal, if not more attention, to creating desired “behavior” change and not relying too heavily on structure, processes and automation and hoping that the right culture emerges. “People first,” “live your values” and “lead by example” were his key messages, stressing that values must be translated into corresponding desired behaviors as well as unlearning old ways of doing things. Another important discovery was accepting that not all teams are so far and not all teams can mature at the same speed.

    A great example of “lead by example” was the leadership team’s daily standups and visualization of strategic priorities, gaining more situational awareness and shared understanding and commitment.

    Matthijs Dee and Ivo Carton from ABN AMRO presented their journey from Agile to DevOps, also pointing out the fact that teams mature at different speeds and the need to share lessons learned between teams. ABN AMRO adopted a DevOps playbook that teams could use, containing a kind of toolkit for improving team capabilities. Equally, Dee and Carton noted ABN AMRO’s challenges in moving from “command and control” and traditional hierarchic management models to new leadership styles and behaviors. In ABN AMRO’s case, the organization needed to focus on BizDevOps—it’s not all about code, it’s about delivering business value.

    Farenhorst mentioned “values” in his presentation, while Dee and Carton mentioned “principles.” Both of these concepts need translating into team behaviors and leadership behaviors must help empower teams to make this shift.

    My presentation, “DevOps Will Fail … Unless,” I revealed the findings culled from more than 400 global teams having participated in the Phoenix Project DevOps simulation and gave a Top Three set of takeaways.

    The first was the need to focus on BizDevOps—making the shift from “features” to “outcomes” and from a flow of “code-to-commit to a flow of “idea-to-value.” This was also one of the top challenges for organizations at the most recent DevOps Enterprise Summit.

    My second tip mirrored advice from Transavia and ABN AMRO: The need to define, agree and commit to “desired behaviors” and what is effective collaboration (here is an example of what I mean).

    My third tip was embedding continual learning and improvement as core behaviors. DevOps is new and all about experimenting—it is a long journey and needs to be done as iterative improvements. At the same time, the pace of change coming at us is increasing, as is the amount of change. Teams need to be able to respond to change. I also quoted Mike Orzen, author of “Lean IT”: “Improving your work is just as important as doing your work”; as such, impediments and improvements should also be made visible on the backlog of work for teams and leaders must ensure adequate time is given and reserved for work-in-progress, for teams to improve.

    Following the presentations were three break-out sessions: “Value Creation and Management,” “Organizational Design – Agile/DevOps at Scale,” and “Sustainable Culture Change.”

    These are some of the challenges raised in the Culture break-out session I attended as a follow-up to my presentation:

    • An interesting discussion was around “control” and how to empower the management layers and have them empower the teams. As a CIO, this layer between you and the work floor can diffuse your vision by the time it reaches the shop floor and at the same time leave you unaware of what is happening.
    • Management by walking around was suggested, as a CIO being visible on the shop floor and soliciting feedback. Listen to concerns and enter into a dialogue about vision, goals and what it means.
    • Teams often are faced with fear, uncertainty and doubt (FUD) about new ways of working. What will it mean to their job? To their responsibilities? And will they be able to do it? Leaders must remove the FUD and create a safe environment. Safe to take risk, to experiment, to fail, to give feedback. Managers must foster a “no blame” culture.
    • A study by Google (2012) called Project Aristotle, named in tribute to Aristotle’s quote, “The whole is greater than the sum of its parts,” looked into why some teams work and others don’t. One of the key conclusions was that “psychological safety” was the “it” factor: A sense of confidence that the team will not embarrass, reject or punish someone for speaking up.
    • Change team behaviors. We adopt these approaches and don’t see the behaviors we expect. Not everybody wants to change. Leaders need to be able to identify the silent killers, what is under the water, what are drivers for working against. At the same time, teams need to be willing and able to work effectively as a team and need team training (not just individual training). Team training also needs to address soft skills such as communication, feedback and collaboration.
    • Leaders also need new skills in organizational behavior management to be able to identify behavior drivers and how to create sustainable behavior change.
    • Lead by example was named, but what is that? What behaviors are expected from leaders? Sometimes managers are only one step ahead in this new working. DevOps is new, there is no fixed framework; it is about experimenting what is right for your organization. This is all new.
    • Ask yourself, “Why are we doing Agile, DevOps, Lean? Are we adopting these approaches as a goal in themselves? Or are they to solve a specific set of problems or deliver a specific set of results? And how does this relate to strategic goals?” This must then be translated into, “What is in it for ME?” for the various stakeholders (business, IT management, teams, customers). Success can only be achieved end to end, which means all end-to-end stakeholders must understand the “why” if they are to commit to the journey.
    • Build empathy and trust and asking questions to get open feedback—not telling (command and control).
    • Authenticity: To build trust, be empathetic to FUD; listen to concerns; demonstrate (words and deeds) how these will be taken seriously; and recognize achievements. Empathy must be authentic; if your behaviors are not seen as real, you will lose the trust you are trying to create.
    • Shift from a (real or perceived) “blame culture.” Failure is OK as long as we learn and improve as a result. If there is no trust, then people fear consequences of making mistakes and are less willing or likely to want to experiment or speak up.
    • Leaders should show vulnerability, too. Set an example of having failed and learned. Admit in these turbulent times when new ways of working really are new, managers don’t have all the answers—it is a journey of experimenting, learning and improving and giving feedback.
    • Allow teams time to learn and discover themselves. Recognize that not all teams mature at the same speed, appropriate leadership styles and coaching for teams. Use external (to the team) coaches.
    • Be prepared for the difficult discussions and decisions. Not everybody can and not everybody wants to change. If you are dependent upon heroes, get rid of them—literally or metaphorically. One example noted was a toxic working culture with teams held to ransom by the hero, while another example was having the hero share knowledge, coach and create more T-shaped capabilities.
    • Look for “change champions” in teams—peer level respect. Empower them with the right skills and recognize their contributions and the team successes. “Give a podium” to success from desired behaviors such as experimenting, learning and improving.

    From the discussions it was clear that C-level managers need to learn new skills and demonstrate new behaviors, while management layers must learn more behavioral and organizational change skills. Teams must not only learn DevOps technical skills, but also team-building and soft skills.

    CIO Platform Nederland and DASA will be organizing future events and sharing content and experiences from member organizations to address these needs as a follow up to this kick-off event.

    — Paul Wilkinson

  • Using CALMS to Assess an Organization’s DevOps

    Using CALMS to Assess an Organization’s DevOps

    Of the tried-and-tested frameworks that allow enterprises to assess DevOps in their organization and how it can be improved, the CALMS model remains particularly useful.

    CALMS, which stands for Collaboration, Automation, Lean, Measurement and Sharing, is particularly helpful for analyzing an organization’s DevOps structure, and ultimately, its utility in any organization. The CALMS framework covers all stakeholders within DevOps, including business, IT operations, QA, InfoSec and development teams, and how they collectively deliver, deploy and integrate automated processes that make business sense.

    “DevOps as a technique is slowly but steadily maturing, so it’s good to see general assessment methods like the CALMS model,” Holger Mueller, an analyst for Constellation Research, said. “The CALMS model gives a good frame of reference to compare the maturity of a DevOps team, and as such,  is invaluable for assessing the state of teams for the transformational change that goes with it.”

    Applying CALMS

    Here are a few ways CALMS can be applied to DevOps for enterprises either thinking about shifting to a DevOps structure or seek to make improvements to an existing deployment.

    Culture

    It is long-established that technology adoption must be to serve a business need rather than investing in technology for its own sake. This shift in mindset applies to how the “culture” component of CALMS supports how the forecasted ROI associated with automating a process must be championed across the DevOps team. This mindset is especially important for getting the non-technical business teams onboard, Mueller said.

    “DevOps must have the backing from the business executives. That’s a crucial factor in the culture part,” he said. “One thing software teams can do is use successful software deployments to help convince the business executives in DevOps to make the investments. Those are the kinds of tribal events that every DevOps organization needs.“

    Automation

    Netflix is well-known as an exemplary case study for DevOps automation. Among other things, it can deploy code and software updates in a matter of minutes across its entire massive infrastructure, many times throughout the day. But Netflix’s example of automation does not take into account what can go wrong at firms that want to follow Netflix’s example when automating their software deployments and updates, Mueller said.

    “The risk is always deploying too fast and you end up deploying bad code,” Mueller said. “Automation, of course, needs to take this into account and compensate. But not everybody can do that.”

    Lean

    Once completed, it is relatively easy to document cost savings by eliminating resources. Within the CALMS framework, the corresponding “lean” component in DevOps is thus relatively easy to assess, Mueller said.

    The good thing about DevOps, Mueller said, is companies can come to a consensus ahead of time regarding what they consider to be a lean operation.

    However, he added, “There is always the risk of being so lean you begin to err on the QA side.”

    Measurement

    The success of software deployments is relatively easy to measure once completed. However, attempting to measure future deployments as part of a forecast model is, of course, much more challenging.

    “It can be surprisingly tricky to measure how good DevOps is ahead of time,” Mueller said. “Measurements should thus allow errors to be pinpointed  quickly during the post-deployment stage to fix the code if needed very quickly.”

    Sharing

    Sharing, in many ways, overlaps with culture. This is where assessing whether all of the different teams within DevOps are working together and communicating comes into play.

    “Thanks to  DevOps, the days of the lone developer are long gone. But sharing is not always easy,” Mueller said. “Even within separate teams, it is easy to fall into the trap of wanting to get your own work done without necessarily thinking about the team as much as you should.”

    The End Result

    While applying CALMS to assess DevOps never hurts, the framework is still not as important as one of the main objectives of DevOps—namely, using technology to make organizations’ operations more agile and reactive to customer needs, Mueller said.

    “At the end of the day, assessment methods such as CALMS are great, but they are never as important as focusing on implementing next-generation applications,” he said.

    — B. Cameron Gain

  • What is an Agile IT Organization?

    What is an Agile IT Organization?

    Agile IT is the new sexy.

    Don’t get me wrong. It has always been around. But with the rise of digital transformation, it has taken on a renewed urgency.

    For example, Domino’s Pizza has repeatedly said that the reason it was able to beat the competition was a result of its investment in building a more responsive IT organization.—an IT function that heavily relies on Lean, Agile development and DevOps best practices.

    But what does it mean to be a faster, nimble, and more responsive IT?

    Agile IT Characteristics

    Based on our experience, it comes down to the following characteristics:

    1. Bring new software/functionality to market quickly—all the way from idea to production.
    2. Experiment first mindset. Cut big ideas into small projects (MVPs) and deliver iteratively.
    3. Deliver experiences not just features.
    4. Measure success in business impact, not IT KPIs. This applies to both the idea and the teams.
    5. Create small, dedicated, cross-functional teams. They are more nimble than functional silos.
    6. Reward individuals based on their contribution to team goals (i.e business KPIs).
    7. Decentralize decision-making.
    8. Make continuous improvement part of the company culture. Failure is learning, not something to be punished for.
    9. Create short feedback loops so that you can be responsive.
    10. The sum of the parts is greater than the parts. Speeding up development and not operations drives minimal benefits.

    So how do you reboot IT capabilities to get them to be faster, nimble and more responsive? It’s more than just investing in new technologies; it’s about defining new ways of working. It starts with how work is defined and structured, how it is performed and how success is measured.

    In our next article, we will go into more details on the new ways of working, including explore how IT needs to change its mindset, set up new operating models and measure itself differently.

    — Mustafa Kapadia

  • Digital Transformation: How DevOps Could Have Revamped Toys R Us

    Digital Transformation: How DevOps Could Have Revamped Toys R Us

    The story you’re about to read and its recommendations are real; they contrast with what you have heard so far about digital transformation and DevOps implementation. Its objective is to convince you about that the time to go digital is now; it’s about transforming your business, not only IT; and to do it you’ll have to implement DevOps entirely.

    In September, Toys R Us, one of the world’s largest toys store chains, filed for bankruptcy protection. A better understanding of how disruption in the retail industry impacted the company would have helped to prevent its downfall and to reinvent its business model. For example, providing Toys 2.0 (a generic term referring to a new generation of toys built on cloud, mobility, IoT and AI technologies) gaming services could have helped the company survive.

    Shifting to Toys 2.0 demands a revolution in thinking, vision, practice and value that business leaders, CIOs and IT vendors haven’t done yet. They must forget the obsolete notion that technology and speed determine business success. Adopting paradigms that stress innovation and solve competitive constraints is the safest path toward fast and durable revenue.

    The biggest problem Toys R Us faced was the fact that consulting firms and IT vendors either didn’t understand the challenge as an industry disruption issue—or if they did, they improperly addressed it.

    Let’s clarify: To tackle your industry’s disruption, you must adapt your business model including the set of interactions, staff and skills, processes and practices, beliefs and values and infrastructure and tools used across your company to generate revenue. Industry disruption is the challenge, and DevOps through its many assets is the unique business capability companies need to quickly transform and win their digital battles.

    The problem, as Alan Shimel, founder, CEO and editor in chief of devopsy.kinsta.cloud, puts it:

    “While so many companies have already started to use DevOps or planning to use DevOps and related methodologies soon, there is only a small percentage of companies that are end-to-end DevOps. This means there is still tremendous opportunity in bringing DevOps to market.”

    How should have Toys R Us leveraged DevOps to tackle its industry’s disruption? Why did investing in that global digital e-commerce platform prove insufficient? How well did they transform their business model? How would have implementing DevOps 100 percent helped to overcome Amazon and Walmart competition?

    The principles, ideas, practices and solutions in this article are part of a case study we developed at ITaaSNow to see how to help companies facing similar challenges.

    What is DevOps?

    Alan, who is a major contributor to DevOps, is right: Only a small percentage of companies have fully adopted it. DevOps is much more than the automation toolchains consultants and vendors talk about. If they want to help lines of business survive and keep their job, CIOs must get a grasp of DevOps’ business facets.

    So, what is DevOps? Why do I think, it would have saved Toys R Us from digital downfall?

    DevOps Beyond the Operations Automation

    From my experience implementing it, DevOps is a business capability that seeks to optimize business operations (versus the sole IT operations). It provides companies with four competitive advantages needed to meet the digital business competitive challenges:

    1. Enterprise collaboration
    2. Business agility
    3. Short time-to-value
    4. Innovation culture
    Figure 1 – DevOps Overview

    As the picture shows, DevOps is a set of concepts aggregated around the notion of value stream to form a digital business management capability. It’s structured around four stages that format the company’s interactions and workflows into a powerful digital business management capability. These stages include:

    • Plan & Measure – addresses strategic watch, service prioritization and revenue generation through innovation portfolio management practices and infrastructure.
    • Develop & Test – takes advantage of agile and lean practices and infrastructure to ensure innovations design, development and testing.
    • Release & Deploy – leverages continuous delivery practices and infrastructure to timely deliver the right innovations to the right markets.
    • Monitor & Improve – stresses continuous improvement to guarantee not only premium customer experience but also customer value.

    Four business value catalysts are used to act as revenue generators:

    • Culture & Values
    • People & Skills
    • Methods & Practices
    • Tools & Infrastructure

    As you can see, DevOps transcends application development issues; it covers the entire business life cycle.

    DevOps Framework as a Facilitator of DevOps Implementation

    So, what is a DevOps Implementation framework?

    Concretely speaking, it’s a bundled DevOps platform combining managed PaaS infrastructures and optimized value streams to help companies boost their digital business:

    Figure 2 – DevOps Implementation Framework

    The platform seeks to help businesses implement DevOps end to end and builds on three principles to guarantee digital profits:

    1. Innovation as the revenue driver – It’s the belief that business can resist the competition imposed by technology companies such as Apple, Google, Amazon and Facebook when they use innovation to keep customers loyal, attract new ones and generate revenue.
    2. Value stream agility as the foundation of market responsiveness – It’s the demonstrated notion that companies are market-responsive when they rely on agile and lean value streams.
    3. Managed cloud as the catalyst of business performance – It’s the proven idea that when companies are focused on their core business, they innovate and offer superior customer experience.

    The 5-Step Digital Transformation Blueprint

    The 5-Step Digital Transformation Blueprint makes DevOps implementation fast and easy. As illustrated, it’s a comprehensive business transformation framework I developed to help clients with their digital transformation initiative:

    Figure 3 – The 5-Step Digital Transformation Blueprint

    It’s an integrated and inclusive approach to business transformation that involves the company’s relevant contributors. It structures the transformation effort into a five-stage transformation journey:

    • Digital strategy: In this step, the transformation team uses tools like the SWOT analysis matrix to help business and IT executives understand the changes in the disrupting industry along with the impacts on the company’s business model.
    • Value stream: In this step, the transformation team uses tools such as the value stream mapping to identify the required changes and get business and IT executives agree on the company’s future value stream. Interactions, staff, skills, processes, practices and tools are at the heart of the discussions.
    • Digital platform: In this step, enterprise and solution architects work together to identify and implement the technology and tools selected to support activities in the value stream.
    • Digital organization: In this step, a panel of business and IT users at the operational and executive levels experiment the new digital business model under actual business conditions. The tested digital business model is then deployed as the new digital organization.
    • Digital business management: In this operation phase, the value stream and the digital infrastructure are extensively used to run the business.

    How Chief Digital Officers Set Up Top Digital Businesses

    It would be remiss on my part not to recommend the online digital transformation course that gives DevOps practitioners—executive and operational from both the business and IT—the insights about implementing DevOps as the foundation of digital business.

    “How Chief Digital Offers Set Up Top Digital Business: Establish DevOps as the Foundation of Your Digital Business” is a 15-module course that offers concise, practical and powerful tips to help practitioners learn and apply strategies and tactics to effectively plan, monitor, facilitate and lead business transformation including IT to digital.

    Analyzing Amazon and Walmart Disruptive Impacts to Spot Guidelines for Reinventing the Company

    Many bankruptcies happen because business leaders don’t take the time to understand their industry’s disruption and the impacts on their overall business.

    The reality on the ground is, industry analyses and competitive strategies are either overlooked or totally ignored. Understanding the toy industry’s disruptive effects would have helped to identify Toys R Us’s transformation as the safest solutions to avoid bankruptcy.

    DevOps implementation framework makes the difference, it sees DevOps as the foundation of digital business success. It considers industry and competitive analyses essential steps of the DevOps transformation initiative. Figure 4 outlines the outcomes that resulted from our industry analysis:

    Figure 4 – Toy Sector’s SWOT Analysis

    As illustrated, it was shown that Toys R Us should have exploited Amazon’s vulnerabilities and take advantage of the technological opportunities to reinvent itself as a Toys 2.0 gaming service provider. These vulnerabilities include little product differentiation while technological opportunities refer to the new toy generation built on cloud, mobile, IoT and AI technologies.

    The company’s strengths—reputation, longtime industry presence, brand equity—combined with the cost savings resulting from managed cloud adoption would have not only simplified its transformation but also challenged Amazon on costs.

    Changing the Value Stream to Establish Innovation and Invent the Company’s Digital Business Model

    Business leaders don’t take the right transformation decisions because they lack insights into the changing competitive environments. Aggressive marketing and sales campaigns supporting short-term financial gains. Toys R Us failed because it bet on its debt reimbursement at the expense of its business model reinvention.

    A DevOps implementation offers a value stream mapping framework that not only facilitates innovation culture implementation but also speeds up digital business models development.

    Figure 5 – Value Stream Mapping, Agile, and Lean

    The objective of the value stream mapping I performed was to outline the features of work environments that take advantage of DevOps Three Ways to equip the company with the competitive advantages needed to resist Amazon and Walmart. The following lines summarize the outcomes.

    Implementing DevOps Flow Principle to Defeat Amazon and Walmart on Innovation: The value stream mapping recommended to leverage Agile and Lean principles to properly implement the flow principle and defeat Amazon on its little product differentiation. The Agile’s features to stress included collaboration and prioritization while focus on people engagement and customer value were the Lean’s benefits to emphasize. Their combination were likely to not only foster innovation culture but also accelerate time-to-market and time-to-value.

    Implementing DevOps Feedback Principle to Guarantee Superior Customer Experience: As to the feedback principles, the value stream mapping recommended to use Lean’s value stream assessment and Agile’s review mechanisms. The objective was to institutionalize continuous improvement practices as a means to ensure superior customer experience.

    Implementing DevOps Experimentation and Learning as the Foundation of the Innovation Capability: As to the experimentation and learning principle, the recommendation was to take advantage Agile’s prototyping and learning curve-lessening features to institutionalize innovation and risk-taking cultures. They were likely to not only help the company challenge its competitors on innovation but also ensure durable revenue and customer loyalty.

    Enabling the Value Streams with Managed PaaS Services

    Using technology ingeniously to boost business activities is clearly one of the keys to succeed in the digital business. Today’s DevOps-timid approach focused on speeding up IT operations alone not only is ineffective, but it also doesn’t make sense. It’s the entire value stream that needs optimization, not just IT.

    The findings of the digital platform assessment I performed, showed as illustrated, that the global e-commerce platform wasn’t enough to compete against Amazon and Walmart. The company was at the embryonic stage of digital transformation maturity practices:

    Figure 6 – Toys R Us Possibly at the Embryonic Stage of Digital Transformation Maturity

    The findings suggested that using technology to innovate or creating the operational conditions to cut cost, accelerate time-to-market and be responsive to market opportunities were either overlooked or improperly addressed.

    Using a digital platform engineering framework allowed me to design in a record time the following architecture:

    Figure 7 – Possible PaaS Platform for Toys R Us

    The digital platform would have built on two cloud services supporting the value stream: managed software as a service (SaaS) and platform as a service (PaaS). Let’s discuss them.

    How Managed SaaS Services Would Have Helped to Fix the Cost Leadership and Business Agility Issues

    SaaS services would have supported the Plan & Measure stage. In addition to supporting varied management activities, it would have provided two fundamental tools that possibly could have enabled the Toys 2.0 strategy: customer relationship management (CRM) and innovation management portfolio. CRM tracks, measures and improves customers’ experience, keeps them loyal and guarantees revenue. Innovation portfolio management identifies innovation ideas, supports their implementation into digital services and monitors generated value. It gives the company opportunities to disrupt and control its industry.

    The on-demand and metered billing features of SaaS services would have allowed Toys R Us to get the needed software in record time while enabling time-to-market, time-to-value and responsiveness competitive advantages.

    How a Managed PaaS Platform Could Have Helped to Address the Express Delivery Issue

    PaaS services would have supported activities covering the Develop & Test, Release & Deploy and Monitor & Improve stages. In addition to providing the technologies needed to implement Toys 2.0 gaming services, it would have built on microservices to set up the automation tool chain and accelerate innovations development and delivery.

    Wrapping Up

    The recent IT innovations are disrupting several industries and expanding the digital economy. To avoid troubles, businesses must urgently start their digital transformation. Toys R Us, Sears and many others learned it the hard way.

    It’s urgent to understand that the digital transformation of your business isn’t only about migrating your IT to the cloud, implementing automation tool chains or deploying artificial intelligence tools across the company. It’s primarily about transforming with a strategic mindset your company’s business model from the ground up.

    Digital transformation is a complex process that engages the entire company, and requires specific methodologies, practices and tools. I renew my recommendation to take the online course, “How Chief Digital Officers Course Set Top Digital Businesses“—you’ll get from it the practical vision, approach, processes, practices and tools that’ll help you create the conditions for successful digital business with DevOps.

    — Philippe Abdoulaye

  • DevOps Chat: Value Stream Mapping with CollabNet’s Eric Robertson

    DevOps Chat: Value Stream Mapping with CollabNet’s Eric Robertson

    This DevOps Chat features Eric Robertson, VP of product and engineering at CollabNet. We discuss value stream mapping, which comes from Lean methodology and has been around for a while. But do you actually know what value stream mapping is? How can it help your DevOps transformation? Eric does a good job of explaining.

    As usual, the streaming audio of our conversation is immediately below, followed by a transcript of our chat. Enjoy!

     Streaming Audio

    Transcript of our Chat

    Alan Shimel: Hey, everyone. This is Alan Shimel of devopsy.kinsta.cloud here for another DevOps Chat and our guest on this chat is Eric Robertson, VP of product management and engineering at CollabNet. Eric, welcome to DevOps Chat.

    Eric Robertson: Thank you. Thank you, Alan. Glad to be here.

    Shimel: Yeah. We’re glad to have you here, Eric. I don’t think we’ve had anyone from CollabNet, actually, on DevOps Chat before, though I think we’ve done some video interviews over at DevOps Enterprise Summit—maybe it was San Francisco in October and November—but we’re—so we’re glad to have you here. We’re eager to find out about what’s going on with CollabNet and about some of the stuff you’ve been doing. Eric, if you don’t mind, though, there might be some people out in our audience who are not familiar with CollabNet, so, if you can, just—doesn’t have to be long, but maybe a quick elevator pitch on who CollabNet is, what you guys do.

    Robertson: Sure. Sure. So CollabNet’s been around since, I think, 1999, and it was one of the foundational on the open source, with our Subversion version control software. We since then moved into the ALM, application lifecycle management, platform. It’s our product offering called “TeamForge,” where we started linking in that planning, development, and testing life cycle, with integration to tools. And now, with me, we actually extended that life cycle all the way down into the operations—thus, the concept DevOps. And now we are launching—have launched, actually, a series of products and partnerships around DevOps for our customers.

    Shimel: Fantastic. Fantastic. So, Eric, one of the things that, when we spoke off mic earlier, we spoke about value stream mapping, and I know that’s something kinda, if not near and dear to your heart, something that you’ve been involved in with CollabNet. Why don’t you give our audience—let’s start off with this. There may be people out here who, just as they didn’t know CollabNet, maybe they’re not familiar with the term “value stream mapping.”

    Robertson: Yeah. It’s very interesting. Value stream mapping is actually an older concept. It’s part of the Lean management framework. For example, many may have heard about Toyota. It was started there, as far as best practices around mapping material and information flow and how could we apply to, for example, the value chain, and pretty predominant in the manufacturing domain. And it’s kinda of interesting because I have a background in software engineering and I have degrees in computer science and engineering, but my first job was actually in architecture—not in software architecture, but actually designing building. CAD design.

    And it was interesting that, during that time, they started talking about design patterns and best practices, as far as architecting and putting together systems and designing. And I said, “Wow, this is very similar concept to what I learned back in college, when I was doing software engineering, software design.” And, very soon, that started translating into object-oriented and design patterns and things of that nature. So it’s interesting how patterns and techniques that were very popular and used in other domains, like manufacturing and architecture, now being applied to software. In other words, software is maturing, right? The software development process is maturing. It’s starting to utilize these type of practices.

    And the value stream map is just an example of that, right? It’s Lean management method for really analyzing that current state and designing a future state, based upon a series of events that take a product, a service, from its beginning through to its customer. Right? And, again, like I mentioned, Toyota—this is known as that material and information flow mapping, and it can be applied to any value chain, for example, right? And what is a value chain? It’s just a set of activities that take, for example—that delivers a valuable product or service to the market, right? So you got, in the manufacturing world, this was machines that did it; in the software world, it’s now tools that we use to deliver a product from a planning all the way to its operations stage.

    Shimel: Yep. Got it. So, Eric, this is something, obviously, that you have written and you’re talking a lot about it. Can you tell our audience, if they want—maybe if they wanted to find out a little more, where can they go? Before we dive in more than that, maybe where can they get more information on this?

    Robertson: Yes. Actually, they could come out to our website, collab.net, but, also, I recently published an article around how value stream mapping delivers a better DevOps tool chain, and we can post those links—I believe it was also on devopsy.kinsta.cloud and we have one that was delivered through TEDxBeacon, so there’s a series of outlets, and we’ll post those links there on where they can get more information about this.

    Shimel: Excellent. You know what? We’ll, for sure, do that. And then, Eric, you had also mentioned that you guys were doing some sort of roadshow or a little city tour, where you’ll be talking about this, as well as other areas of interest around DevOps and what CollabNet’s doing. What’s going on with that?

    Robertson: Yeah, so we’re actually having a series—we’re also doing it through webinars, but we’re also doing it through seminars, and we’re gonna be having these seminars throughout the different series. And, basically, what we’re doing there, what’s really critical there, is that we’re going to be not only talking about the value stream as far as more of the how this applies into the DevOps—in DevOps world, but also we’ll have customers there talking about how they are leveraging value stream mapping and how they’re mapping that to their tool chains and how they’re able to, from bare, start applying measurement, which, to them, is what they’re calling “the last mile” of DevOps, right? And it’s really—they’re gonna talk about how that provides a window to allow them to monitor, measure, improve their workflow processes, all around a series of KPIs, both velocity KPIs and also quality KPIs.

    Shimel: Mm-hmm. Excellent. So, again, I think, Eric, what we wanna do is post a—maybe if you have a schedule of cities that we can post with the notes from today’s show.

    Robertson: Yes.

    Shimel: I think that’s the way to do that. So—

    Robertson: Yeah.

    Shimel: —let’s return, though, for a moment, to value stream mapping and kinda dig in here a bit. One of the things—and, again, as we spoke about off mic, I’ve had some experience with value stream mapping—one of the things, though, in speaking to potential customers of value stream mapping, is it’s easy to say, “Oh, yeah, that sounds good.” Right? “Oh, that’s something we wanna do.” Okay, well, let’s schedule some time and I’m gonna need the right people at the table because, if you don’t have the right people there, it’s very hard, number one, to truly map out the value stream and, number two—

    Robertson: Exactly.

    Shimel: Right? And harder than that is let’s get some consensus on what we’re gonna do to make it happen.

    Robertson: Exactly.

    Shimel: You know, unfortunately, it can’t be some developer who raises his hand and says, “I really wanna make a digital transformation here and I need to convince my CIO. Can you come in and give me a value stream mapping kind of session or workshop or can we discuss it?” It’s not a one-man show.

    Robertson: Exactly. Exactly. And it is very interesting you said that because, because value stream looks at the lifecycle from planning to operations, there’re different stakeholders, right? And what’s happening in, especially in enterprise, is these stakeholders now—they have implemented the tools or they have guys that work for them or folks that work for them that implemented these tools, and they’re starting to ask questions or they already started asking questions around value. What I mean by that—you have the executive and he’ll say, “You know, my folks are telling me we did four deployments today.” Great. What does that really mean for the business?

    Shimel: Yeah.

    Robertson: Did we get little features out to the business, where they get utilized? Are they utilizing that? Did I actually place the right emphasis on those features? Right? The last release that I deployed on time, at least from a developer perspective, said I deployed this, I deployed it on time, but I’m having this increase of service desk tickets. What’s going on here? Why am I being called? Right?

    Shimel: Yeah.

    Robertson: And I _____ –

    Shimel: Oh, yeah. Exactly.

    Robertson: Right? [Chuckles] And it means that the IT office guys, right? They have their own set of—type of metrics that they’re looking at, right, and they wanna understand, right, “Is there anything impacting this release?” and without having to chase down and talk to every other person or look into every tool, to try to gather this information, right? And then you’ve got the engineers, like the QA engineers, and now compliance, security’s coming into play as well, right?

    Shimel: Absolutely.

    Robertson: So now folks wanna know, “Before I deploy, did all this pass through the quality gates? Was this sufficient?” Right? “What about security and compliance checks? Can I automate that feedback? Can I get that feedback to the appropriate stakeholders?” Right? So they’re already involved in asking these questions, but they really don’t have any direction there on how to get that information. And this is where—this is the impetus to say, “Well, you know what? Now’s the time to start looking at these tools, where you’re gathering this information, what’s generating this information flow, and how we bring this together.” Right? So it kinda starts to endow that value stream mapping conversation pretty well.

    Shimel: Yep. Excellent. Excellent point. Because, like DevOps itself, value stream mapping is a team sport, right? And—

    Robertson: Yep.

    Shimel: And it’s cultural and you need that group kind of involvement to make it happen. So, Eric, I’m sure you probably have a few war stories around this, though. Can you share with us sort of—you know what I always say? You learn more from your failures than you do from your successes.

    Robertson: Oh, my God.

    Shimel: Can you share with us maybe some value stream mapping engagements that didn’t work out and, of course, only if you’ve learned something from it, and what was the valuable lesson you learned?

    Robertson: Exactly. I mean, that’s—it’s very interesting that you said that because we had one customer—and I can even use it from my experience. I mean, I worked at a company and I used to dread Wednesday mornings because Wednesday mornings was—wasn’t really a scrum meeting, but it was more of a meeting as far as, “What is the latest status of this release that went out the previous day?” because we did weekly deployments,  weekly deployments. And everybody would dread that because it was really no place to go to get a full understanding that, “Well, if this release actually was deployed, what was in that release? If it wasn’t deployed, what was the bottleneck in there?” Right? “Was it that it failed a certain testing that it didn’t get through or did we discover that, in this environment, we did some monitoring and it didn’t pass this stage?” We had no idea. I mean, did the builds fail? Why? There was no insight to anywhere in that chain, right, from the planning, ’cause it’s all kinds of activities that are happening in the coding, the building, the testing, the deploying a release.

    And so, if you don’t really have an idea, as far as that information flow in a place where you can go and view that information and quickly understand “What are my exceptions, right, that I need to quickly identify and quickly address?” everybody’s chasing their tails there. And I’ve been on so many projects where that transpired and happened. And so this was really impetus of why we wanted to start having—start putting—leveraging this best practice, leveraging these practices, and then the tooling becomes more secondary type of aspect, rather than primary goal for driving processes.

    Shimel: Yeah, I agree with you. The tooling then winds up taking sort of a backseat to it. So let’s—well, we’re almost out of time, unfortunately, Eric. As I mentioned to you, the 15 minutes goes quick. We do the best we can.

    Robertson: No worries.

    Shimel: Let’s put—

    Robertson: I’m enjoying it.

    Shimel: —value stream mapping to the side a little bit. What else is—

    Robertson: Sure.

    Shimel: What else is going on with CollabNet?

    Robertson: So CollabNet is also partnered with a company called “Clarive”—it’s release automation software—and what we’re doing is is that we’re linking the release automation capabilities into our value stream management platform. Now what’s nice about this is that this allows us, very quickly, to start getting metrics across different type of applications and projects. And what I mean by that is, if you go into a larger enterprise, for example, they – of course, they’re experimenting with container type technology and Web-scale IT technologies, but they’ve also got some legacy applications, right? There may be Java, right? There’s—or on WebSphere or a traditional type of applications or architecture. They may even have mainframes or they may even have package apps, right?

    So one of the things that we’re doing is that we’re getting—we’re creating this abstract _____ layer around all those tools, so customers can have, enterprises can have a common user experience around release automation, whether or not—so, again, we’re abstracting the tools, so you’re focused on the process, and it doesn’t matter what tooling is utilized underneath. If it’s Webscale IT technologies, container-based technology, it does not matter. You can basically have a common release process across your different type of applications—package, legacy, and traditional—so we’re very excited about that.

    Shimel: Excellent. Sounds very cool. Eric, we’d love to talk more to you about this, but we kind of are over time. What I’d like to do, though, is maybe invite you back and we can talk. You know, we’ll leave value stream mapping for a moment and we’ll talk about other stuff next time, but I think we’d like to hear what’s going on in the world of DevOps, obviously, and with the players in it, and CollabNet has certainly been on the scene here and lots to tell. Until then, though, it looks like we’ll call it a wrap on this version of DevOps Chat and we’ll speak to you soon, and I—Eric, we’ve gotta get those links over. There’ll be in the notes for people who are listening in. But until then—

    Robertson: Great _____.

    Shimel: Eric Robertson, VP of product management and engineering at CollabNet, thanks for being our guest on this episode of DevOps Chats.

    Robertson: Thank you, Alan. Glad to be part of this.

    Shimel: My pleasure. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks for listening in today and we hope to see you soon on another DevOps Chat. Buh-bye.

    — Alan Shimel

  • SRE vs. DevOps vs. Cloud Native: The Server Cage Match

    SRE vs. DevOps vs. Cloud Native: The Server Cage Match

    This post supports my DevOpsDays Austin Presentation on May 4

    I don’t believe in DevOps shaming. Our community seems compelled to correct use of DevOps as an adjective for tools, teams and teapots. The frustration is reasonable: DevOps clearly taps into head space for both devs and operators who see a brighter automated future together. For example, check out this excellent DevOps discourse by Cindy Sridharan.

    As an industry, we crave artificial conflict so it’s natural to try and distill site reliability engineering (SRE), DevOps and cloud native into warring factions when they are not. They all share a focus on Lean process.

    Very simply: SRE is a job function, DevOps is a process approach and Cloud Native is an architecture.

    These three concepts have tremendous alignment because they all have the same fundamental goal: increase product delivery through improved flow. It’s really that simple. We are looking to enhance productivity using system thinking concepts from Lean manufacturing.

    SREs improve productivity by eliminating manual operations, reducing errors and improving infrastructure quality. They do this starting from the production infrastructure and working backwards. Highly automated delivery, integrated logs, systemwide monitoring and blameless root cause analysis are key tools. Before we get wrapped up in tools, the distinguishing factor for SRE teams is that they take ownership of the production infrastructure.

    There is tremendous power in assigning ownership for delivery. That’s why I see industry benefit in defining an SRE job function. A DevOps strategy is a system approach and it becomes an anti-pattern to making an individual or team responsible to own “the DevOps.”

    In DevOps, we look for ways to streamline the entire product creation flow. That often drives toward tools and techniques that SREs require; however, our goals are not department-specific. We want to work with all stakeholders including developers, product managers, testers, SREs, executives and customers. This system focus for developers becomes CI/CD pipelines, platforms, work tracking tools and other workflow elements. These tools are not specifically DevOps tools, but confusion is natural since they are often pulled into organizations due to DevOps thinking.

    This SREs should expect to collaborate deeply with other functions under a DevOps process.

    Cloud-native architecture also falls under the DevOps mandate because it strives to decompose large application stacks into highly automated collections of services. There is no magic “DevOps platform” in cloud-native design; however, teams using the architectural approach get modularity, strong APIs, service orientation, simplified configuration and build automation practices that fit perfectly into DevOps thinking.

    For example, using containers does not mean a dev or SRE team is following DevOps process or using cloud-native architecture; however, it is an indicator that they are leaning toward smaller deliverables and improved dev-production fidelity.

    Yet, SRE, Cloud Native and DevOps do have a shared enemy: Complexity.

    We’re doing a great job creating best practices and abstractions that accelerate developers and creating innovative infrastructure options in both cloud and physical. That means we are seeing dual explosions in developer productivity and infrastructure complexity. Unfortunately, this wealth has not made it into operations automation, which has been delivering incremental improvements at best. Even worse, the added workload and complexity adds pressure to SRE functions.

    Ultimately, all three of these concepts are aspects of Lean business practices; however, acceleration from DevOps and cloud native is outpacing progress by SREs. This imbalance creates risk for everyone involved because Lean is about system performance. Delays and failures cannot be isolated to a single silo.

    The mistake of seeing Dev and Ops as silos means creating false contention between SRE, DevOps and cloud native.

    If you are hearing that in your organization, then take it as a warning about how your teams are integrating Lean systems thinking into your processes.

     

    — Rob Hirschfeld

  • Scaled Agile: Faster Feature Cycle Time, Improved Time to Value

    Scaled Agile: Faster Feature Cycle Time, Improved Time to Value

    Do you remember when the business imperative was improving feature cycle time? As if we just needed to deliver more stuff faster to win in the marketplace. I wouldn’t say that times have changed, but I would say we were just scratching the surface, and rightfully so. After all, we have to start somewhere. The adoption of agile methodologies have proven successful in helping redefine the characteristics and behavior of development teams and, in the process, have certainly helped speed feature delivery cycle time. Great! Is your business more successful now?

    Our goal then, and now, should have been to improve time to value. What good is it to deliver more stuff faster if it’s not the right stuff? How do you know whether it’s the right stuff? How do you make smarter decisions so that you know?

    Agile & Lean at Scale

    The Agile Manifesto explains the key tenets of agile transformations that lead us to this thought: It’s all about value, vision and quality—and rethinking what quality means—in terms of customer value. I didn’t make this up … a team of really smart people from different organizations and industries collaborated and the result is a truly inspiring set of guidance to help teams focus to deliver faster, smarter and better. The thing is, without adopting this guidance at scale, without thinking about what value means and how to prioritize investments into the delivery of value from the top down, we’re back to the same old decision-making process that often takes us off track.

    Business owners, portfolio managers, analysts, solution architects, product managers … all of these roles that operate largely on the “business” side need to think lean and agile and collaborate with engineering continuously to drive the organization as a whole to work faster, smarter, better. Aristotle said: “The whole is greater than the sum of its parts.” Think about that in terms of creating a unified, collaborative organization that marches to the same drum beat, uses the same language, follows the same process to make decisions and drive change. Regardless of whether you are operating at the portfolio or team level, or somewhere in between, you are essentially planning and executing, planning and executing. Your deliverables may be different but the goal is the same: deliver value faster, get feedback, rinse and repeat.

    Addressing the Whole Transformation

    Convinced? Maybe just intrigued? Fair enough. Let’s talk about how to do this, starting with my warning: Change is hard, especially when you’re trying to transform the mindset of an organization and do real work at the same time, so it’s not for the weak or meek. I’m not trying to scare you, just making sure you enter this with eyes wide open.

    With that out of the way, let me enforce the need to consider the whole transformation to be successful; this is not just about the process and it’s even less about the tools that support that process. It’s about the cultural change, first and foremost. There is no tool or magic pill for that. A well-defined, cohesive process is key, however, in uniting the tribes, so in this way it helps with the culture issue. Finally, embedding a well-defined process in tooling just makes things easier because you knock off the requirements related to collaboration, traceability and reporting with the tooling. Remember: people, process, tools.

    SAFe is the Recipe

    So what scaled agile process should you use? Well, I can tell you that you do not need to develop your own process, there are several out there. I favor the Scaled Agile Framework (SAFe) for a number of reasons: it is extremely well-defined, it covers nearly any size and complexity, and it is flexible despite what some may think. At the same time, it’s just a framework—there is no one size fits all and you do not have to adopt every aspect. But you don’t need to start from scratch, either. Be smart about this and take advantage of the invaluable insight that went into the development of SAFe 4.0. My team has done that and I’ve worked with several large enterprise organizations that have as well.

    I love analogies to illustrate a point and simplify what might otherwise be complex, so let me leave you with this one: scaled agile transformations are like cooking. Start with a simple recipe (especially if you’re an inexperienced cook), learn the art and how to adjust seasoning as you go, and fine-tune the dish after feedback from your family. Then try it again. Do you get it? Same with scaled agile: Start with a good framework (SAFe), learn about it, take what is valuable from it for your organizational needs and try it out for an iteration, get feedback from your team and make adjustments to the process for the next iteration. Simple.

    Please visit our SAFe landing page on jazz.net for all things “SAFe”! We are here to help you with your scaled agile transformation (SAFe or not), so don’t hesitate to reach out.

    The IBM SAFe Team (safeinfo@bg.vnet.ibm.com)

    About the Author/ Amy Silberbauer

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

    Connect with Amy on LinkedIn.