devopsy.kinsta.cloud

Tag: value stream management

Break Open the Black Box of Software Development

If you asked an airline executive what their biggest expense was just a few decades ago, they would’ve easily answered, “Jet fuel.” These days, you’d be hard-pressed to find an executive in any industry that wouldn’t answer with, “Software.” But here’s the difference: With jet fuel, that executive would have told you that they can fly x number of seat miles per gallon/liter of fuel (or pounds of fuel, if we’re being technical). With software development, the expense is becoming more material–and far more variable–but the return on that investment is rarely clear. Over the past decade or more, software development has readily assumed its position as the fastest-growing (and often largest) expense line item in virtually every industry. All companies are adding software experiences to or around their products, and they need the people and tools to build, support and continuously optimize those experiences. And that costs money–a lot of money.

The problem is that the language, the metrics and the world in which software development exists do not translate into operational or financial terms that business leaders can readily understand.

“We invested X million dollars into software development last year,” a CFO might say. “And what do we have to show for it?”

Meanwhile, a technology leader might respond with, “We’re doing X deploys a day!” or, “We wrote X thousand lines of code!”

They might as well be speaking different languages because, in practical terms, they are.

And the problem is, that you can’t manage what you can’t measure. To continue our airline theme, software development continues to be a ‘black box’—this hidden-in-plain-sight source of information—that financial executives can’t seem to peek into.

Why the Black Box?

It’s not likely that technology leaders are being purposefully elusive toward business leaders–it’s more likely that they simply are not aligned on what, fundamentally, they need to do to speak the same language.

The question at hand is, actually, “Are these investments we’re making turning into our desired business outcomes?” But the question technology leaders feel compelled to answer is, “What do your people do all day?”

These are questions that Agile and DevOps don’t solve–translating Agile or DevOps metrics (also known as DORA metrics) into actual, actionable metrics for business leaders to understand. Although these metrics are tremendously useful for teams, using them to steer the business is a mistake.

Misaligned in purpose and using different language, business leaders and technology leaders talk past each other as software development costs continue to rise.

But the cost of software development is too high for business leaders to continue to tolerate this ‘black box’ of ever-rising costs. It’s the fiduciary responsibility of financial leaders to understand the value of software investments and figure out how they are affecting business outcomes–or their jobs could be on the line.

In case this seems like a distant threat, it isn’t: I saw a headline recently about a prominent automobile executive who lost their job because they weren’t able to gain the necessary insight into, and business outcomes out of, their significant software development costs and that was affecting the competitiveness of their entire company.

It’s happening. And it’s on both business and technology leaders to break that black box open and start speaking the same language.

The next question, of course, is, “How?”

How to Bridge the Communication Gap Between Technology and Business Leaders

For far too long, business leaders have made do with the activity metrics provided by technology leaders–they’ve tolerated this lack of visibility and found other ‘strategic’ ways to justify the rising software development costs. Perhaps they’ve been questioning how A leads to B–how an increase in funding for software development might result in greater customer retention or app usage, for example–but they have not had a tangible way to prove to themselves, much less to investors, whether this is actually happening.

In order to understand and quantify software development costs, we have to start demanding more from our technology leaders: Working with them to establish realistic objectives and key results (OKRs), and holding them accountable to business metrics that actually relate to outcomes. That means insisting on business results–and not accepting activity metrics in their stead.

Stable-Fund Products, Not Projects

Here’s a hard pill for finance to swallow: When it comes to delivering software-enabled customer experiences, it’s not about optimizing costs. It’s much more nuanced than X dollars in equals X dollars out. Funding by projects might help make the numbers neat, but it doesn’t reflect the reality of the business.

Project-based funding also tends to keep project leaders in a cost-center mentality: It makes it seem as though all resources are fungible; as if the work and the people performing it are interchangeable.

One of the goals of Agile is to maximize value for the customer. But when we fund by project, we often stop funding a piece of work–declaring it done–before it actually starts generating value. We have this false end date that doesn’t reflect the actual ending of the value that we funded to create.

Instead, finance organizations should move to the stable funding of products: Funding an outcome and giving teams the ability to stop, change or extend their work to achieve the business outcomes of the product.

This is a shift that one prominent UK bank has been going through in recent years–from traditional portfolio management to lean portfolio management, including the shift to stable-funding projects. You can learn more about how NatWest Group (formerly Royal Bank of Scotland) has made this shift in this webinar.

Visualize the Flow of Value with Flow Metrics

Finally, we have to stop treating the collection of technology metrics and business metrics as two separate, unrelated efforts. Agile and DevOps are great at accelerating the throughput of your software development … but vanity metrics around how quickly teams are delivering are not enough to justify the growing and material investment in software development.

Finance leaders have the opportunity to be the Babelfish between technology leaders and business leaders. As mentioned above, one way to encourage clearer communication between teams is to use OKRs to naturally tie software development objectives to tangible business results. The more we practice drawing connections between technology and business metrics–the closer we get to finally breaking open that elusive black box.

A key part of this is communicating operational metrics differently: Developing a core set of metrics for tracking the flow of business value in software delivery, and providing a mechanism that correlates the investment in flow for each product’s value stream with the business results for that value stream.

Visualizing the flow of value in a software development process may not be as easy as watching value flow on a manufacturing floor–but that doesn’t mean it’s impossible. Thanks to the vast number of data and visualization tools at our disposal, it is possible to make software products and their value streams just as visible as production lines.

The Flow Framework, created by Dr. Mik Kersten, addresses the pivotal challenge of breaking open the black box of software development and bridging the gap between business and technology to optimize the flow of business value to customers.

Break Open the Black Box with Value Stream Management

The black box of software development is, at its core, a communication issue. It’s on both business and technology leaders to bridge this communication gap. Business leaders need to demand more from technology leaders and insist on translating activity into business metrics. Technology leaders need to practice tying their efforts to tangible business outcomes to help justify their growing expenses.

Of course, it’s helpful to have tools purpose-built to facilitate this visibility and communication.

November 2, 2022
Building New Value in IT Systems Management

For decades, companies treated the IT system as a cost center not much different from facilities maintenance. The job of IT was to keep the lights on, ensuring that the technology a company used worked and that the costs of keeping it working were kept under control. Those days are well over. Not only is technology an operational necessity, but everyone now recognizes that the way companies strategically use technology—whether they buy it, rent it or build it—has a direct impact on company performance. This goes beyond efficiency. Technology is key for everything from customer acquisition and engagement to competitive differentiation and advantage.

As it turns out, however, not every company has been able to rethink and reconfigure its IT system to meet these new demands. That’s not surprising. Not only does this require a mindset shift from the C-suite on down, but it also requires restructuring the IT function to ensure it supports business objectives in a consistent and measurable way.

While transforming IT from a cost center to a profit center can hardly happen overnight, there are three things that any company can do to turn IT into both a business enabler and a business driver.

1. Establish Full Transparency Over Your IT System

A mission-critical IT system needs to have a thorough understanding of what the organization’s IT landscape looks like. Spending money on duplicate applications and unused licenses is a waste. Unknown SaaS applications pose a persistent security risk. Optimizing spend and improving security are table stakes for business-enabling IT.

The fact that anyone in a company with a credit card can subscribe to a SaaS service is the main challenge. Effectively tracking down all SaaS applications and licenses, along with monitoring SaaS usage, can’t be handled manually. What is needed, as with other tedious tasks, is automation. For example, by integrating a SaaS management platform (SMP) with SSO and expense management solutions, organizations can automate the discovery of SaaS. When the SMP also integrates with the primary SaaS vendors companies rely on (Microsoft, Google, Salesforce, etc.), it allows organizations to keep track of usage.

The goal here isn’t for a centralized IT function to exercise more control over the software used by organizations. Instead, the goal is leveraging automation strategically to produce the kind of data-driven insights that allow organizations to make better, more informed decisions about the technology it uses.

2. Promote Engineering Efficiency

All companies today are software companies. This means that the engineering function needs to be thought of us as part of the overall IT estate. Not only does the IT system need to support engineering as it would any other business function, but the technology created by engineering itself inevitably becomes part of the broader technology landscape managed by IT.

Mission-critical IT supports engineering efficiency in at least two ways. First, IT should provide the tools and capabilities needed to drive engineering efficiency. For a long time, measuring the efficiency of engineering was either not done at all or was based on meaningless vanity metrics such as lines of code. Recently, DORA metrics have emerged as the scientifically validated method, widely trusted by engineering teams themselves, for tracking efficiency. IT needs to enable easy tracking of these metrics.

IT should also facilitate the creation and maintenance of a service catalog for engineering teams. Maintenance of this catalog not only promotes the reuse of services, itself a hallmark of engineering efficiency but also makes it possible to quickly mitigate security issues associated with microservices (Log4j being just one example from the last 12 months).

Beyond efficiency, however, IT can also support in-house software creation by helping engineering teams with value stream management so they can track the business impact of the software they create. While efficiency can have a business impact (realized through time/cost savings), software drives the business forward when it effectively meets customer needs. IT can facilitate these insights by connecting the dots between customer feature requests, product changes and increased adoption (of products and features).

3. Make Enterprise Architecture Strategic

An IT function serving as a mission-critical part of the organization cultivates a comprehensive overview of the software landscape and supports engineering efficiency, as suggested, by viewing the development environment as an integral part of the broader technology estate. However, IT system leaders need to do something more to effectively collaborate with the business leaders and drive the business forward.

Specifically, IT leaders need to provide the business with insight into all the ways technology influences business performance. This means highlighting risks that need to be addressed, uncovering opportunities that should be pursued, and suggesting options for future planning. Thoughtful and strategic enterprise architecture management here is the key.

A strategic approach to enterprise architecture management means focusing less on governance (who gets to use what) and more on reducing complexity to promote agility and quick decision-making. The first step in this direction is the adoption of a common language that aligns the business and IT. Business capabilities and the creation of business capabilities maps for different departments serve this purpose.

To make decisions about technology, business leaders need to know what they are working with. Reliable and current data is essential. For this reason, your enterprise architecture management needs to prioritize ongoing data collection and the maintenance of data quality.

Finally, to make objectives and options transparent, IT needs to be capable of strategically displaying all enterprise architecture data in a way that can be easily understood and acted on.

Where Do You Start?

Taming an unruly SaaS landscape, making it possible to build better software and guiding technology strategy are all easier said than done.

The good news is, ongoing innovation has created solutions that are easier to use, effectively leverage automation and integrate with all relevant systems. In other words, the tools are there. All that’s needed is the commitment to transforming the IT system and developing it into the critical business function it can and should be.

October 28, 2022
Allstacks Adds Alert Capability to VSM Platform

Allstacks has added an alert capability to its software-as-a-service (SaaS) value stream management platform that automatically notifies DevOps teams when software project goals and deadlines are likely to be missed.

The core Allstacks platform employs machine learning algorithms and artificial intelligence (AI) models to keep track of pull requests, commits and card changes via a set of dashboards that are designed to be accessible to anyone in an organization.

The Allstacks Alerts capability makes it possible to notify those stakeholders via email or Slack any time a specific indicator, such as a pull request, has been open for four days, which would suggest risks of delays have increased. Support for Microsoft Teams will be added early next year.

Adam Dahlgren, senior vice president of product for Allstacks, said the goal is to leverage the advanced analytics built into the platform to surface thoughtful observability insights versus simply firing off a series of generic alerts that lack any context.

Value stream management (VSM) platforms such as Allstacks automatically take technical metrics collected via DevOps tools and correlate them to key performance indicators (KPIs) defined by business leaders. The concept of value stream management traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to a highly-automated process using DevOps best practices, an appreciation for the value of monitoring the impact of missed software development deadlines on the business has grown as organizations realize how dependent they are on software.

In fact, many organizations are discovering there is a clear disconnect between their business goals and software development processes. Business leaders are especially anxious to understand how a software development project delay might impact future revenue projections at a time when economic conditions are the most uncertain they’ve been in recent memory.

VSM platforms also make it possible to track KPIs spanning multiple software development projects; the hope is that doing so will make it easier to see where resources should be reassigned as various bottlenecks are encountered. In the long term, Allstacks is also working toward adding scenario planning tools to make it easier for IT and business leaders to model “what-if” scenarios, added Dahlgren.

It’s not clear how much organizations are willing to invest in VSM platforms, but the need for them is becoming more acute. The challenge many organizations still face is making sure they have the tools in place to collect the appropriate technical metrics. A SaaS-based platform should make it simpler to achieve that goal and to apply algorithms to what can quickly become a large corpus of data.

Of course, it’s still early days as far as the adoption of VSM platforms are concerned. But there’s no doubt the divide between application development teams and the rest of the business is continuing to narrow. Less clear is to what degree that increased visibility will lead to a higher degree of empathy between dev teams and the business.

October 10, 2022
Plutora Releases Test Environment QuickStart Bundle – Techstrong TV

Bob talks about Plutora’s new “Test Environment QuickStart Bundle”. It provides an easy, immediate fix to the Achilles’ heel of software development: environments that cause delays, produce bugs, and waste time and effort. The video is below followed by a transcript of the conversation.

Alan Shimel: Hey, everyone. Welcome to another Tech Strong TV segment. I’m really happy to be joined today – I don’t know if he’s actually been on Tech Strong TV with us, but I’ve spoken to him many times; it’s my friend Bob Davis from Plutora.

Hey, Bob, how are you?

Bob Davis: I am great, Alan. It’s so good to be here. I haven’t had the pleasure of being on the Tech Strong TV spotlight and it’s great to be here.

Shimel: Fantastic to have you. So, Bob, our audience has been fed a steady diet of Plutora for years already, right? So most of them know Plutora, one of the leaders in the value stream management space, a DevOps pioneer leader. But I don’t know if they really know you. I’d like to introduce them to Bob Davis.

So why don’t we start there? Give them a little bit of your history, Bob.

Davis: Sure thing. Alan, I’ve got a few years under my belt, and I started in the semiconductor business back at Intel as a chip designer. And I ultimately said, “Gee, you know, I think I understand why I want to build things bigger, better, faster and cheaper, but I don’t understand the business.” So I went and got an MBA and I moved into more of a product marketing orientation, and from there became a serial entrepreneur.

This is, Plutora is my tenth startup. I never joined another large company after I joined Intel, but I found my way into some through acquisitions and so forth: Novell, CA. Always on the software side, always on the, you know, typically the infrastructure, you know, a lot of enterprise IT, networking, compression, security, a lot of that, and ultimately back up in recovery and continuous data protection and those kinds of things, which ultimately led me to really understanding, wanting to understand more about the developer side.

And so about five or six years ago I found my way into Plutora and I became chief marketing officer and away I went. Along the way I became a pilot, I play golf, and love the water. So I’ve got a lot of things. And six grandchildren, so good stuff.

Shimel: Six children. God bless you, man. Whoo. You know, I’ll tell you off camera; I don’t even want to get into it now.

But anyway, that’s great, man. It’s great to have you here. And it’s interesting, ’cause you know what, a lot of people will hear “Bob Davis, CMO Plutora” and say, “Ah, he’s a marketing guy.” Well, yeah, but you’re a marketing guy who started off designing chips at Intel when a lot of people watching this were playing computer games, not even computer games, Show & Tells or whatever the heck they were. Right?

Davis: Yeah. Well, I’ve always been on the product side and I’ve always been more on the “What’s the next idea?” In fact, the best example of that was right around 2000 – you know, we started Kaseya.

Shimel: Oh, I remember that.

Davis: So I was the original founder of Kaseya and started that in my kitchen and it’s …

Shimel: Really?

Davis: Yeah. To being what it is today. And there wasn’t even a managed service provider market at the time.

Shimel: No, I remember that early on. Because I had started a company called StillSecure and in 2005 we pivoted into MSSP. ‘Cause I just thought MSSP was the way to go. It was too hard for too many companies; they needed an MSSP. Actually Kaseya bought friends of mine, Carl and Billy Austin, they’re serial entrepreneurs as well. They were acquired by Kaseya. And then of course Kaseya was acquired, what was it, a year or two ago maybe?

Davis: Yeah, Inside Venture Partners bought Kaseya in 2013, which is when I left actually.

Shimel: Right. Oh, okay.

Davis: That’s when the new management came in. And we sold the company and kind of went off on our own journeys. I went to a company called Atlantis, which we were doing hyper-converged storage, and then ultimately Dalibor Siroky, CEO of Plutora, found me and brought me over to Plutora in 2017.

Shimel: Very cool. So, Bob, we were talking off camera a bit. We’re at an interesting sort of boundary layer here again. I think many of us are let’s call it cautiously optimistic that we are going to emerge from our kind of COVID cocoons and venture out again en masse.

Davis: Yes.

Shimel: Many of us are already.

Davis: Yes.

Shimel: The interesting thing is the world we left two years ago is a different place today than it was two years ago. We’ve learned a lot of things, we’ve experienced a lot of things. Digital transformation – no pun intended – has transformed many a business – many a business model. For us in the tech industry, for our audience, you know, the way they shop for products, try products, use products, measure flow in terms of value stream and stuff like that, it’s really changed in two years. They’re different. You can’t put your foot in the same water twice, right? And so companies like Plutora – someone once said that, I’m pretty sure.

But companies like Plutora, they’ve had a change. You’ve had to adapt. And you guys have. You have that sort of a whole new program you’re coming out in market with. Let’s talk about it.

Davis: You bet. You know, in the beginning, right in the beginning of the pandemic, early pandemic, early 2020 we saw as the world was trying to find its axis again we saw an incredible increase in people wanting to learn. So they spent the first part of that 2020 just in this learning mode. And value stream management was one of the things that people were really focused on learning. And the notion of being able to say “Wow, if I could really see a pipeline, a value stream from the beginning to the end and understand if I’m getting better.” And that was really the question that the CIOs were asking, “I’ve spent millions of dollars on these tools. Am I getting better?”

The point I’m making is that everybody was trying to understand how they could tell if they were getting better. And all these flow things became almost an MBA project or a PhD-type project to really understand all that’s possible. And that was awesome and we got a lot of interesting traction from that.

What we found, however, is that that transformation is a daunting transformation and the world changed around everybody. We went from distributed teams to distributed teammates. So now that autonomous team was distributed in and of itself, and the communication and collaboration became very difficult to achieve. So processes, organizations were changing. So many things changing all at once that people were really slowly doing like they’d be happy to go to an event, sit on a virtual show. What do I need to understand to get better?

That’s not what’s happening today. Some of it, sure. Some of it still happens. But people are moving to more execution. They want to get value. They want to start seeing the value of that journey and they want to see the value in real-time. They don’t want to see it a year from now; they want to see it right now, this year. So we have seen our customers struggle with saying “How can I get started in value stream management? I may not even want to go all the way to the end of the value stream management journey, depending upon my specific tastes.”

So we’ve developed an entire program around doing just that. How can we get people into a value stream process mentality, into a value stream platform, and do so quickly so that they can value right away. And so we have this program called the Quick Start Program and we released in January the first of several Quick Start products. This one is on environment management, which is a core component of value stream platform that Plutora sells. And in so doing we’re able to provide people solutions to a very complex test environment problem in three or four weeks, whereas today it can take 30 days just to configure and make an environment available on some of the prospects that we’re talking to.

So in the time it takes to get an existing manually configured test environment ready for a test event you can have a full test environment management program and go from manual management of test environments to an automated process very quickly. Now I see value. Now I can see value in terms of the efficiency of utilization of expense and test environments. I can see better quality. I can see saving tons of money.

We find that people with average levels of releases, well UMA did a study and they came out and said the average number of releases in an enterprise environment was 76 a year. That was in a survey. They did a survey and they came back and said that was the average. There was certainly a distribution, but that was the average. And if you’re manually managing your test environments you’re losing money. They determined based on all the issues of managing these things almost $1.5 million a year you’re wasting.

And so we can save you that with a product like this. So imagine I’ve got a bottleneck in my DevOps tool chain, the Achilles’ heel of my tool chain is waiting for test environments as I shift left and try to test earlier. I solved that problem, I removed the wait states there, I become more efficient, I save money, and I can do that in about three to four weeks worth of setup. And now I’m rolling. Wow, I’m getting value. Now I go to the next problem and so forth. And I get quick starts, I can come into the platform pretty soon. I’ve got a full value stream management platform down the road. I’ve gotten value every step of the way and I never had to really think about the prospect of doing the whole thing. It’s like one step at a time; every journey is one step. So it’s like let’s give people the ability to get value in that same way, one step at a time.

And that’s really, it’s been met with tremendous success already. We’ve seen a lot of responses, a lot of people wanting more information, and our SDR team is very busy fielding calls on it. So it’s been a real successful launch so far.

Shimel: That’s great. You know, Bob, I think part of the reason for its success is there’s two kind of trends you’re riding there. First of all it’s this, I call it “deliver delight,” but I mean that’s just two words, right? It goes to when I was an entrepreneur founder of companies we were hiring enterprise salespeople who sold to the C-levels and all that stuff. In today’s world we hire DevRel evangelists, and the idea is get the software into the hands of the people who are going to use it, deliver delight, and if it works they’ll tell their bosses and so forth to buy it. So it’s a different sales model. But it’s become dominant, especially in DevOps cloud native, you know, the kind of markets we play in. So this really is kind of playing into that.

Davis: Totally.

Shimel: It’s delivering delight. Because synonymous for delivering delight is delivering value.

Davis: Yes. Well, that’s the point, right? Now it’s the whole point of value stream management in the first place. You know, it’s interesting; it’s really an agile approach to delivering the value stream management solution. There’s a parallel there. You know, saying “I’m going to buy a value stream management platform and implement it” is a little like deciding I’m going to build a waterfall process. ‘Cause it’s everything at once, this is what I want to do.

Shimel: No, it’s like trying to eat an elephant.

Davis: Exactly.

Shimel: You’ve got to eat it one bite at a time. [Laughs] That’s the only way you can eat it.

Davis: Right. Well, you’re crossing – you know, by the very definition value stream management embraces both, you know, everything from the ops person on the far right to the strategic planning office on the far left, and so you’ve got lots of people, you’ve got lots of moving parts. It’s hard. We actually have found hard when we market the product we get the interest from the pain point, I’m having trouble. In this case I’m having trouble managing my environment. If you’re selling the entire platform that environ manager, in order to take advantage of that feature, has to sell the platform to the planning person, to the ops person, ’cause they’re all going to get affected.

There’s value there, but they’re like, “Show me.” Now we’re giving them a tool they can do that. It’s an on ramp into the platform, a smaller bite of the apple, as you said, an agile approach to delivering value stream management and value at the pain point level. And so we’re doing everything around it to make it super-clear if you have this pain, this is what it looks like in our product when you solve it, and you can get there by the end of the month. Does that sound reasonable? And it’s way cheaper.

And so that’s the other thing, these platforms can be expensive. But what if I can buy something that’s in my sign-off authority, so it’s more approachable to me? The whole notion of S-a-a-S is all about product life growth and let me get something in my hands for free and try it out and then I can grow from there. That’s the beauty of what so many people have enjoyed with S-a-a-S-style software products.

Value stream management is hard in that sense, ’cause it’s complicated. There’s integrations into the tool chain, there’s process changes as people evolve from more legacy processing to DevOps tool chains and DevSecOps tool chains and so forth. There’s that. There’s organizational change, budget-holder changes, people moving from silos and project-oriented things to product-oriented things. So we’ve run into prospects that get so frustrated, they want the solution but there’s a lot going on in the organization. We’re answering that question.

You can each have had a success, show the value, and go from there. It’s a great on-ramp. It’s a freemium approach almost in a complicated environment and its value stream management, and we think it’s really going to be awesome when people can have multiple. We’ll do probably deployment, we’ll have a quick start for master deployment plans. You know, Jeff was on in November talking to you about our progressive release management and some of the new stuff that we did with the Insights dashboard. That’s another screaming for of Quick Start, “Hey, wouldn’t it be cool if you could get this up and running very quickly?”

So all of those things is where we’re headed. We started with environment management and it was made available on the 18th of January and it’s already in the market, so we’re excited about it.

Shimel: So no pun intended, but where can we get a quick start on this Quick Start? [Laughs] Where can we go, Bob?

Davis: Well, we have, there are online demos. You know, there are all kinds of spots on our website. We have a spot where you can say “Talk to me and you can sign up for that and have it by the end of the month.”

Shimel: So just go to Plutra.com and check out the stuff for Quick Starts.

Davis: Yep. There’s a banner right on the top of the home page that will take you right to the information on it.

Shimel: Love it. Good stuff.

Davis: Yep. It’s all right there.

Shimel: Hey, Bob, we’re about of time. I want to thank you for coming on and telling us about the Plutora Quick Start program. You know, the first one, as you mentioned, came out the 18th. Any timeframe on subsequent quick starts?

Davis: We’re going to bring out the next one in the beginning of the next quarter, so right around April.

Shimel: Excellent, man.

Davis: So you heard it here first, Alan.

Shimel: Well, that’s why we’re here. Thank you for letting us know. We’ll be watching. Good luck with this one. Maybe we’ll see you show up on one of the Plutora webinar workshops that you guys do with us so often. Love to have that.

Davis: We’re going to do that.

Shimel: Cool stuff. All right. Bob Davis, CMO Plutora here on Tech Strong TV. We’re going to take a break right now. We’ll be right back with our next guest.

August 26, 2022
Building a Platform for DevOps Evolution, Part One

Winston Churchill once said, “To improve is to change; to be perfect is to change often.” While nearly everyone will confess that change is necessary to grow and succeed, we all know it’s much harder, especially when human behavior is involved. Professionals who work in DevOps environments know this all too well.

Adoption of DevOps principles and behaviors should be viewed as a gradual process. Many organizations make false starts or attempt to implement a change only to see it fail. Sometimes this is due to changes in leadership, market conditions or technology, but then organizations catch their second wind, build momentum and reaccelerate their evolution.

DevOps can Change

With a shared vision, mutual goals and hard work, DevOps can change to keep up with user demands. DevOps professionals will always confront two potent barriers: Cultural and process debt and technical debt.

Cultural and process debt occurs when leaders refuse to delegate authority, distrust their teams and lack a value stream approach to work. Technical debt develops when monolithic systems are tightly coupled, automation is delayed for testing, environments and version control and there is no access to cloud technologies.

Although these obstacles are challenging and complicated, many organizations still meet them head-on. Evolution depends on a habit of making improvements every day through the use of an improvement kata such as PDCA (plan, do, check, act), which involves long-term strategies and objectives and continual experiments between the current and next target states.

An evolving DevOps approach maintains moving pieces across a large organization of hundreds, thousands or even tens of thousands of people who cannot change overnight. Many lack the will and the cognitive capacity to embrace and enact change.

This environment requires release managers to delegate power and transition from centralized commander to an enabler, understanding different value streams have varied skills and requirements. Mark Peters, a cybersecurity specialist and DevOps leader with years of military operations experience, outlined his top release management traits in the context of DevOps ways of working as automated processes, distributed accountability and accelerated delivery.

PDCA Improvement Kata

DevOps proposes that we adopt an improvement kata in our day-to-day efforts as an improvement habit, consisting of four steps that are repeated:

1. Set the long-term vision
2. Understand the current state
3. Identify the next target state
4. PDCA between the states

Experimentation is at the heart of the PDCA cycle. The most practical experiments are empirical, data-driven and date-specific. Using a value stream management platform to give data to support the experiments leads to data-driven discussions on real and measurable success.

In the next part of this series, we will begin exploring different experiments DevOps organizations can conduct to drive change and improve their release management procedures.

August 16, 2022
Why You Should Rip Up Your Org Chart and Reorganize Around Value Streams
To compete in the digital economy, teams must optimize both efficiency and effectiveness–it’s a tough ask. The traditional dominator hierarchy is a problem because organizations that use command and control create silos and handoffs that stifle innovation at the team level. Coordinated autonomy releases the creative spirit of individuals–but how can leaders assure alignment with their vision?

One way to eliminate the delays and waste associated with silos and foster autonomy is to arrange around value streams. A value stream is anything that has a customer or anything that delivers a product or a service. All value streams begin with ideas and end when a change is delivered. Or, even better, when our cherished customers realize the intended value outcome. The original intent of Agile was to provide “value” to our customers faster … but we hardly ever talk about what this value is or measure its existence.

Traditional organizational charts arrange resources according to expertise. This means that work is handed off to different teams as it progresses through the value stream. Value streams exist whether or not people call them that and whether or not they actively manage them. Every time a hand-off occurs, it creates an opportunity for delays or errors. It also means it’s hard for people to understand the end-to-end system. Instead, they do as they are told to optimize their piece of the puzzle without really understanding how their actions impact work that’s upstream or downstream.

More progressive ways of working, like Agile and DevOps, do promote cross-functional, autonomous teams, but they typically leave a big gap between planning and delivery and are not always smart at connecting feedback from customer experience back into planning. Value stream orientation promotes team diversity by recognizing the individual background (cross-functionally) into the value delivered to the customer.

Organizing around value streams is the foundation for nurturing the value stream-centric ways of thinking and working that drive both efficiency and effectiveness. Then, customer experience is improved and higher levels of organizational performance are achieved. This is because:
- Putting customer experience front and center brings higher retention and referral rates
- Elevating the concept of flow (see below) gives teams permission to prioritize removing waste
- Balancing innovation with improvements reduces technical debt, toil and unplanned work so employee experience is better, too
- Connecting planning to delivery to feedback in a continuous loop aligns teams and helps with decision-making
Flow is about how fast ideas can move through a value stream and be made available to the people they’re designed for. It’s about outputs and efficiency. Customer experience tells teams about the outcomes of their work and their effectiveness. Used together, these measures ensure the teams are doing the right things right and moving in the right direction.

In this model, leaders share their authority and empower their teams. They support teams’ self-discovery of improvements and make sure those local learnings go global. They help their teams understand how much time they spend innovating compared to reacting or improving. Then the leaders can help their teams reduce distracting and stressful unplanned work and instead invest in increasing capacity for innovation in the future.

Follow these steps to become a value stream-centric organization:
1. Identify your value streams
2. Identify who is involved in each step of your value stream
3. Make your value stream visible by visually collaborating with your value stream team
4. Use tooling to gather value stream data and generate insights for your team
5. Meet regularly to inspect and adapt your value stream
All organizations are composed of value streams, regardless of whether they have been made visible, and most large organizations have complex networks of interconnecting value streams. These dependencies are not easily decoupled. They’re not easily visible, either. But once you’ve mapped them, you can start seeing where they connect and manage the dependencies. Ultimately the goal is to break these dependencies since they cause delays and risk, but it’s hard to do that when they can’t be seen.

Connecting the organizational vision with the value streams becomes much easier with this model. Organizational structures are flattened. Leaders understand which value streams they are accountable for and how they work. The time between having an idea and getting feedback on how it’s received is shorter and amplified. They can see the work being done, measure what impact it’s having and make better decisions about what to innovate or invest in next.
August 11, 2022
Techstrong TV: Value Stream Management & Value Creation

Lance Knight, ConnectALL President and COO, joins us directly from the Agile 2022 conference. Lance discusses the concepts of value stream management and value creation. The video and a transcript of the conversation are below.

<span data-mce-type="bookmark" style="display: inline-block; width: 0px; overflow: hidden; line-height: 0;" class="mce_SELRES_start"></span>

Mitch Ashley: I have the pleasure of being joined by Lance Knight. Lance is COO and president of ConnectALL. Lance, good to be talking to you.

Lance Knight: It’s great to talk to everybody here again. It’s great to meet you as well.

Ashley: Nice to meet you. I know you’ve had a lot of conversations with Allen and great opportunity for me to have a conversation with you, too. For folks that might not know you or have seen you before, tell us about yourself and of course ConnectALL. Tell us a little bit about that.

Knight: Well, you know, I hardly ever done that before, told anybody about myself. But anyway, I’m Lance Knight. I’m president and CEO of ConnectALL. And you know, we’ve been around ConnectALL for a while. We’ve been spearheading in maybe in the forefront of this value stream management market and we’re excited to be part of this fun ride that’s value stream management. It’s been an interesting ride for me for years. I’ve been in this space since even before it was value stream management for years now. Just excited to see it grow and excited to be a part of___.com and we recently got nominated. It’s part of the 12 for value stream management solutions. So appreciate that. Yeah.

                                 As for myself, more about myself, you know, I’ve got a wife, a kid. I’ve got three kids. I’m just kidding now. But lots of cool things happening in our industry now.

Ashley: It’s fascinating I think one of the things that is fascinating about value stream management is it’s emerging but it’s been around for a long time. It’s not like it’s new. It’s in the manufacturing and you go back to the goal and all. You know, a lot of other things and Toyota. So it isn’t a new concept, but it is as we apply it to software. What do you think it’s now is the time for value stream management? I’m really curious. Obviously you made a big decision of you’re CEO of this company and that’s what you’re focused on. Why is now the time you’re going to be able to make this happen?

Knight: First, you know, you’re so right and I’ve said this quite a bit, is, you know, I started my career in manufacturing, dong value stream management work, understanding leans, systems thinking, all of those things to improve how manufacturing happened. And what I think is now as you take a look at what happened with Agile, what’s going on with DevOps, and the way that people are developing software, they’re thinking how do I make this even better. And I have a whole bunch of opinions why now. One of those is maybe a little controversial, is the goals, aims, and means, and the great vision of what an Agile transformation was supposed to do with my organization was never truly achieved.

Ashley: You mean it got overhyped and oversold?

Knight: Overhyped, oversold. It only really talked about how developers to work better. It never, you know what I mean?

Ashley: Oh, I totally know what you mean.

Knight: My organization has spent millions of dollars on these coaches and transformational people, and now you want me to do that with DevOps too and build a community and feel good about it, and sing Kum-Ba-Ya.

Ashley: [crosstalk] solve that for us, didn’t- Agile solved that for us too before that and you know, this succession.

Knight: Yeah, right.

Ashley: It’s an evolution, right.

Knight: And I see a little of that bleeding into value stream management, but I think why V.S.M right now, because it makes you look at your end to end flow. It makes you understand how you’re deciding what to do. Makes you look at how co goes through things. It’s a little more logical, not that those other ones aren’t. But it’s more specific. It’s got an age old set of things. And business people, the ones that make decisions on things can wrap their head around it. All right, so someone puts a request in here, it goes here. It goes through our agile processes. What do mean? I can finally get these reports to tell me how efficient my teams are? I think that’s what’s driving a lot of it. And ConnectALL we call it see, measure, automate. I can see my value stream now. I can measure and I can automate.



                                 And I think that’s just one reason why it’s taking off. And I think there’s some other ones. You know, well, we do agile, DevOps, value stream, what are we doing and how does this relate? And at ConnectALL we say this all the time, so it’s really interesting. Value stream management is a human thing. It’s a human endeavor. We talked earlier it’s been around forever with manufacturing. We didn’t have machines and computers out there measuring our value stream. We went and did that. We improved the flow. We looked at how parts moved around the shop floor. We mapped it. And we had some tools to help us. And a value stream management platform that’s what they’re there to do, help humans be more effective with managing requests to code in production, connecting it and automating the processes within it.

Ashley: yeah, there’s this phrase I heard, I don’t know where from. You know, you want to work on the business not just in the business. In other words, you have to sort of, that’s about continuous improvement, whatever that might be. But you have to understand it first. You have to be able to measure first. Where do we go improve. Another thing I wanted to run by you is I think one of the reasons why value stream management gets a lot of attention is we’ve elevated the value, the strategy behind software and how much that is importance of that to businesses, how much they’re counting on our ability to deliver. But you know, gone are the one year, 90 day whatever projects where you know, we think we’re going to get this spec, but we never do and something else pops out. And now we’re doing lots of little smaller races. How does a business know if I put a quarter in here I’m going to get my quarter’s worth of what I thought I was going to get there and how we can manage that process to help achieve those results? Is that fair do you think?

Knight: That’s fair too. And I think that’s another reason why it’s taking off right now, right. You know, my controversial point, but then there’s this other point of I’m never- I’m an executive. I’m over an organization. I’ve never seen what I’ve had move quick enough, move through. What are the bottom numbers? It’s invisible to me. Right? I have an initiative and I know I need these capabilities. I need this software. I need all these things. And as I’m saying that I’m watching just this initiative that’s an artifact in some system, I don’t know if that’s moving forward. I don’t know if I’m blocked. It’s a black box to me.

                                 And value stream management kind of opens some of that up as you kind of look at flow. And then also like you said earlier, how am I prioritizing that? I’ve got technical done. That’s really important to repair. But how do I prioritize that rather than somebody saying I need to fix this technical debt. Where you could look at it and say, not yet. This is more important than that. This new capability to make me competitive in the market is more important than if I fix that technical debt today. And those decisions aren’t able to be made at the right levels. And it’s also strategy execution where I can go and to sign my outcomes I want and my initiatives. And then have those get executed across all the organizations, because we have all this visibility and track it.

                                 So that’s the see part. And also the measure part where you talk about measuring. I can say, all right, now I’ve improved our processes by 25%. So now I can move quicker. The only thing that I think value stream management we have to be careful of is I don’t- and I’m seeing some of the other analyst firms do this. It’s not DevOps value stream management. It’s value stream management. And DevOps things are a part of that value stream.

Ashley: We have a value stream whether you’re doing DevOps or not, right?

Knight: You know, at ConnectALL my head of products says there’s a value stream now. Every company has it. You may not be aware that that is a value stream, but it is.

Ashley: I think it’s just been more elevated to our consciousness, right, because of DevOps.

Knight: Or more aware of the flow of value through it. Right. So, it’s interesting as it takes off and goes next stages of it and so on. I just want to make sure it stays the highest level thing from an organization perspective and that’s your value stream, right. You have DevOps tools of course and those are part of your value stream also. I just did a speaking slot somewhere about value stream management is not a feature and I went into that whole thing about how value stream management isn’t a feature of a tool or another tool. It4 is what you do and the tools and the platforms how you be more efficient. So it’s a different take I think than a lot of organizations have on it as they try to figure out how to build the best value stream feature in their product.

                                 So ConnectALL we have value stream management platform. It lets you see, measure and automate but if you’re not educated on systems thinking, lean principles, we can do some little stuff, but you would have to map it, use area waste principles, lean principles to think it through, right. I’ve got some mooda, if I used the word right. Maybe we’ll get some text about he said that wrong, which I probably did. Which anyway, that’s waste. And then you could go figure out how to fix that. Why am I having these things?

                                 So yeah, I mean I think it’s going to take off pretty well in organizations need to do this now because software is no longer that thing that that guy in the corner called Lance programs so that you’re more efficient in some of the manufacturing stuff you’re doing.

Ashley: Reminds me of, well, Jim and I first worked together in security. Security we evolving from sort of the people nobody knew that did this thing behind the scenes and couldn’t talk to them because they didn’t know what it was about, to more everyday people, system administrators, network administrators. And so you had to really think about the barrier to entry, right. Do you have to be a lean expert to do value stream management? Or can you step your way into it so there’s the whole idea for barrier to entry for your products? And how do you make that lower to get people started? And I know you had I think an announcement recently for ConnectALL. Can you tell us about that?

Knight: Yeah. So first, so you don’t need to be a lean expert to do it. Just have to maybe read a little white paper on it. And understand just the basics of it and it’ll help you through. So what we have done if you’re referencing to the fact that, and one of the reasons why we wanted to do this is that ConnectAL is going to offer a free online value stream management visualizer, designer where you can log in, put all your tools on there, draw the boxes of flow, decide what kind of flow loops you want, and just lay out your whole value stream, that’s actually yes, that’s’ what we have. That’s our big announcement coming next week is the free online value stream design. And it’s a nice little drag and drop environment where I can just drag on my tools. It’s going to have all the different tools on there, and then I can draw lines between them. I can set up my swim lanes, my boxes. We can do all kinds of things in order for you to lay out your value stream. You can name the links. You can name it so it’s personalized. You can put notes in there. And then it’ll give you a PDF view of your value stream that you can export, you can go around and share that with your manage- here’s how our workflow works. And it comes from the years that I’ve been doing value stream management workshops on a big whiteboard, but we’re not getting together these days for these big whiteboard sessions. So you know, it’s got these different pallets and you can do all these things so that you can actually get a good vision to see your value stream and how things are flowing. And we’d be happy to help you lay that out if you wanted to get on with a session with one of our session architects to walk you through it. You can save them because maybe multi-session thing. Export them and share them with other people that can load it into the free value stream from their computer. And we’re really excited about it because I think it’ll really help people understand how they can use just this one part of value stream management.

So you know, at ConnectALL we’re all about helping the humans be more effective at this, right. And it’s just a great opportunity for anybody’s interested in getting involved in value stream management to have a place where they can go just lay it out. It’s pretty robust. There’s some cool things. Yesterday I was messing with it. I drew a turkey in it. So, you know, Thanksgiving’s coming. So, we drew this little turkey in there, right. Somebody will probably do a Christmas tree as well. But the cool thing is I know some people will probably be like well, I can do that with this tool and this tool. That’s true you can. However, this one’s also free and we’re going to have all of the images and icons of the tools and the flow icons and all of those things preloaded so you can just drag and drop on there. And you’re off to the races of being able to start to tell the story around how you can improve value stream within your ___.

Ashley: Looking at things systemically, even if you think you know the system, the process really well, at least my going through things like that, you just go, I don’t really know what happens here. I kind of do but I don’t really know. So you can learn that or figure that out or somebody who’s mapping this out. And then to your point is once you’ve got that, now you’ve increased your understanding of what we do or the flow of what we do, where do we work? Right, you’re going to go with the theory of constraints and let’s look for a bottleneck. Let’s look for you know, we need a future over a technical debt is where value is. And you start to connect it into a system of creating software, which is I imagine more of your- the paid version of ConnectALL.

Knight: Well, so paid version will operationalize your connections. We can actually, you’ll see the flow of work and we do the integrations, the connections, the triggering, the capturing. We offer all the tough stuff the V.S.M. platform can do at ConnectALL. And normally for these talks I don’t talk much about our great product which is really, really great. We got a brand new release, 2-11 coming out that has some great- I’m using platitudes by saying great, but it has some really great features coming out in the future.

                                 Usually when I talk I want to help the industry. I want to help the space. And that helps me of course. But here this free tool will get you up and running. You can see, measure, you can do some measurement stuff in there. And actually you can put your measurements in there and actually tell a story to your boss. So I was on a conference recently and someday said, well, to do value stream management you need to you know, go talk to your boss and have him approve the project and build a little community and figure out how you’re going to adopt value stream management principles and do all this stuff. And I started to feel like here we go again with community and adoption and the feel good part of it.

                                 And all of that is really relevant when you think about agile, when you think about DevOps, that is relevant. DevOps is a culture shift. And a culture shift, I’ve spoken on this before, is transforming operations and DevOps to work so well together and when operations is normally commanding control, right, can’t have access to those servers because this reason. I used to be that guy, so I can speak to it with great understanding. And having people change that mindset and culture so they can collaborate better, this is not. This is value stream management. You map the value stream. You look for waste. You point it out. You try to figure out how to remove it. And you work with people to do it, don’t get me wrong. But there’s no sprints. There’s no ceremonies. Once you’ve done it, you look at it, figure out how to improve it. You improve it. You modify your map. And by the way you can save these and come back. And then you look for the next place to improve flow. I’m for the other stuff. I’m just saying this is not. This is value stream management. It’s lean thinking. It’s been around forever. Doesn’t require all this other stuff, go do it.

Ashley: I think from an end user perspective I would think that now having a way of dipping my toe in the water, maybe more than that to really understand what’s going on. And I can decide. Now I can decide to go to the next place, whatever that looks like with ConnectALL.

Knight: Yeah. I go map it out and then I can talk about it.

Ashley: Not making a big bet that this thing is going to do stuff for us, but I just don’t know. Right. You know, you’re going to get value unintended.

Knight: So we’re really excited about it.

Ashley: Well, congratulations. When this airs actually I think it’ll be when this is released. So, how do folks get ahold of this? Is this ConnectAll.com?

Knight: Right, ConnectAll.com you’ll see a link there in the home page to go to designer and it’ll come up. We’re not looking for tons of lead information. We don’t want to know how many people run your company and you know, got control over that. I mean all we want is maybe an email and you’re off to the races and you can save them and do all the stuff. And just use it to take that first step. And we have some partners who are using it to run consulting sessions and different things like that. So, I think it’s something that nobody’s done yet. I think it’ll really help move value stream management forward.

Ashley: Great. Well, congratulations on the launch of this entry point, the value stream designer. And definitely I’m going to check it out. So, appreciate-

Knight: I’d be happy to walk you through it. I’ll send you a quick copy of the turkey we made.

Ashley: I would love to see the turkey. All right, Lance. Lance Knight, CEO and president with ConnectALL. Thanks for joining us today, Lance.

Knight: Thank you.

Ashley: Take care.

[End of Audio]

July 26, 2022
Planview Outlines VSM Strategy After Acquiring Tasktop

Planview this week announced it completed its acquisition of Tasktop, a provider of a value stream management (VSM) platform that enables DevOps teams to align their efforts more closely with strategic business goals.

Louise Allen, chief product officer for Planview, said the goal is to tighten integration between the Tasktop VSM platform and the project management applications that Planview already provides to software development teams and business executives.

It’s still early days as far as adoption of VSM within DevOps workflows is concerned, but as more organizations realize how dependent they are on software, they need to better align application development projects with their strategic business goals, said Allen. VSM platforms make it possible to analyze data collected from various DevOps tools and enable business and IT leaders to, for example, visualize how a delay to one project might impact revenue goals for an upcoming quarter.

Given the current weakness in the overall economy, organizations are looking to more precisely understand the impact software development decisions will have on the business, she added. As part of an effort to address that requirement, Planview will also make it easier for its applications to consume data that was originally created in Tasktop, she explained.

VSM enables more organizations to function like a software company—aligning application updates with revenue goals. As the number of digital business transformation initiatives being launched increases, organizations are finding they need to operate more like a software company that either manufactures something or provides a service.

The concept of value stream management traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to an automated process using DevOps best practices, there is growing appreciation for the value of monitoring things such as the impact of missed software development deadlines on the business.

At its core, a VSM platform will automatically convert metrics collected from a DevOps workflow to track a set of key performance indicators (KPIs) defined by the business. Once those metrics are gathered and KPIs established, organizations are then able to apply advanced analytics to align the resources needed to achieve a strategic goal by, for example, devoting more developers to a specific project. The data collected via a VSM platform can also then be shared with business intelligence (BI) applications that business leaders typically use to manage the business.

It’s not clear just how hard business leaders are looking for deeper insights into how software development initiatives are progressing, but at the very least, DevOps leaders need a simpler way to understand all the dependencies that exist between initiatives. Otherwise, they risk missing deadlines simply because no one realized a delay that occurred in one project had a cascading impact across multiple other initiatives. Regardless of who consumes the data generated by a VSM platform, the need to increase visibility across the software development life cycle had never been greater.

July 8, 2022
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.
June 20, 2022
Digital.ai Extends Scope and Reach of DevOps Platform

Digital.ai today unveiled the Ascension release of its namesake DevOps platform that adds pre-built metrics and best practices dashboards using a Test Lens capability to more easily employ analytics to identify software delivery bottlenecks.

In addition, the company has added autonomous testing tools that automatically generate performance and security tests for mobile applications. These tools can be run by DevOps teams, developers or business users. An enhanced Change Risk Prediction capability enables machine learning algorithms to make more extensive use of historical data.

Finally, Digital.ai has also added integrations with the open source Argo continuous integration/continuous delivery (CI/CD) platform and made available an Agility Sync tool for building custom integration with legacy application environments and opened an online marketplace for integrations.

Jeff Moloughney, chief marketing officer for Digital.ai, said the goal is to extend the reach of the company’s DevOps platform. At its core, the platform has a value stream management (VSM) and version control software originally developed by XebiaLabs and CollabNet VersionOne before the two companies merged to create Digital.ai. The combined company subsequently acquired Numerify, a provider of analytics tools infused with artificial intelligence (AI), Experitest, a set of testing tools, and Arxan, a provider of an application security platform. The company claims that its platforms are used by more than 1,500 organizations.

In general, DevOps is entering a new era as organizations realize how dependent they are on software to drive business processes, noted Moloughney. Historically, the adoption of DevOps practices has been driven from the bottom up within most organizations. Now, business and IT leaders are also looking to drive the adoption of a consistent set of DevOps best practices to gain more visibility into software delivery, he added.

That does not mean, however, that organizations can dictate what tools individual developers can use, so the DevOps platform employed has to be extensible in terms of the available integrations, said Moloughney.

At the same time, Molougney added that more DevOps processes will be automated using machine learning algorithms. Digital.ai is embedding these algorithms within its core platform to both uncover software delivery bottlenecks and automate routine tasks such as testing.

It’s not clear to what degree organizations that have already embraced DevOps might be considering replacing their existing platforms but, regardless of size, most of them are encountering issues. On the plus side, the number of organizations that are adopting DevOps practices more broadly is increasing as more digital business transformation initiatives are launched. As those practices evolve, the expectation is many of those organizations will embrace analytics in the form of VSM to better optimize their efforts.

In the meantime, the rate of DevOps adoption across enterprises will continue to vary widely. Each development team within an organization tends to define a set of DevOps practices based on their own requirements. The challenge, given all the dependencies that exist between those projects, is determining the actual rate of progress the organization is making as each of those isolated initiatives progresses.

April 27, 2022