DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • DevOps Chats
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Communities
    • AWS Community Hub
    • CloudBees
    • IT as Code
    • Rocket on DevOps.com
    • Traceable on DevOps.com
    • Quali on DevOps.com
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Digital Anarchist
  • Media Kit
  • About
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DevSecOps
  • Leadership Suite
  • Practices
  • ROELBOB
  • Low-Code/No-Code
  • IT as Code
  • More Topics
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps

Home » Blogs » DevOps Practice » Accommodating Different Processes in Enterprise Software Delivery

Accommodating Different Processes in Enterprise Software Delivery

By: contributor on December 20, 2017 2 Comments

When an organization takes on a new initiative, it typically develops a procedure to optimize execution and limit blowback from the transition. Whether it’s the introduction of new processes, personnel, structures or technologies, there are a number of established ways—often gleaned from experience—to support the individual, the team and the wider organization.

Recent Posts By contributor
  • How to Ensure DevOps Success in a Distributed Network Environment
  • Dissecting the Role of QA Engineers and Developers in Functional Testing
  • DevOps Primer: Using Vagrant with AWS
More from contributor
Related Posts
  • Accommodating Different Processes in Enterprise Software Delivery
  • Reinvent Testing to Galvanize Digital Transformation
  • Survey Shows Increased Focus on Modernizing IT, Retiring Apps
    Related Categories
  • Blogs
  • DevOps Practice
    Related Topics
  • development
  • modular value stream
  • software delivery
Show more
Show less

That said, while this procedure may work for one department or team in a certain discipline—say, when marketing invests in a new marketing automation tool—what if the initiative impacts multiple teams, processes, structures and technologies, as it does with enterprise software delivery? A standardized procedure won’t work; there are just too many variables to consider.

DevOps/Cloud-Native Live! Boston

And as organizations continue to provide digital services and products for their discerning customers, the number of variables will only increase as enterprises look to ramp up their software delivery to gain a competitive edge in a digital world. How do you manage all this change?

Moreover, what if this change disrupts some of your best teams, many of whom who are fiercely protective of their own unique processes? Much time and thought has been committed to hone a process that is right for them. Who are you to tell them to pull up the floorboards and start again? Sure, the wider organization may want everyone operating from within one end-to-end system, but that’s just not how software delivery works. Nor, for that matter, is it how practitioners think.

You Can’t Please Everyone — or Can You?

Very rarely do practitioners look beyond their core function and specialism, unless it truly impacts their job. For instance, developers want clear requirements to write accurate code that is tested, validated and out the door. They have to write and maintain reams of code, meaning they have little time to think about the rest of the value stream. Typically, if you’re not a business analyst, tester or in ops, then you’re unlikely to be on their radar. They certainly won’t welcome any interruption or change to the way they operate from someone “outside” their world.

This dilemma is exactly why organizations need to think long and hard about how they deal with these differences within software delivery value stream. Not only can practitioners be hostile and resistant to change, but it’s extremely complicated to deconstruct or adjust these processes. They’re highly detailed in practice (although rarely documented due to the frequency with which they’re modified!), covering:

  • Work items to utilize/prioritize
  • How backlog items vs. issues are represented on their backlogs
  • How items flow through day-to-day processes
  • Whether they use Scrum and/or Kanban
  • The required information that developers need to submit to management level
  • The person responsible for submitting certain elements of the management report

When Standardization Isn’t Enough — How to Accommodate the Cowboys

While standardization is possible (and preferred) across organizations, e.g., ITSM for managing multiple systems for multiple functions from one centralized point of control, unifying teams across the software value stream isn’t so simple. There always will be one or two rogue teams that will reject any new process because they know better and only want to do things their tried-and-tested way. We call these teams “cowboy teams.”

Cowboy teams, while problematic, are a force for good as they can be leaders in experimentation and innovation: Consider Alan Turing and his “Enigma” team. Nor are these teams stubborn sticks in the mud. Often it just boils down to the fact that introducing a new process comes with a lot of baggage that people are naturally going to want to avoid, including:

  • Financial cost (new tools, staff and accompanying training)
  • Time cost (training etc.)
  • Reduced productivity during implementation period
  • No guarantee of success
  • Potential of negative impact on function
  • Detrimental influence on employee satisfaction
  • Unforeseen complications and conflicts such as mismatch with tools used by the team

Last but not least, haphazardly introducing a new process can undermine your software delivery value stream. We know that large-scale software development and delivery requires all teams, tools and disciplines within the value stream to be connected for end-to-end visibility, traceability and governance over the whole process.

And in an ideal world, the process would be underpinned by a single cohesive system. But in reality, this is not the case. Teams work in silos because their purpose-built tools aren’t connected to other stages in the value stream since these tools are unable to automatically flow information between systems. Not only does this state foster siloed thinking, but there always will be one or more teams that will resist any wholesale change to their way of working, even if they’re told it will help the organization meet its business objectives.

Fortunately, there’s a way to unify and connect your value stream while simultaneously accommodating these cowboy teams, and that’s a modular tool chain.

Modularity — The Backbone of Autonomous Teams Functioning Within the Bigger Picture

The software delivery process isn’t a conventional manufacturing process. It’s more like a network of thousands of people with different functions, tools and processes that work on different components of the same project at the same time. And these components simply must communicate in real time to share collaborative data. Supporting such a system is complex, because all the best-of-breed tools for planning, building and delivering software do not naturally integrate—there’s no interconnection, the lifeblood of any network.

However, you can connect these tools via model-based integration through a modular value stream; i.e., not point-to-point integration, but an adaptable, integrated network that communicates through a model in the center of this complex universe. Not only does this account for all different tools, teams, disciplines and processes, but this paradigm enables organizations to plug new elements in and out without disrupting the all-important flow of information across the value stream.

This means any information that is shared throughout the value stream is done so in a normalized format—a common language, if you will—that allows teams to operate in their preferred tool and methodology. For example, if your management wants to know the number of tickets/defects submitted per program during each release, they don’t want to know there were 10 “high priority” ones from one team and 15 “important” from the other team. If “high” and “important” mean the same thing, priorities should be normalized and reported back to the management in a standardized fashion.

Thanks to the automated flow of information into a language everyone understands, the whole value stream, even the cowboys, are on the same page without the need for laborious time-consuming manual forms of communication, such as email threads, status meetings, phone calls, spreadsheets and duplicate data entry. Not only does this improve the working conditions for practitioners, enhancing employee engagement, but it also can save up to $10 million a year in productivity-related savings.

So, the choices for organizations are either to:

  1. Force all teams to use the same system, creating a litany of individual, team and organizational problems due to disruption, or
  2. Use a modular value stream method that maps each team to the standardized model, while at the same time allowing teams to continue working in their preferred system using their carefully devised processes.

Change is constant, inevitable and vital for progression and innovation. At the same time, change can be a threat to those important parts of your business model that are working and delivering business value. With value stream integration, you can have the best of both worlds: Your pioneering cowboys can continue to work in the ways that make them happy and productive, while the rest of the stream can continue to collaborate, evolve and adjust to the fast-paced digital landscape.

About the Author / Mara Puisite

Mara Puisite is a Pre-Sales Engineer at Tasktop, bringing with her years of industry and technical experience. Prior to her current role, Mara worked as a Product Manager running Tasktop’s connector program and managing the development and maintenance of 50+ integration systems. Today, she helps companies solve various bottlenecks in their software development and delivery process through the power of value stream integration. Connect with her on LinkedIn.

Filed Under: Blogs, DevOps Practice Tagged With: development, modular value stream, software delivery

Sponsored Content
Featured eBook
The Automated Enterprise

The Automated Enterprise

“The Automated Enterprise” e-book shows the important role IT automation plays in business today. Optimize resources and speed development with Red Hat® management solutions, powered by Red Hat Ansible® Automation. IT automation helps your business better serve your customers, so you can be successful as you: Optimize resources by automating ... Read More
« Real World Development
Are Your Web Applications Prepared for the Holidays? »

TechStrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

The Complete Guide to Open Source Licenses 2022
Monday, May 23, 2022 - 3:00 pm EDT
Building a Successful Open Source Program Office
Tuesday, May 24, 2022 - 11:00 am EDT
LIVE WORKSHOP - Fast, Reliable and Secure Access to Private Web Apps
Tuesday, May 24, 2022 - 3:00 pm EDT

Latest from DevOps.com

GitLab Gets an Overhaul
May 23, 2022 | George V. Hulme
DevOps and Hybrid Cloud: Life in the Fast Lane?
May 23, 2022 | Benjamin Brial
DevSecOps Deluge: Choosing the Right Tools
May 20, 2022 | Gary Robinson
Managing Hardcoded Secrets to Shrink Your Attack Surface 
May 20, 2022 | John Morton
DevOps Institute Releases Upskilling IT 2022 Report 
May 18, 2022 | Natan Solomon

Get The Top Stories of the Week

  • View DevOps.com Privacy Policy
  • This field is for validation purposes and should be left unchanged.

Download Free eBook

The State of Open Source Vulnerabilities 2020
The State of Open Source Vulnerabilities 2020

Most Read on DevOps.com

DevOps Institute Releases Upskilling IT 2022 Report 
May 18, 2022 | Natan Solomon
Apple Allows 50% Fee Rise | @ElonMusk Fans: 70% Fake | Micro...
May 17, 2022 | Richi Jennings
Making DevOps Smoother
May 17, 2022 | Gaurav Belani
Creating Automated GitHub Bots in Go
May 18, 2022 | Sebastian Spaink
Is Your Future in SaaS? Yes, Except …
May 18, 2022 | Don Macvittie

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2022 ·Techstrong Group, Inc.All rights reserved.