While companies are starting down the value stream, assessing and mapping their operations and product delivery to find areas of bottleneck and waste, another critical aspect of value stream management is feedback loops.

People discuss applying manufacturing techniques to software creation and delivery, and breaking down their product portfolios into work for the development or operations teams, but feedback isn’t often discussed or incorporated into the stream.

In manufacturing, where the product requirements don’t change that often and the processes and deliverable are well-understood, feedback loops aren’t as important as they are in software development, where requirements change and complex projects are put together by multiple teams, leading to questions and comments along the way, according to Lance Knight, chief operating officer at ConnectALL, a value stream management software provider.

When it comes to software development, he said, there are direct and indirect feedback loops. “All the information coming from the right of software delivery — meaning operations, DevOps, all that stuff — those are direct feedback loops. ‘I found a vulnerability; you need to look at it.’ That’s a direct feedback loop. An indirect feedback loop in my world would be, ‘I don’t know if I like the way that looks.’ Or it’s comments and collaboration. Those are more indirect. And those are different patterns. The direct feedback has patterns; the indirect I would say doesn’t.”

It’s important to put patterns around your feedback loops and into your value stream, Knight said. “For example, send code scan feedback to development. Send build results feedback to development. Those are patterns that start to uncover each other,” he explained. Patterns can be human, or they can be automated, he noted, but human patterns — such as reading through logs to find vulnerabilities, then create an issue and the ticket — slow the process down.

For example, Knight said, “I would submit my code, then I’ve got to log into another tool, and I have to run all my scans. Then the QA team takes it. They run it through their scans, they see a bunch of defects, then they wait a while before they key them back into the other system to communicate about them. In automating the defect reporting, you’re removing that time — which could be days. In one assessment I did, it was actually months. In those two months, you’re still coding against those defects. So if my feedback loops are long, now I’m just coding against defects, which leads to more defects.” Organizations, he emphasized, are using feedback loops to see how they’re moving through the stages, but they also need to think about mapping the loops that have to go back to development.

One of the keys to successful improvement of your development and delivery processes is to amplify feedback, which is done through automation. The effect of feedback amplification is that it helps organizations maintain speed in their delivery process, as well as reducing or eliminating wait times and gaining efficiency. “When I amplify it, I’m going to make it visible,” Knight said. “It’s not visible if somebody’s just sending emails. It’s visible when it’s in my backlog. I have to see it and attend to that new issue that came from my scan. When the system just runs a scan and you hope that somebody checks it, that’s not amplified.”

The direct feedback loops are quantifiable, and the ones that can should be automated, such as results from a failed build, or a failed test, or QA or monitoring tools. Organizations that need to know their end-to-end cycle time, and what is causing any delays in that time, should look at their feedback loops. If, for instance, it’s taking four days from when a vulnerability is uncovered to get it back to software delivery, that’s a bottleneck.

Automation in software delivery processes always seems to be the first step towards implementing artificial intelligence or machine learning in the systems. Those have value, Knight stressed, but there always will be an important human element to the processes.

“I can collect all kinds of big data, but is [AI] going to tell you that you have to combine these two teams because they work better together?” Knight asked. “Will AI be able to look at all your code and use machine learning to send feedback loops? The answer is yes. It could look into all the possible potential things going on, start to look at what can change and the vulnerabilities, and then model something back to you, for a feedback loop. But it can’t look at how you’re doing things.

“Until we get to the day that machines can do all this stuff, which we’re nowhere near, and it can look at everything you’re doing and make rational decisions like you and I do, it’s not going to happen.”

 

Content provided by SD Times and ConnectALL