Keeping Everybody Happy with Separate Agile Systems

Agile systems provide better predictability, progress visibility and collaboration, but many organizations fail to realize the benefits throughout their entire organization.

Why?

They are applying a single process, intended for development teams, across executives, program managers and developers.

To fully realize predictability, progress visibility and collaboration through Agile, you need separate Agile systems to manage responsibilities and accountabilities that are different for each role.

What are the separate Agile systems? 

Un-Separate Agile Systems

Most technical teams that I see running scrum have a pretty good system for delivering technical work. It’s reasonably well documented with respect to governance and policy what you do during a sprint planning, how you commit to the work, how you get the work done, how you do a demo, how you do a retrospective. What I see less often is a product management policy governance and cadence that is both disciplined and systematic.

In most organizations I work with, the product managers and technical teams are locked in conflict. Either the product manager is unhappy because he or she has to decompose work into small enough pieces for the technical team to deliver on it, or the technical team is unhappy because they have to build products against great big specifications, and they’re not delivering exactly what the product manager asked for.

The Conflict of Un-Separate Agile Systems

The conflict comes from organizations using work items that serve two separate sets of responsibilities and accountabilities. User stories are the sole unit of value of delivery, and they’re the sole thing that a product manager has to accept as value. Those same user stories are the unit of work on which you have to understand all of the technical items you have to deliver and the accountability around which you think about quality in the artifacts that you deliver.

This creates a conflict between batching and size. The size at which value starts to matter to the customer could be on the order of weeks’ worth of work. At the technical delivery level, the notion that you would take one batch of work and spend weeks on it before you deliver it to your product manager creates a conflict of wandering. You’ll get off path and won’t deliver the right stuff. A user story or decomposition from a feature to a user story creates a situation in which you’re delivering small units of value. Product managers can see value in the user stories that you’re delivering because they show progress and represent learning against their bigger unit of value, but delivered to an outside customer or consumer, they wouldn’t be valuable.

You break the conflict by creating small units of work for technical delivery that are then composed back into the larger unit of work that can be delivered to the customer. You need separate Agile systems to manage responsibilities and accountabilities that are different for each role.

Responsibilities & Accountabilities of Separate Agile Systems

I find what works best is separate systems for separate goals in the organization. Executives are responsible for allocating budgets and selecting projects that they believe are going to achieve their investment goals. The responsibility here is allocating the investment and selecting the business cases. The accountability is tracking that the business cases are meeting their individual financial goals and tracking that the overall portfolio is meeting the financial goal of the business.

At the program level, the responsibility is taking a business case and turning it into what you need to do in order to meet the goals of that business case, including the financial objectives, customer objectives and functional objectives. The accountability is validating, accepting and taking full accountability that you get what you asked for.

At the delivery level, the responsibility is detailing how you’re going to do something and creating a full understanding of that. The accountability is ensuring the quality and fitness of the artifacts that you produce. The definition of done in all those levels has to directly relate to the accountabilities of those levels.

Language of Separate Agile Systems

When you’re managing a portfolio, you’re in the language of executives, which means you’re talking about visions, goals and investment allocations. You’re selecting opportunities from your portfolio of investments in terms of business cases. That is the language of the executive. I have a vision, I have a goal and I have business cases that allow me to attain that goal.

For example, let’s say you have a four-way split on your investment allocation due to government regulation. Your going to invest 30% of your budget and you expect a 0% return on investment. You also have a 25% investment in keeping the lights on, just maintenance of the product. 55% of your investment is sunk cost. The other 45% has to make up the 40% margin you expect from your investment.

When you think about the program level, you’re thinking about the flow of value. In flowing value, you have units of work that are value oriented, and a container of value. You may call them a feature. So a business case from the portfolio level might be that you want to invest 300 thousand dollars in a new virtual infrastructure. As you flow value, the first bit of value might be that I have to research three different kinds of virtual infrastructure stacks so that I can make a build buy decision.

You may have features called research cloud stack, research open stack and research VMware.  When those are all done, you actually have value that you delivered with those because you have learning, and now you have a third unit of value, which is making a decision. That’s flowing value.

At the delivery level, you’re flowing the technical work, delivery or artifacts. At this level, you talk about user stories and tasks.  I recommend your tasks and user stories start with a vertical slice of the application, or a vertical slice of the knowledge and learning that you want to do, and they flow through the steps so that the other side will have an artifact.

When thinking about how work flows, each level will have a unique and contextual set of steps needed to transform an idea into a deliverable. At the delivery level, you might talk about code, code review, unit test and testing. At the value level, you might talk about functional analysis, technical analysis, build it and accept it. At the very top level, you might talk about ideation, committed and tracking. The flows are different. The languages are different. The purposes are different.

Separate Agile Systems

Portfolio Level Agile Systems

The top level system, the executive system, develops why you’re doing a particular piece of work and that why takes the form of goals and initiatives, portfolio management and investment.

It typically begin with investment themes and allocation. I’d suggest you use something similar to the following: we intend to capture new markets with 10% of our budget, keep the lights on and maintain the project with 60% of our budget and we intend to do less risky but high value projects with 30% of our budget. Those are your overall investment themes. For each theme you define what qualifies as something to be involved in your investment.

Once you understand your investment themes, you should go through a selection process.  What business cases should you select? Once you know why you’re doing something from an economic or benefit point of view, then you should dive into the details of your business case. Ask yourself or team what benefit it has to your customer and company, what it’s going to cost, what the constraints are, and who the stakeholders are.

What you are creating is a cascading set of artifacts and processes that are dependent upon one another. Once you have selected a set of business cases, you need to determine the why, division and goal. Those selected projects move into a program level where you start to manage the overall program that has been selected. That system has a different flow focused on delivering value.

Program Level Agile Systems

Now that you know why you’re doing something, you need to know what it is that you’re building. Not how you’re building it, not the specific technology and artifacts you’re going to deliver, that comes later, but what you’re building and what functionality, user experience and feasibility you need from these features to meet the executive goals. This is the point you begin due diligence to determine if you should buy or build and start advocating and selling the business case.

Now that you have a business case, you need to decompose it into units of work, called features. You need to understand those units of work functionally. This is where you draw pictures on white boards, take pictures of drawings, create a conversation about the units of work and conduct analysis. Once you understand the units of work’s functionality, you begin discussing the technical feasibility and high-level designs of the units of work.

Once you understand the technical feasibility of the units of work and have agreement and shared understanding, then you’re ready to decompose them into user stories that a delivery team, or a technical team, can start to work on.

Delivery Level Agile Systems

This system focuses on the construction of artifacts and the delivery of actual artifacts, as opposed to the program management system, which focuses on the delivery of value. This might be something like detailed technical design, coding, code review and manual testing. Once all of the stories that are related to a particular feature are done, then we have a unit of value in the container of a feature and that feature can be accepted by the product manager, or the product management team, which says, “Yes, this is the value that we accepted.”

Business cases flow down through the systems in the form of responsibility. At the portfolio level, responsibility is allocating investment and selecting projects; at the program level, responsibility is developing what you’re building, how you’re going to build it and dictating artifacts; at the team level, responsibility is delivering quality artifacts; then, at the most outer level, responsibility is tracking the return on investment, value proposition and the business case to make sure the value that you intended for the customer and business are being realized. Those three Agile systems have to be separate.

Summary       

I hope this article has inspired you to reflect on whether your organization has a conflict between the goals of the program managers and developers. If you do have this conflict, I would encourage you to write down how your organization gets from a great big idea to knowing what you’re going to deliver for that idea. Write down the steps that you take, and the policies you have around those. This is the first step to separating these systems and fully realizing predictability, progress visibility and collaboration through Agile.

What ways have you experienced conflict between the goals of executives, program managers and developers?