While the pandemic was significantly challenging for businesses, it exposed the need to quickly adapt and change. Software products for internal or client use continue to provide an opportunity for a competitive edge in nearly any industry. Businesses will immerse themselves and compete in the digital economy by consistently producing better software products at an ever-increasing pace.
In the past year, two new solutions with similar names have been gaining attention: value stream management platforms and value stream delivery platforms. Both are designed to help firms improve their software development process. The end goal for both is also similar—speed up development—but how each accomplishes this goal is important to differentiate the two.
So which one should you use? We’ll cut to the chase—the value stream delivery platform provides more strategic long-term value. Here’s why.
First: Value Stream Mapping
To understand the need, you first need to understand value stream mapping. This involves visualizing the value stream processes and events from conception and creation to testing, production and, finally, release. By mapping the value stream, you can get a better understanding of the workflow and identify dependencies between the different activities, which will help you identify any blockages or impediments to delay delivering customer value.
Staying abreast of your value stream is essential to delivering value to the customer as it connects all the multiple teams, tools and applications along the way. By gaining clearer visibility into the entire software delivery process, you can then scale your enterprise by bringing other teams on board for greater collaboration. Additionally, tracking your value streams can help reduce any risks to performance, as you can easily see the throughput and stability of your products.
Value Stream Management Platforms (VSMP) Explained
Simply put, value stream management helps solve poor visibility across the software delivery life cycle. You can measure and manage the performance of your software delivery team, identify any areas for improvement and leverage best practices that support collaboration through teams. Additionally, a value stream management platform helps connect applications, teams and tools through the collection of static data used to improve ongoing delivery performance.
One benefit to using a value stream management platform is that existing toolchains remain undisturbed. The VSMP simply integrates with the different datasets across the existing process and provides the desired visibility and analytics to the different product value stream(s) across the organization.
An Underlying Problem: Toolchains
The lure of easy visibility that a value stream management platform provides is somewhat deceptive. The constant pressure to create and deliver better software faster using multiple tools and manually built toolchains has reached its breaking point:
Poor interoperability, manual handoffs and disparate data have created DevOps automation silos
The multiple test environments used through the process and the need for multi-cloud and hybrid deployments add tons of unnecessary complexity
Increased policy and security requirements simply cannot scale and remain manual
Developers are caught in the middle—they must understand both a complex development and deployment process plus build a complex product for their customers—but being an expert in both is nearly impossible.
The use of internal platform teams has beenrecognized as a way to solve this problem. The platform team is responsible for providing an easy-to-use solution; essentially treating developers as customers. In turn, the developers can focus their efforts on the software products they’re responsible for and on satisfying client needs.
How is a Value Stream Delivery Platform Different?
Many firms have learned the hard way that building an internal platform is risky, time-consuming and expensive. A value stream delivery platform replaces the traditional, manually built toolchains used today and sidesteps the risk, cost and development time involved in building a platform in-house.
A VSDP should:
Cover the entire process of planning and creation, integration and verification, deployment and operations and, finally, monitoring and improvement
Have both security and compliance capabilities built into the platform foundation
Integrate DevOps point solutions, plus easily add or change tools over time
Provide a centralized data model that creates one source of truth for the development process
Provide metrics and reports to accelerate process and value stream improvements
Improve software quality through continued enhancements based on best practices
A value stream delivery platform cuts the administrative burden on DevOps teams, allowing them to refocus their efforts on providing significantly higher value. Instead of maintaining toolchains, they can now help identify process bottlenecks, expand automation and work directly with application teams to drive standards.
Value stream management platforms provide value in understanding the process and where it can be improved. But they don’t fix the underlying toolchain problem. Instead, the improved visibility may tempt some to squeeze more productivity from developers over the short term without addressing the underlying toolchain problem. However, replacing toolchains with a value stream delivery platform can help address all these issues, and may prompt you to retire your value stream management platform.
As a senior DevOps consultant working with large organizations over many years, I have been involved in more than 70 digital transformation projects, with hundreds of applications. While many things have changed over time, one thing has been a consistent source of problems that presents a formidable impedance to these transformations. The diverse number of DevOps platforms and tool variants used in those platforms results in a chaotic software delivery environment. From the point of view of any one application, almost any choice of DevOps platform and toolchain is fine, to an extent. But when you stand back and look at the larger picture, an enterprise with many variations of DevOps platforms and tools is at best chaotic; at worst, it is a gross impediment to overall organizational agility – which undermines the very purpose that DevOps is meant to serve.
I relate to the quote “You don’t need another CI/CD automation tool. You have too many already.” The aggregate set of platforms and tools is like a Frankenstein’s monster with many incompatible parts resulting in an awkward looking product that is hard to control, replicate and evolve.
DevOps Platform Blockages
Success with DevOps requires frictionless interplay between the people, processes and technologies that need to cooperate for continuous deliveries to happen effectively. All three of these factors are impacted when an organization has too many variants of DevOps platforms.
People factors – It starts with leadership. Business leaders want to leverage the values of continuous flow of software improvement made possible by DevOps. However, the flow is bottlenecked when the services of the organization must be delivered through a disparate combination of unconnected pipelines, each with separate processes to monitor, manage, troubleshoot and maintain.
Process factors – Continuous delivery works because the DevOps platforms enable automation of processes to remove bottlenecks in flow. Process management and improvements are seriously slowed down when the details of automating the orchestration, execution and monitoring for software version management, integration, testing, security assurance and deployment processes are not standard between different DevOps platform variants.
Technology factors – Often application development teams have their own favorite DevOps platform and a chosen set of tools. However, when application development teams in the same organization choose different DevOps platforms and tools, sharing knowledge, process data and practices becomes difficult. These incompatibilities slow down the overall evolution of continuous delivery for the organization.
Requirements for a Unified DevOps Enterprise Platform
Culture barriers, process problems, and DevOps platform “wars” are factors impacting the progress of digital transformations. A new unified enterprise DevOps platform would accelerate time-to-value and realize efficient, safe operation for digitally transforming enterprises and organizations. The following are general requirements for a unified enterprise DevOps platform.
● A new unified approach that supports end-to-end capabilities for continuous delivery of software, as a managed service, for multiple streams of pipelines is needed.
● Unified capabilities should include visibility, orchestration, integration, security, compliance, governance, traceability and management of flow for application value streams across multiple pipelines.
● Businesses need unified metrics that show business value, costs of the value stream and timing for end-to-end continuous delivery flow across multiple pipelines.
● A new unified approach is necessary to simplify and accelerate toolchains that support new cloud-native and cloud-adapted applications, infrastructures, machine learning, commercial off-the-shelf and open-source software.
What This Means
Digital transformations are an imperative for modern enterprises and organizations to remain competitive. However, the transformations of many enterprises and organizations are being seriously impeded by having too many DevOps platforms and tools. A new unified enterprise DevOps platform is needed to resolve the technical problems of broken, leaky, “Frankenstein” toolchains and processes.
A well-known failure mode for business process automation is to automate a broken process. The same goes for tooling up value stream management (VSM). If you have an overly complex value stream – immobilized with dependencies, a clumsy way to move work from ideation to engineering or disagreements over who has power over the plan – then trying to tool up your value stream to make it visible is a waste of time and money.
First, form engineering teams capable of delivering business value, and form program or product owner teams to feed backlog to those engineering teams. You may need a portfolio or strategy team to set prioritization across all of the programs. If you must matrix manage your teams, ensure that the business (not engineering) is the strong side of the matrix.
Such an engineering team should be able to take a chunk of business value, a small epic, and develop, test and deliver it with very few, if any, dependencies on other teams. How you define business value in this case should be very close to how the customer would define value. It’s okay to have some component teams or service teams provide value to multiple other teams, but organize to have few of those because dependencies kill agile.
Done well, your portfolio team can have a kanban of epics in which the status of those epics is clear, instead of complicated. This is because there are few teams involved in building those epics. The portfolio team will be able to see epics move frequently. They should all slide over a column every month or three. You don’t need a sophisticated VSM console because it’s so simple. Whatever tool they have their epics in will most likely have a cumulative flow diagram (CFD) and info on lead time, flow time and cycle time for the epics. That’s the level at which they need to manage, and all the info they need is (more often) able to be in a single tool.
It’s the same all the way down, at the program and delivery team level as well. When features map to sprint goals and when velocity is stable and dependencies are few, each engineering team can understand their own process. They can manage their own value stream with whatever simple tool they happen to be using at that level.
To achieve higher levels of velocity, agility and predictability, companies need to connect people, process and tools effectively. Integration has its place, even in messed up situations. It can be a useful tactic to help deal with a complex and hard to understand value stream, but integration and VSM platforms will not automatically fix your situation. That’s because VSM is human.
2019 was an exciting year for DevOps practitioners, with DevOps adoption continuing to grow at a fast pace. Most organizations were either executing or evaluating their DevOps strategies. So, what is 2020 going to bring in DevOps, infrastructure and application automation? Here are seven DevOps predictions for emerging trends in the new year.
Customer Experience
CX will become the guiding light of the DevOps journey, and not necessarily just technology. This is a big mindset shift from the early days of pure-technologist enthusiasm. As DevOps matures, we have to remind ourselves that it’s all about making business faster, not just the cool tech.
Take advantage now:
Tie DevOps achievements to business needs and results to get executive buy-in and budgets.
Successful QA teams will start looking at their role as guardians of customer experience and not just testers.
Trust
Everyone will be talking about trust—not only in the context of zero trust networks but also in the context of making it possible for Dev and Ops to trust one another as the foundation for DevOps.
Take advantage now:
Proactively invest in creating a culture of trust. Identify causes for lack of trust in your value stream and make trust a 2020 goal.
Encourage product-level conversation and define methodology and ownership when it comes to value stream management, application and infrastructure automation. It is the foundation that everyone is working on.
Invest in staging environments—Staging environments are needed to ensure things work before you put them in production. For many of us, jumping directly to automatically deploying to production is a big step. The risk can be mitigated by investing in staging environment automation, which will be the first step toward deployment to production.
Value Stream
The DevOps toolchain is going away. In 2020 we will think value stream. The industry is maturing beyond the notion of chaining together dozens of open source tools and trying to make it work together. In previous years many felt comfortable saying that if they have a CI system in place it means they “do DevOps.” This is no longer the case. DevOps is not just CI, and DevOps cannot be established in silos. Mature DevOps needs to take into consideration the entire value stream—from planning a new capability and the business requirement, all the way to the customer getting more value and a wonderful experience.
In 2019, Gartner announced it’s the last year of the ARO MQ, as it’s not the right perspective. In 2020 we finally gain a system-level view on the value stream. More players are announcing end-to-end value stream management including Atlassian’s new Forge platform, GitLab and CloudBees. Companies are maturing and adopting system-level solutions.
Take advantage now:
Plan for platform operations. System-level value stream perspective requires roles that take ownership of orchestration and automation throughout the value stream and not just in silos.
The SRE Role Will Continue to Mature
The SRE role that started with Google bringing software development practices into Operations will continue to evolve. Increasing volume, velocity and variety of data will make AIOps solutions thrive. Also, increasing levels of automation will require smart ways to handle dynamic infrastructure and applications without losing control, and being able to track changes all the way back to the coder.
Take advantage now:
If you haven’t implemented the SRE role yet, consider how SREs can be part of your teams in 2020. Define SRE areas of responsibility and KPIs, and how the SREs communicate with the teams. Is it a centralized position or are the SREs part of the team?
Make sure you provide SREs with the tools they need to succeed including:
What are the observability solutions you use? Who uses them today? How do you analyze it and how is it communicated?
What are the production environment orchestration, deployment and configuration tools that you use today? How do you connect them to application and infrastructure automation that happens before production?
Seamless Infrastructure
We will have to make infrastructure seamless for our teams. Internal customers are also customers, and their experiences will be just as important. Self-service and empowering teams will be the main themes in the bridges that need to be built between Dev and ITOps. Public cloud, Kubernetes and serverless technologies will grow. And while it makes automation more feasible than ever, the emphasis will shift to self-service and to the end users. With more companies adopting similar approaches, the need to develop internal expertise will decrease, and we will see more off-the-shelf solutions.
Take advantage now:
Map how infrastructure is used throughout your value stream, and work on unifying the approach in product-level.
Make sure you build self-service solutions with strong focus on the end-user in order to enable and balance both speed and control. Make sure developers and ITOps are equally represented when determining an approach to infrastructure automation.
Infrastructure Automation
Infrastructure automation is going to get smarter, with a lot of AI and ML. Making sure automation is properly governed will also increasingly be important. Take into consideration security and compliance, as well as cost.
Take advantage now:
Assess infrastructure automation practices throughout your value stream. Who builds the automation? What teams and systems consume it? How do you enforce security best practices (e.g. no passwords in public repositories, using proper data sets for testing, compliance of automation blueprints)? How do you enforce cost control (e.g. tagging, reviewing cloud spend reports)?
Invest in control mechanisms before you lose control, especially in public cloud automation. If you don’t have governance in place, look at baking governance into automation, rather than adopting traditional cloud management approaches. Invest in automatic de-commissioning of infrastructure, automatic tagging, analysis of infrastructure consumption data and connecting it back to the business requirement, secrets and key management and access control.
SaaS
Open source is nice. SaaS is great. While big open source projects set the pace (K8S, Github) and are strongly backed up and funded by the industry’s giants, smaller projects are increasingly difficult to scale and glue together, especially when trying to assure enterprise readiness. The need to “do it yourself” is gradually fading, as more vendors offer products and services for supporting DevOps with clear business and support models and, as important, with OOB integrations with the ecosystem. Just Rest API is no longer enough.
Take advantage now:
If your enterprise-readiness requirements make it difficult for you to scale DevOps initiatives, consider evaluating new SaaS offerings that eliminate much of the heavy-lifting and gluing that were typical to the skills-heavy early-days implementations. If you were concerned with security, cost and skill requirement, today you can find tools that are purpose-built to support DevOps for enterprise at scale. The good news is that most of the vendors are well-aware of the criticality of integrating to your ecosystem, making it easier to achieve your end-to-end value stream vision.
Want to learn more about what to expect in 2020? Join us Jan. 23 for our Predict 2020 Virtual Summit featuring discussions from some of the industry’s best and brightest offering up their visions for the future. Sign up today for this free daylong virtual event.
As enterprises strive to digitize their organizations, whether it’s digitally transforming aspects of sales and marketing, customer interactions or supply chain, they’re undergoing a wholesale revamp of traditional businesses into digital business models. While some companies are just getting started, as we covered earlier this month in Digital Transformation: Coming from Behind, the bulk of those enterprises that have already embarked on digital transformation efforts—70% according to some findings—fail to meet their objectives.
How do enterprises flip such statistics around? We reached out to a group of experts to find out, and collected their thoughts on how organizations can attain better digital transformation results through better quantification of their efforts.
It sounds simple enough, as Cyril Attia, CEO at BeMyApp puts it: Success should be measured in alignment with the key performance indicators (KPIs) of the business. He said, when advising his customers, he makes certain “one of the main focuses is to identify if these efforts are directly related to bringing in or maintaining clients which ultimately have an impact on the bottom line.”
Stay Focused on Core Business Objectives
Not staying focused on core business goals is at the essence of the challenge. “One of the reasons that digital business transformation is so ambiguous, and in an overall sorry state, is that the objectives are not clear,” said AgilePoint CEO Jesse Shiah. Organizations should make themselves clear about their desired outcomes and what it is they specifically seek to improve, he said, adding this is best achieved by tying digital transformation initiatives to key performance indicators that can best determine the health of the business.
“Through your efforts, are you making progress against those goals, do you need to adjust course? Once you’ve found a successful formula, think about how that success can be replicated in other areas of the business,” he said.
Kyle Hutchins, a senior director at business and technology consulting firm West Monroe Partners, agreed. The key to initial success is identifying the right KPIs, starting small, and proving out the viability of the idea, he said.
“Success metrics should be tied to your overall business strategy and not live as a standalone set of KPIs. Once you have a short list identified, ensure you are tracking the progress and able to measure the impact,” Hutchens noted. “When you have a win, share the success broadly within the organization, tie (it) back to your digital vision and use that as an entry point into other areas of the business.”
Shift to Value-Based Measures
Dave West, CEO and product owner at Scrum.org contended that, when it comes to measuring digital transformation success, traditional motion metrics such as velocity, as well as efficiency on time and budget measurements, should be replaced with external value-based measures that will establish the baseline that the effectiveness of change will be measured against. “For each value stream or customer aligned team, the measures will be unique. For instance, value for one customer might be a net promoter score; for another, it might be direct revenue. However you measure value, there are three types of things that should be considered: current value, time to value and innovation,” he said.
West defines current value as to how one directly measures the current value of your product and can include measures such as numbers of users, revenue, profitability and brand. While time to value ratios, how long it takes to deliver from an idea to its implementation? When it comes to measuring innovation, West says, innovation should be measured as the percentage of new stuff versus fixes/infrastructure being changed when a release is made.
Attia added that such effective KPIs will indicate if outputs are being achieved faster or cheaper, ultimately decreasing overall costs and improving profits.
Hutchins said there isn’t a single list of magical KPIs, and points to a set of questions (suggested by Gartner firm) designed to help create digital KPIs:
What is being measured?
Where are we today?
What is our target goal?
What is the desired business outcome or benefit?
What is our balance point?
Craig Besnoy, program director and digital strategy consultant at Mindtree, has a straightforward way he suggests companies look to track their success. That’s by the internal popularity of the program. “Companies should track their success based on the number (of) departments in the organization that are requesting access to the digital transformation program,” he said. “Once the organization experiences the increased efficiencies and revenue that digital transformation can bring, managing the requests will be the biggest challenge.”
Lean project management is rooted in cost-saving manufacturing methodologies. The ultimate goal of lean methodology is to reduce waste. Companies in all industries have adopted lean principles into their own processes, but lean is most suited toward physical manufacturing, engineering and related industries.
Regardless of your company’s size or the activities of your organization, lean project management principles can be extraordinarily helpful in optimizing your everyday operations.
Below are the five core principles that guide lean thinking for project managers.
Identify Value
Defining the value of a given product is crucial. Before beginning any manufacturing project, or any project for that matter, the amount of value a finished product will generate must be assessed accurately. How much customers expect from a given product must also be ironed out.
Value questions that lean teams will ask:
What do customers want?
How will they benefit from our product?
How much are they willing to pay for the benefits of our product?
Lean teams can, for example, estimate how much customers are willing to pay based on related data points, then set costs low enough to reach an agreeable price. The goal is to eliminate all waste in every process. Any area where value is not added—or worse, cost is exceeding value—must be addressed early on using lean management principles.
Map the Value Stream
The value is the end goal of the project. Once you’ve established value as a definite endpoint, you can begin mapping the way to get there (or value stream). Every single process and every single step involved in getting to the end product is part of the value stream. From gathering the materials needed for production to coordinating efforts with PR, every related process is represented in the value stream.
Kanban is one of the most popular ways to map value streams. Tasks are broken down and are posted in a “just-in-time” fashion. That way, each task is taken one at a time and only done when it is absolutely necessary to complete.
Using Kanban flowcharts and other diagrams, managers can set up visual aids for value streams, mapping every single step onto a single page. By mapping the flow of activities, lean project managers can easily identify waste and inefficiencies with the process, allowing them to ameliorate these issues swiftly.
Create Flow
By mapping the value stream, project managers can spot waste. Any tasks that are done too early, too late or too often creates waste. By analyzing the map and removing waste, lean project managers can create the optimal flow of activities.
Lean project managers check for possible bottlenecks and delays. If there are any inefficiencies present, tasks may have to be reordered. Sometimes, project managers may even decide to append value-adding tasks to improve processes.
Ideally, every step should flow into the other, beginning at the factory (or organization) and arriving smoothly as an end product to the customer.
Employ a Pull Approach
Many organizations use a push approach, stockpiling supplies in anticipation of demand. Lean organizations, however, employ a pull approach, wherein production increases as demand increases. Customers can “pull” directly from the manufacturer, getting what they need in an on-demand fashion.
The pull approach requires extremely accurate market research and exceptionally efficient dissemination of information within the organization. Also, all processes must be streamlined; otherwise, it will take too long to ramp up production to meet demand.
Seek Perfection
At its core, lean management is about continuous improvement. Lean management requires a thoughtful approach to every action. Optimization must be part of the corporate culture itself. Every member of the organization must be working toward removing waste, adding value and delivering quality. There is always room for improvement in lean organizations.
Conclusion
Lean organizations are removing waste. Lean project managers ensure that activities within the organization flow properly, without interruption, delays or bottlenecks.
Identifying value means finding out what your product will do and how much customers will pay for it. Value streams are then mapped, following every step in production. Project managers ensure that tasks flow and processes run smoothly. Market data is collected during development and these data points drive production. The most important principle that guides lean thinking is to seek perfection. The lean management philosophy demands a dedication to continual improvement.
Software has no intrinsic value until it’s working in production and supporting a customer’s business initiatives. With that in mind, it’s imperative that organizations focus on how they reduce the time to value, not just time to deploy. And that’s achieved through people.
A common misconception is that technology underpins a software delivery value stream. This is only half true. Tools add immense value and help people to be more productive—whether through advanced functionality (such as the ability to visualize and manage workflow) or by automating repetitive activities (such as test cases and releasing code). All of this boosts throughput. But it’s actually the human touch that drives a product.
It’s all about how practitioners work together to understand and address a discerning customer’s needs with software. To that end, organizations must ask themselves, “How do we optimize practitioner collaboration?”
It’s All in the Artifacts
Collaboration optimization lies in how organizations handle product-critical information—artifacts such as features, epics, stories and defects—that are created for the very purpose of sharing with collaborators.
Therefore, the follow-up question that organizations should ask is, “What system do we have in place to ensure these artifacts are flowing in real-time, so the information is always up to date, ensuring that all work is always accurate and adding value?”
Fortune 100 companies have already asked these questions, making a number of significant discoveries:
The software value stream is actually a social network of collaborators who are connected by artifacts—hence, “value stream network.”
This network consists of two different, but equally important, phases: “plan and design” and “build and deploy.”
The network by default is not explicitly connected because the tools collaborators use do not naturally integrate with each other and automatically flow artifacts between them.
This disconnect forces collaborators to waste precious time chasing up information via manual means such as email, status meetings, spreadsheets, tool-switching and duplicate entry.
This manual communication is non-value work that costs organizations up to $10 million in productivity overhead (based on a typical 1,500-person IT department).
Such archaic knowledge-sharing practices significantly compromises the fidelity of data as it goes from one practitioner to the next.
The “plan and design” phase—the part of the software delivery process that determines what product/feature is to be built/fixed—is detached from the “build and deploy” phase.
Through these discoveries, the last one in particular, organizations came to an important realization: They have no real way of knowing if they’re building the right product because there are six degrees of separation between the people who design the product, and those who build and deploy it.
The result? Disgruntled customers and a big loss of competitive advantage. To address this, they’ve created a new infrastructure that provides a framework to connect and support both phases.
By fusing the value of people and technology into a defined value stream network that is visible and traceable, they have a seamless flow of work that they can see, measure and control. They’re now in a position to identify where value is created and lost, enabling them to make informed business decisions to make better products.
The Software Value Stream Network
The enterprise software delivery process has long been misunderstood as a traditional manufacturing system that is linear and sequential—thanks in part to the industry’s failed adoption of the Waterfall model. The negative influence and impact of that experiment still lingers today.
The process is linear in the sense that there are two clear bookends: A product/feature/fix is requested (A) and then that product/feature/fix is made (B). There are also established phases across the production line: conception, initiation, analysis, design, construction, testing, deployment and maintenance. But that’s where any real similarities end.
In reality, the process is more of a latent network of critical interactions between collaborators. These bilateral working relationships exist at key stages of the software delivery process, such as developer and tester, developer and operations, etc.
When you actually lift up the floorboards of the process and peak inside, it looks more like a social network connected by the flow of artifacts, which looks something like this:
Most of these relationships have developed over time as organizations have introduced a higher degree of specialty in key stages across the value stream. This evolution has been vital in helping organizations to:
More deeply understand customer requests/issues
Clearly articulate the requirements/defects
Enhance product management/optimization
Acutely break down requirements into epics and stories
Write more accurate code faster
Automate and accelerate higher levels of testing
Continuously deploy
Introduce tighter feedback loops
Continuously improve and innovate
While all these new roles, disciplines, purpose-built tools, processes and methodologies have helped different practitioners to perform better, it’s also introduced huge technical complexities. How do you flow those all-important artifacts if the tools are disconnected by design, and when collaborators are working in silos, trapped in “administrivia” hell? It’s tantamount to having a sports car with no gas and a confused driver. Or an airplane flight network with no air traffic control. It’s a banana republic.
Building the Right Product via Value Stream Integration
Agile and DevOps illustrate just how vital integration and automation is to this flow of work. Agile brought in prioritization, feedback loops and sprints to build the most important features as fast and accurately as possible.
DevOps, meanwhile, has accelerated speed of deployment. In that sense, the build and deploy phase is optimized. Automation has work flowing seamlessly between Dev and Ops teams, and eliminated/mitigated cross-team issues, such as miscommunication regarding what products need to be deployed, and when.
But what’s the point of faster delivery if it’s not what the customer wants?
We need to consider how wrong features are developed. If you turn to look upstream, you realize that the teams planning and designing products are affected by the same misalignment that used to plague DevOps teams.
The disconnections between collaborators and their tools in the creative software design process mean that often what’s implemented isn’t right or is delivered too late. In either case, it doesn’t add value.
But that can be radically changed through sophisticated toolchain automation, which shares artifact data across tools and automates the hand-offs between owners in the “plan and design” stage.
From the sales to product to PMO to business analysts, by bringing these customer-centric, product-focused teams together, you dramatically improve the product articulation process and the speed at which its performed.
You build features closer to the customer’s needs. You contain that precious value. And then through automation you can flow that value downstream to developers to create that value. It is as big a revelation as DevOps.
How is this all done? Enter value stream integration. This process is much more than just connecting two tools, say Jira and HPE QC. It’s about connecting all tools, practitioners, disciplines and processes to define and create a free-flowing network that is automated and scalable. Think of it as the plumbing in a house. If even one pipe isn’t connected, there’s no flow of work (value).
Value stream integration connects the pipes to:
Automate Information Flow Across Value Stream: It enables the frictionless flow of artifacts, as well as information from events across the value stream. This removes non-value-added work and bottlenecks; increases velocity and capacity; enables automated traceability; and dramatically improves employee satisfaction.
Enable Value Stream Visibility: When managers want to see metrics and dashboards to understand project status, to optimize the process or to ensure compliance, it has been nearly impossible to get a real-time, holistic view across non-integrated tools. Value stream integration unlocks lifecycle data from these application tool silos by automatically compiling lifecycle activity data into a single database. This data can be used to create consolidated, full-lifecycle reports and dashboards, as well as for traceability reporting.
Create a Modular, Agile Toolchain: Value stream integration enables organizations to use the products that best support each discipline while getting the benefits of a single, integrated toolchain. This drives more value from each tool and allows organizations to easily add, replace and upgrade them, creating a proactive environment for innovation. It creates that value stream network.
Finally … Manageability
With this network, organizations can finally see, manage and optimize one of the most important processes in their business: the engine that drives their prosperity in a digital-centric world. You cannot underestimate how important it is to have this network, this complete system. This is the state where innovation thrives, and where continuous improvement can be executed. And, of course, where you gain the essential visibility to be confident you’re always building the right product.
No one denies that JIRA has taken over the developer space. The verdict is nearly universal: Most developers want to use JIRA only. That’s fine, but without understanding the role it plays within the context of your entire value stream network, your organization has likely not crafted the most efficient value stream.
JIRA plays a critical role within any complex value stream—and using JIRA to its fullest along with the other critical aspects of your value stream is the key to delivering software faster and achieving the software results you sought.
But developers encompass only one role that is required to build complex software. And, as fabulous as JIRA is for developers, it is often not the tool of choice for the many other roles involved in building software, i.e., product managers, product analysts and test engineers. Even salespeople are part of your value stream.
Fundamentally, we need to recognize and understand that delivering software requires careful orchestration between a large network of people with different roles who have the need for different tools. But we need the overarching value stream of information passing within that network to work together seamlessly. The information flowing through the network needs to be connected and traceable in an automated way. This really boils down to identifying the “centers of criticality” with the associated artifacts and architecting your value stream network accordingly.
JIRA, Centers of Criticality and the Value Stream
What are “centers of criticality” in software delivery value streams? They are the artifacts and associated tools that represent the primary connectors of business value to the manifestation of that business value. To be more specific, when the business asks for some new functionality, it is represented as one or more artifacts, typically either requirements, features or epics (sometimes all three). Those artifacts act as the “glue” for all of the other key information from which to “hang off.” You want the tests that run, the change sets and code reviews, the defects, the builds … all of that information should be tied to the requirements/features/epics. And those “glue” artifacts also need to be tied to the originating business initiative or program. Thus, tools that operate on those types of artifacts really are your “centers of criticality.”
And that is where JIRA comes into play quite significantly. It acts as the touchpoint—the center of criticality—between what the developer should build, tied to the actual artifacts that constitute the end working software, as well as tied to the originating business needs.
Consider the familiar example of when a salesperson hears from customers that they really want a new feature. As a result, she wants to tie this net new ask to the opportunity—and be able to track via Salesforce whether the customers are going to get that new feature request anytime soon.
And here’s a good value stream for it: The request is entered into Salesforce and naturally tied to the customer account. That request should flow to the product management tool in use, which in some cases might be JIRA, but often, especially at large organizations, is a more purpose-built product management, portfolio management or requirements management tool. At that point, the request that originated in Salesforce is reviewed and determined to be three different features. Once the company decides it wants to build them, those features then flow into JIRA as epics. From the epic in JIRA, the development team begins to create the stories and tasks necessary to build the feature, then connects the change sets and tests and defects to those stories and tasks.
As a result, without any manual effort, the team has created a dynamic network of artifacts that provide full traceability from the very beginning of a customer requesting something through to its final delivery seamlessly. JIRA plays that critical touchpoint role of “what” should be built to the actual bits and bytes of the resulting software.
Now consider a different example. You’ve released the next version of your application and all is going smoothly. Support uses ServiceNow, or one of the many IT service management (ITSM) tools that exist. Your support team is the originator of much of the follow-on work that happens regarding applications. Tickets originate with ITSM tools—but they, too, need to be connected to the resulting defect that requires attention. So, you need a seamless flow of tickets and incidents from the ITSM tool to the resulting defects that must reside in JIRA. And those defects need to be associated to the stories and epics that were affected. They also reside in JIRA.
Both examples exemplify the importance of “centers of criticality,” with JIRA being one of those centers of criticality. In a complex value stream network, JIRA plays that crucial role of being the touchpoint between bits and bytes and business value. But, without flowing information to and from JIRA from the other tools in the value stream, you are left with a broken value stream without real, accurate, automated knowledge of what and why you are building something. Because knowing if you’ve delivered business value comes from understanding the provenance of what you are building. It might be how many customers (internal or external) had asked for the 20 features that were delivered last release. Or how many customers were not going to renew your software if those features weren’t there. Or even how many new opportunities you can follow up on to say that what they’ve asked for is now in your product.
Conclusion
Building complex software that truly meets business needs necessitates that there will be an equally complex underlying value stream network that will only be efficient and effective if it is architected from the ground up with careful consideration of the critical artifacts and tools that need to be connected. JIRA is very clearly one of those tools. So, embrace JIRA being the heartbeat for developers—and know that by crafting your end-to-end value stream network with JIRA as one of the “centers of criticality” you can have an efficient, fully connected and fully traceable value stream. Happy connecting!
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:
Enterprise collaboration
Business agility
Short time-to-value
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:
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.
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.
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.
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.
