With limited resources, it’s about flow – not competition

Organizations strive to be lean with their development resources, but when stakeholders are competing for those development resources it can be detrimental to the organization. The key is to manage the flow of work.

How do you prioritize projects so that the organization is focused on delivering value vs. competing for resources?

You do it by running a Kanban at the executive level that feeds the team’s backlogs throughout the portfolio down to the nitty-gritty task level.

Competing for Development Resources

I recently worked with a small company that builds mobile applications. The CEO of this company was very cash-flow sensitive and knew he needed to improve his organization’s predictability as well as productivity. As he read and heard about Agile, he was exposed to some of the common metrics that accompany the Agile “sales pitch” and related “high-performing team” concepts about improving efficiency by 500% and increasing team morale, among other benefits. These revelations and a genuine desire to empower his teams with tools to be “high-performing” convinced the CEO to drive his organization toward the use of Agile techniques.

After several leaders in the organization attended CSM and CSPO classes, the team restructured into “cross-functional teams” consisting of Web, iOS, Android and API developers to focus on building an integrated product for their customers (which usually have a Web component and iOS/Android applications). Sounds good, right? He did not have enough QA people to place one on each team, so they formed a separate QA team with a follow-on “hardening Sprint” strategy to test deliverables. Not perfect, but common. The company had ten major clients managed by three sales people. They tried to align one sales person to one development team to minimize churn and focus the teams on building products for a smaller set of clients. At first blush, it’s not a bad first attempt at structuring to foster cross-functional teams focused together on a set of products.

Each team had a backlog attached to it, which ran back to the products and clients that the team supported. The backlog started with high-level Epics defined by the Sales team members with Stories broken down by the team members. The goal of each Sprint was for the team to focus on one “product suite” for a customer (which would deliver the Web, services and mobile applications). Any guess as to how successful the team was with that goal in an environment where one team supported the goals of three different Sales team members? 

The result, within a few Sprints, was a Sprint backlog jammed full of multiple stories from multiple products for multiple customers (lest any of the three Sales reps not see progress on “their sale” for one or more Sprints). Chaos quickly ensued with a development team in constant context-switching mode. Less time was given to Story decomposition to deal with the chaos and “ramped up” cadence. More time was lost to chasing down the details of Stories. It felt busier than ever to the teams, but looked less productive than the old “Waterfall” approach of the past to management and Sales. Everything was a #1 priority, running late, delivering with quality issues. What had Agile done? Obviously this company couldn’t do Agile if they wanted to manage their cash flow or maintain a sustainable pace of growth. That was the thought of management, anyway. It sure didn’t feel like 500%+ increase in productivity – Agile must be a failure.

The team was frustrated. They were doing everything right – writing User Stories, doing Sprint Planning, Daily Standups, Demos and Retros. They were practicing two week Sprints. They felt busy. They saw progress. They tried to estimate better each Sprint and to buffer for the “unexpected” to accommodate changing requirements from customers or from discovery. But they, too, started to wish for the “good old days” of a structured Waterfall plan and date-driven handoffs. The self-organizing teams, lighter burden of documentation, ability to manage work more closely themselves just wasn’t worth the pain of feeling constantly stressed out and disappointed – a far cry from the goal of “high-performing.”

What would you do in this situation?

What I would suggest you start to do in this situation is to create Epics at the Sales level for each Client/Product and run them through a Kanban based on priority of several criteria such as time-to-cash-flow and other strategic measures (such as those that may be used for identifying recurring business, strategic relationships, etc.) – manage the backlog of work to what the company values. I’d even suggest that you start with just one based on Cash Flow. This Sales-level Kanban becomes the feeder queue for the development team’s backlog, limiting work in process, improving prioritization across the entire Sales (revenue-generating) organization and helping to identify the bottlenecks in the ability of the organization to deliver. Conversations about injecting new “Epics” (e.g., a new Product for a new or existing Client) would have to happen up at the Sales team and executive level before it ever affected the delivery teams. Each Sales Rep would have a chance to say, “Look, I’ve got this work in flight or slated for work. If you want to add a new Epic it is going to cause this work to go on hold. Tell me how that is good for the company.” Discussions around Cash Flow, priority and commitment are elevated to the right level of the organization. We’ve put Sales in a position to justify and prioritize every Sale – before it affects our development/delivery team. This will allow the organization to prioritize their limited resources around what is most valuable. The world of managing expectations, contracts and sales would need to evolve around this, but we’ve implemented a mechanism to focus on Cash Flow with a limited capacity. Metrics at this level would allow the organization to make a real case for managing expectations at the current capacity, model revenue/cost options to increase the capacity of the teams and make decisions about the long term.

Now, some of you are about to take me to task about changes you would make to the team structure. I would make changes, too. But I’m not going to focus on those for the purpose of this blog post for a few reasons. First, I believe that making changes solely at the team level in this environment would have been of no value at all without solving the problem of managing the flow of work across the organization. Second, the alterations to the structure of the delivery team really aren’t mine to mandate; sure, I would make some recommendations and present some thoughts, but the Agile Coach in me wants to go back to having the team inspect their capabilities, adapt the structure to what makes sense and self-organize around owning future iterations of the structure.

To solve the underlying problem, the first step is to get Sales to make decisions around priority based on key business drivers (in this case, cash flow) in an environment of limited capacity. Remove the competition for resources, set the team up for less context-switching, and begin to identify bottlenecks, opportunities for growth and limitations in the system to be resolved over time. The flow of work improves, the metrics to measure progress (and needs to support growth) begin to emerge. The team is able to focus on delivery based on priority at the organizational level (as opposed to in-fighting and negotiating with three or more Sales Reps about whose sale is more important to get attention in this or the next Sprint).

Can it work?

Yes. Here is another example of a company who had product managers fighting for their development resources. This organization had sixteen developers working across forty products. There were forty product owners fighting for sixteen developers. We created a product owner team with a chief product owner. This created a “product funnel” by which the ideas and needs of the other thirty-nine product managers had to go through the chief product owner to get development resources.

With that construct, they were forced to govern the portfolio based on the prioritization of the organization, coupled with release planning, balancing capacity and demand. It was an extremely uncomfortable situation because the product management organization was always committing to many times more work than they could actually do. As they started to measure the entire portfolio of need against the ability to deliver, they came to the realization that there was capacity to support only 10% of what they wanted to deliver in their current state. Imagine, as a Senior VP of Product, seeing this reality in numbers – the pain of seeing the reality that your capacity is only 10% of what you need it to be. Imagine the pain, but imagine the power… what to prioritize, what to work with the Technology team’s leadership to do to improve capacity, what to communicate to Sales’ leadership in terms of setting customer expectations.   Was it painful to force this portfolio-style plan and force the organization to prioritize work together? Absolutely. Did it present problems that seemed insurmountable? Yes. Was the team able to solve the problem of capacity and eventually deliver the wants and needs of all 40 Product Managers? Yes.

Conclusion and my challenge to you

Agile is more than just Scrum. Agile is more than just cross-functional teams. Agile is a system of managing work and continuously improving that system to manage the flow and delivery engine behind that work. It’s about more than just the people; it’s about the system itself. If you are struggling with Agile for reasons akin to those mentioned here, I hope I have inspired you to take a look at how your organization prioritizes projects and how you manage disseminating the prioritized work to your development teams. If you are not managing a Kanban portfolio board, I challenge you to do it (whether it is on sticky notes on a board, Trello or some more sophisticated tool, just do it)! If you are good at prioritizing across the organization or are running a Kanban at the portfolio level, how can it be improved?

Now it’s your turn! What are some other ways you have improved prioritization?