Well, throwing books away might be extreme, but so is implementing everything a book or an expert says, word for word, especially when the author has no knowledge of your organization.
Agile and DevOps are two of the biggest buzz words in the industry, synonymous with digital transformation. An organization not already practicing Agile and DevOps or not transforming itself to adopt them can be seen as problematic. This frequently leads to an organization-wide transformation program simply as checkbox exercise, implementing processes and tools in a uniform manner rather than leading a digital transformation to fit the needs of each team.
Large scale change initiatives supposedly often fail because human beings are resistant to change. But we humans make changes in our lives daily, so how can we be resistant to change? More likely, the reason is that many of these initiatives fail to address the key concerns of individual employees and teams. Often only the benefits to the organization as a whole are clearly communicated.
A 2016 Coleman Parkes study of 1,770 senior enterprise IT and business executives found that adding DevOps to Agile practices improved new business growth by 63% and DevOps speed to market by 42%. Additionally, more than 80% of enterprises that have embraced digital transformation and adopted Agile and DevOps practices saw an improvement in customer experience. These statistics tell why digital transformation matters to an organization, but not how it matters to individual employees.
The next error that organizations make is to select methodologies that all teams will use, thus assuming that one size fits all. When CA Technologies (now part of Broadcom) embarked on an Agile transformation in our Mainframe Business Unit in 2013, we made this mistake too. We mandated that all teams adopt Scrum with 2 week sprints and later mandated that all Value Streams or Business Units adopt SAFe in order to solve the challenge of scaling Agile. We also had a central quality initiative that mandated all teams to have quality targets that needed to improve every quarter. We did see benefits from this, but we also had a number of issues.
With an aim to improve, we gathered a group representing the organization and held a two-day retrospective. We learned three key things from the mistakes we made in the past:
- Focus on achieving outcomes, not on implementing processes.
- One size does not fit all!
- We need to provide teams with enough time and support to make improvements.
Then we identified three key outcomes we wanted to focus on: delighted customers; happy and engaged teams; and fast, quality delivery.
Then all we needed to determine was a way to help our people understand why these outcomes matter to the organization, employees, and our customers. We also needed to know how to enable our teams to deliver these outcomes without mandating exactly what to do or how to do it, while ensuring they have the support and resources to be successful.
We communicated these plans and listened to feedback. We told our product teams that we expected them to complete at least one story per quarter that would help them improve with respect to the three outcomes stated above, and that they must measure the improvement. Outside of this plan, what teams chose to work on and how was up to them.
We did have one specific requirement for every team: they had to complete a process map (fig 1) to describe the steps and time taken to go from code check-in to being ready to deliver to production/customer. We believe from experience that this is absolutely necessary in order to understand where the bottlenecks are in the continuous integration process prior to working on improvements. It also enables a team to be able to articulate the return on investment from the work they do and in turn will help management to prioritize it against other work in the backlog.
WT: working time/effort ET: elapsed time A: accuracy
One of the biggest complaints we had from engineers about SAFe was the number of meetings they needed to attend that were not relevant to them. To remedy, we reduced required meetings to only two per quarter. The first was a business context meeting to discuss our achievements from the past quarter and goals for the upcoming quarter. The second was a final readout of each team’s objectives aligned to our epics, so that each team can see how their objectives fit the big picture and what other teams are doing. This reduced meeting time per quarter to about two and a half hours.
We also had complaints from some teams that two-week sprints were too short, as writing code in lower level languages like PL/I often takes longer than higher level languages like Java. Thus work from the previous sprint was not completed and was just carried over to the next sprint. We gave teams the flexibility to choose their own sprint length of one, two, or three weeks. One of the key goals of Agile is to get feedback from end users on working software as early and often as possible. Doing so significantly reduces waste and thereby increases productivity, allowing Agile teams to deliver value faster than Waterfall teams. In our case, there was no point in having all of our teams stick to shorter sprints, as many did not have working features to be able to demo and get feedback on.
The feedback from our teams on these changes has been hugely positive and anecdotally we are starting to see increased efficiency and engagement, both internally and with customers. Still, we continue to seek feedback and look for opportunities to improve.
There are many topics related to Agile and DevOps with Mainframe teams that I have not covered in this blog, such as culture, specific challenges of digital transformation faced by Mainframe teams, application architecture, and tools. I will endeavor to address these topics and share the progress shown by the metrics we are collecting in future blogs. If there is anything you would like more details on, please leave a comment or send me an email.
If you would like help with implementing DevOps practices cross-enterprise or with your Mainframe teams please send me an email, firstname.lastname@example.org. We have developed a DevOps assessment and have experts around the world that are ready to help you.