I recently visited an agile team at a Fortune 100 company that has 34,000 employees—8,000 of them in IT—and over $200 billion in total assets. Much to the delight of customers and business people, this team and its scrum master, following agile and DevOps practices, tackled a heavy process and cut eight weeks out of its software delivery flow time.
This is the story of how they did it.
The problem—and the ultimatum
The core of the agile team at this company—let's call it XMP—consists of 10 dedicated people, including the developers, the testers, and the scrum master. The extended team includes a product analyst, UX designer, app dev lead, and application owner who are shared with other teams.
Like other software delivery organizations, the team at XMP was frustrated with the time wasted with handoffs, status meetings, and the need to chase down missing information. The overhead of keeping colleagues in sync, instead of doing value-adding work that the business needed, irritated the staff and negatively impacted morale.
The flow of information among different teams' tools and work management systems was slow, which made it hard to collaborate and created overhead and errors during handoffs.
There were other problems as well. Conflicting priorities and dependencies stalled execution and responsiveness to customers. And dependencies on specialists were a huge challenge due to difficult, and sometimes non-existent, communication across siloed teams. Furthermore, a heavy process that had once served a purpose was still in place, even though the teams had evolved far beyond it.
From the business' perspective, the pain points included inaccurate estimates, unhappy customers, late deliveries, and unpredictable delivery dates. This last factor was such a problem that leadership brought the agile team in specifically to correct the delivery time frame on a project that had, at that point, taken three times longer than the initial estimate.
The business leaders' call to action: You must deliver more frequently and more predictably, so the business can respond to and improve customer relationships. Given that this line of business supported payment processing, protecting customers' financial well-being was essential.
And so an end-to-end agile transformation pilot took shape, in two phases.
Phase 1: Discovery transparency
Phase 1 consisted of moving visibility of the discovery phase, where the team defines and prioritizes features and minimum marketable products, into the team space. Previously, the agile team had no visibility into the discovery phase of a work request. The team sat in three-to-four-hour-long discovery meetings for eight weeks in an attempt to get everyone aligned on planning, capacity, and scheduling.
The upstream program management work, which had been completed prior to design and development, had been implemented using tools that didn't integrate with the agile team's tools, making the workflow through the front-end process invisible. It's hard to manage work when all you can see are meetings on calendars.
The team at XMP should have been able to wrap up discovery in a few hours, but it took eight weeks. Why? Because people lost context while switching between tasks, and then other work became a higher priority. That's not surprising, because the priorities of other teams aren't the same as your team's.
Teams rarely work in isolation. If you need a skill from a different team, then handoffs between the two teams need to occur. The developer wonders, "Are there unknown vulnerabilities in this code?" while waiting on feedback from a security expert. But the security expert is busy discovering how someone hacked into a now insecure database. And this question awaits input from the database architect: "Is the data in the test environment wrong? Can you please check it out?"
Unfortunately, the database architect is now busy helping the security expert. When you are the only one on the team with a special skill, you can become a bottleneck as you get pulled in many conflicting directions. Expert skills in high demand are often unavailable when you need them.
Experts also get double-booked and don't always show up for meetings. Then you end up with conversations like this:
"Did we invite Sarah to the meeting?"
"Well, we did, but she got pulled into that security issue and couldn't make it, so we invited Chris. But Chris doesn't know this part of the application well."
When the right people aren't at the meeting, decisions get delayed. This is the problem with achieving high resource utilization—important work takes longer and flow time increases because people just aren't available.
The delay at XMP was mainly due to a legacy process that required each request to be estimated at four different stages of the process:
- At the initial funding of the project
- During traditional project management tool setup
- At the weekly estimation of stories and tech cards prior to design
- After any change to the original requirement via a change request (and there usually are changes) that required approval from the project business lead
To bring visibility to this problem, the team captured critical flow-time measures. The average lead time to develop and deliver a change was 80 to 90 days, of which 40 to 50 days was wait time. Now the team could show the time waste in the workflow.
How can you say you're doing anything with agile/lean/DevOps processes when you still have a 90-day booking of resources?
The team worked in two-week iterations with due dates announced for the completed work. Additionally, larger chunks of work were managed—some as long as nine to twelve months.
Furthermore, the old process included:
- A four-week scope lock
- A two-week code freeze
- A one-week release freeze
Any request outside of the process (considered an exception) required CIO approval. Meanwhile, completed development work sat waiting for ages because people avoided the painful exception process. Humans are like that.
It got to the point where long-term development efforts were canceled. That's when leadership decided to bring forward Phase 2 of the end-to-end agile transformation pilot. Managers willingly took risks in this business line and had CIO support. A decision to "rip off the Band-Aid" launched the team into Phase 2.
Phase 2: Shift left—integrate discovery into team workflow
Phase 2 consisted of integrating discovery with the design, development, integration, and test workflow. The XMP agile team brought together the IT team, product owner, UX designer, application owner, application development leader, and product analyst to work through the details.
In the 90-minute meeting that ensued, people voiced their opinions, spoke their minds, and said what was and was not working with the workflow process.
For things that weren't working, the team decided how to make those work. They agreed to the following:
- Move from two-week to weekly iterations to be more responsive to customers.
- Estimate just once (at the feature level) to trade for more time to execute on business value–adding work.
- Have the team, rather than the requestor, establish a delivery date range. No one knows better than the people who actually do the work how long things will take.
- Use best-of-breed tools to further support DevOps practices. Teams want to work with the best tool for their job and have the necessary information flow smoothly among those affected.
Team XMP members asked themselves, "What capability are we trying to deliver?" Given that the team had been brought in by the business specifically to deliver faster and more predictably, the direction was clear: Improve the flow of business value across the value stream.
Two things that speed up flow are making work visible and reducing batch size. The team brought together the right brains to create visual maps of all the activities required to deliver the desired functionality and implement smaller batch sizes—hence the move from two-week to one-week iterations.
The previous process, of eight weeks of double-booked meetings with unavailable specialists, was replaced with one working session dedicated to the discussion and visualization of the discovery part of the value stream.
This new approach of visualizing work with dedicated time for specialists allowed the team to complete discovery work in hours instead of weeks. And by curtailing estimates, the team became more predictable. If the delivery estimate was six weeks (say from April 1), the team communicated a time frame of "some time during the week of May 15" to the business owner.
Then, during the week of May 15, the team submitted a request-for-change for a delivery date that week. This meant no more exact due dates were required up front. Statistician John Tukey's famous quote, "Be approximately right rather than exactly wrong," is an astute reminder for all agile teams.
Because the business thinks in terms of value streams, management looks at all of the things that come up—blockers, accounting issues, and the demand capacity process. (The last is not very sexy to talk about, but the reality is that it gets in the way of making flow happen, so you can't ignore it.)
End game: Faster, more predictable results
Because of its constructive and unified relationship with the business team, the agile team at XMP gained the trust of business stakeholders, who recognized the opportunity to get things done quicker by shifting left. The discovery work done upstream to the left of design and development, which was previously invisible, was now clearly visible on whiteboards in the team area.
By shifting left, farther up the value stream, the team could see what was heading its way sooner, provide faster feedback, and be more predictable.
Improving workflow by making work visible, and clearly prioritizing working sessions with necessary specialists, allowed the XMP team to ax an outdated, burdensome process.
As a result, the team could define a roadmap for success and adapt along the way to put itself in a leading and honorable position: Delivering business value faster by managing and measuring the flow of work through the value stream.
Best of all, after this win, the scrum master was promoted.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
