Keeping Everybody Happy with Separate Agile Systems

This content is syndicated from LeadingAgile by Richard Hensley. To view the original post in full, click here.

Agile Systems

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


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.


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?

The post Keeping Everybody Happy with Separate Agile Systems appeared first on LeadingAgile.

Leave a Reply

What is 7 + 2 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”