Agile + DevOps – you’re doing it wrong!

“My whole team is working 24x7. I don’t have time to think about transformation”. That’s what a VP in the IT organization of a global company was saying last week when we met to talk about ways for them to accelerate their “idea-to-release” cycle.

That’s a very common symptom of a problem most large enterprise organizations are facing as the pressure increases to build and release applications faster. There is no single path towards a better state. Each organization is different, each team is different, therefore, what works for one company won’t necessarily work for another. No cookie-cutter approach here, unfortunately. Recommendation? Start with “why”.

Enlightenment

A while ago I wrote a piece about “Continuous Delivery: you’re doing it wrong”, which focused on sharing how most organizations I work with are overlooking a key pillar to any DevOps transformation.

Now I’d like to add Agile to the mix, as this year (finally) companies realized that for them to truly achieve business agility, there has to be a unification of Agile and DevOps transformation initiatives. It’s really about changing the way the company thinks about their business. First step is to accept that IT is not just a supporting function and a cost center. IT is truly part of the company’s business model. That line you could draw between “the business” and “IT”? Gone. Easy to say it, extremely hard to get there in an enterprise environment.

What’s wrong then?

If the goal is to turn a business idea or hypothesis to quality application code as fast as possible, there’s something fundamentally problematic with the deliverables that Agile teams create.

Figure 1: Overhead in Traditional Agile

Pink boxes in Figure 1 represent just some of the artifacts created by each capability (Product management/Business Analysis, Development and Testing) in the application lifecycle. You have to consider that these are work products that should live throughout the life of the application.

Which means, when there are changes made to the application, these have to be maintained to ensure any impact due to the application changes are reflected in the work products.

Over time, as the application continuously grows, the amount of work products also increases. Ideally, these work products would always be up-to-date and aligned with the current state of the application at a given point in time. In practice, does it really happen? Be honest. Really.

Outdated work products generate lack of trust that requirements accurately reflect the current state of the application or that test cases properly catch any application regressions or even achieve appropriate requirements coverage. The fall back plan? Tribal knowledge. Team members become “irreplaceable” and puts the organization on a bind when they leave. Oh and they do leave. A lot. Lots of great people retiring and Millennials rotating jobs every 2 years.

What then? Well, this is what you hear:

“My whole team is working 24x7. I don’t have time to think about transformation.”

Sound familiar? Rhetorical question, of course.

Strategies that worked for some enterprise organizations

For that VP, one of the quickest ways for him to start seeing results and get his team to work normal hours is to stop creating those work products manually. And more importantly, stop maintaining those manually.

Figure 2: Real value expected for successful Agile and DevOps adoption

For an Agile and DevOps context, the value Product Management / Business Analysis delivers is to ensure the team, usually composed of professionals focusing on Development and Testing, reaches a common understanding of what needs to be developed, tested and released.

Historically this goal has been attempted by documenting requirements in a textual way – thus the pink box on Figure 2. The focus today on some mature organizations is to use visual aids for conveying information. For instance: during backlog grooming / refinement sessions, where whiteboarding is the most common practice, diagrams such as flowcharts seem to be the universal preference.

This approach makes it easy for the team to understand requirements in the same way from the get-go, which reduces the excessive amount of back-and-forth later in the lifecycle for requirements clarification. There’s lots of technologies out there that will take a flowchart and automatically generate text-based requirements, manual and automated tests that are, today, generated manually by traditional Agile teams.

Similarly, Development’s value is the application code. The faster the team can get to the code, the faster the team will be able to release it to users. But they can only do that if there is a mechanism to provide immediate feedback on whether that application code is working and doing what it was supposed to do. Those are two very distinct things.

Notice that finding defects is not the goal anymore, but the byproduct of the mechanism that provides that immediate feedback to developers on the quality of their code according to the 4 pillars of continuous testing.

Takeaways

It’s clear most companies unifying their Agile and DevOps adoption initiatives are focusing on changing the way their teams are measured. It’s no longer about ensuring a certain type of intermediary work product was created. It’s about:

1. Ensuring the team has reached a clear, common understanding around the requirements for the upcoming sprint
2. Removing barriers to building the application code as fast as possible
3. Enabling developers to know immediately if their application code is good so they can move on to the next task in the sprint backlog

Companies that have reached that state have done so by figuring out ways to change KPIs, success criteria and performance goals that focus on “checking boxes” for the organization. For the most part, they still create those intermediary work products in pink. Some of those are required for regulatory compliance and audit purposes. But they have used technology to automatically create and maintain them while the team focuses on the real value the team members in each capability are expected to deliver on the path to Agile and DevOps adoption.