The 2-Week COBOL Sprint: How Agile Mends Broken Trust
“We had to roll back.”
Are these words coming from your mainframe organization?
It means something went wrong with the software rollout and the business unit it supported. It means wasted time and planning, and it demands hours of re-planning and mustering the company troops for the next software rollout attempt. It means lost opportunities, and possibly a great deal of lost money, for the business.
These ruinous rollbacks mean your software rollouts are sporadic, colossal, dreaded tasks disrupting the workflow in your organization, and your head of IT needs to conduct a serious examination of the department.
It’s time for a real organizational change
We began this series explaining why your organization should implement the 2-week COBOL sprint: to stay competitive. Initially, you must convince business leaders the entire organization, not just IT, needs to change to an Agile culture that supports the 2-week COBOL sprint.
But there exists broken trust between business leaders and IT; fortunately, Agile can mend that. Getting to that point requires a conversation between IT and business leaders about becoming Agile and mending broken trust, ultimately making way for a successful implementation of the 2-week COBOL sprint for competitive releases.
In this post, I’ll cover why it’s important for IT to repair broken trust, internally and with business leaders, by becoming Agile, and in the next post I’ll cover how to conduct a conversation about it between IT and business leaders.
What happened to trust, and how does it affect speed?
During the Great Recession, companies were burdened by financial strain and it became difficult to support IT in their organizations. Many companies responded by cutting back the department, initiating distrust between IT and business leaders. Ironically, to remain competitive the business still required a flood of IT work at a level the department’s downsized staff couldn’t support.
Many businesses responded to the IT production deficiency by incorporating shadow IT groups in business units, inevitably growing them. Regardless of higher costs, business units benefited from control over shadow IT groups they could force to accomplish unit-specific development tasks, regardless of relevancy from a long-term perspective. This exacerbated distrust between IT and business leaders.
Intra-organizational distrust became systemic, spawning conflicts within IT between Development and Operations. The thinning of IT departments by organizations led to development shortcuts, necessary to meet business demands with a short staff, which were passed into Operations as problematic updates—nightmares to support.
Some companies began outsourcing software development and testing to groups that were unknown to many in the organization, inevitably causing more distrust between the business, IT and its new outsourcers.
In many cases, layers of processes have now been added to development due to a lack of trust between a company’s business units. Extra checks are performed by parts of the company that aren’t skilled in doing those checks, and because they don’t trust what is being delivered to them, the extra checks continue. As development processes become bloated with manual checks, this lack of trust diminishes development speed.
How can Agile mend trust between IT and business leaders?
It’s time to work together again.
Agile processes can help rebuild trust by improving communication between business units and IT to create better collaboration and transparency. DevOps can reestablish trust between Development and Operations by including operations people from the beginning development stages of new software, also promoting collaboration and transparency.
Just as software updates flow through many departments, trust also needs to flow through many departments. Agile processes help business units and Development communicate, and DevOps processes help Development and Operations communicate.
Agile processes also build trust by providing frequent (daily, weekly, semi-weekly) communication between all parties involved with IT Development, allowing the business to set priorities for its requirements and giving Operations a voice in how software is deployed and how much operation management is required to keep it running.
But the focus of communication isn’t only on Development; it should encompass all company stakeholders. The business and Operations have new responsibilities that require they take time to think about what each department needs to be successful. Development will build what a business unit defines, and Operations will work with Development to define the best configuration.
Improving trust between teams that aren’t local to one another can be difficult, particularly with teams that are outsourced, but constant Agile-driven communication with remote groups can dramatically improve trust, even if it’s over the phone.
The bottom line is communication and transparency lead to improved trust among all groups in an organization. Starting with the initial process of establishing business requirements, to the last stage of operating the resulting programs, high frequency communication improves the trust and speed of getting new software to production.
2-Week COBOL Sprint Next Steps
In my next post, I explain how to have a conversation about Agile with business leaders, including objections to expect and how you can respond. You can read more about why it’s important for your company to adopt Agile and the 2-week COBOL sprint in “The 2-Week COBOL Sprint” blog series here, or follow the links below:
- “The 2-Week COBOL Sprint: Why Mainframe Shops Need It“
- “The 2-Week COBOL Sprint: Having a Critical Conversation About Agile“
- “The 2-Week COBOL Sprint: How to Build a Scrum Team“
- “The 2-Week COBOL Sprint: Developing a Process of Continuous Builds“
- “The 2-Week COBOL Sprint: Agile Feedback Loops“
- “The 2-Week COBOL Sprint: Deployment Automation“
- “The 2-Week COBOL Sprint: Software Development Bottlenecks“
Latest posts by Glenn Everitt (see all)
- Living in a ‘More Data, More Problems’ World with Unit Tests - September 6, 2017
- No Mock Objects for Your Mainframe? Create COBOL Program Stubs - March 23, 2017
- Why You Need Automated Unit Testing on the Mainframe - January 5, 2017