Skip to main content

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

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

Tug of War

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?

Next Understanding Risk in Your Project Portfolio

Comments (4)

  1. Kirsten

    Hi, thanks for the post.

    I just don’t get this bit: “Sprint backlog jammed full of multiple stories from multiple products for multiple customers”

    What on earth is any organisation doing mixing stories from multiple products? What a completely crazy idea for an experienced team let alone any team new to agile. The first thing to do would be to maintain separate backlogs and to have a sprint for each product surely? And while they are at it, halve the sprint length so that a single sprint can be delivered for a single product once a week. That way the team can focus on delivering for the business goals for one product and satisfying one product owner at any one time. Whilst this sprint is running, it’s time for project managers, product owners (including sales) and other stakeholders (including customers) to refine their own backlog and prepare it so that when their sprint occurs it can be hit with maximum efficiency. I’d say that around 25% of the overall effort can go into this phase so it isn’t ‘wasted time’.

    Then teams can be pulled out of their sprint at a predefined time in the week so there are no surprises (we like to do an hour on a Wednesday afternoon) and do a planning poker (or any other sizing session) on the stories coming up the following sprint. This leaves Thursday and Friday for the non production team to further refine and prioritise their backlog ready for their sprint and after a few sprints they can do this based on a good understanding on what the production teams throughput will be (so long as they capture the data).

    From my experience it’s really good for the team to have a clear understanding of the sprint goals and objectives and to then allow them to work their magic without competing teams. They can then all work together to meet those goals by the end of the sprint and leave satisfied at the end of the week that they have all contributed to a significant improvement in the product they have been working on.

  2. Jeff Howey

    Kirsten, great observation regarding the backlog – both in terms of asking the question “why would anyone do that” and in providing an option for managing the backlog(s) in a thoughtful approach. So many teams first “learn” Scrum or Kanban with the thought that they must work against 1 backlog – and come to a conclusion that they will just throw everything and the kitchen sink into that one list and call it a backlog – even if it requires constant context-switching. The concepts of planning ahead, designing your backlogs and teams to manage flow and focus releases on themes and “packages of value” through planning, coordination and clarity of purpose certainly do set the stage for growing the Agile practices into greater maturity levels. Like you, I’m a big fan of pre-scheduled, regular and recurring times for the relevant team members to participate in Story Telling, Backlog Grooming and other activities that allow us to practice good product and project management as part and parcel of our agile practice. Thank you for chiming in!

  3. Jerilyn

    Hi Jeff, This sentence struck me: 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.

    I’m wondering how they measured this. Did they use story points? Did they have the actual development team estimate on these epics?

    • Jeff Howey

      Good question Jerilyn! The Epics were decomposed into Stories and estimated in Points by the development team. The organization had become accustomed to speaking about Points instead of hours and understood the concept of Velocity. To see that your have a throughput velocity of, say, 100 points per sprint is very useful. When you see an outstanding backlog of 2000 points that you’d like to have “done” in a month, it becomes incredibly clear what is possible and what is not – so that priorities and trade-offs can be discussed. I’m always a huge fan of having those who do the work estimate the work. The commitments are far more predictable than having some 3rd party “estimate” work at the granularity of Points that they are not responsible to deliver. Other affinity estimates like t-shirt sizing or ideal weeks may be useful further up the planning and roadmapping chain, but not when getting down to the level of needing a commitment.


Leave a comment

Your email address will not be published. Required fields are marked *