This post originated from an RSS feed registered with Agile Buzz
by Mark Levison.
Original Post: Portfolio Management – Idle Teams
Feed Title: Notes from a Tool User
Feed URL: http://feeds.feedburner.com/NotesFromAToolUser
Feed Description: Thoughts about photography, software development, reading, food, wine and the world around us.
(Continued from Portfolio Management Part 1 in the Scrum Alone is Not Enough series.) Imagine that the Portfolio Management group is giving the individual Product Owners a budgetary envelope of an approximate size. As Product Owners, we expect to make small bets on individual User Stories that will deliver value to the customer. The Portfolio Management group wants to make mid-sized bets (>1 Team Sprint) that will deliver value to the customer. But let’s say the current Sprint is one in which some Team members don’t really have a lot to do. This is the type of scenario that often drives management crazy because they see idle workers, and traditional thinking is that idle workers don’t deliver value. This rarely ever happens in real life because there’s almost always more work than there is Teams to do it, but should the rare situation occur when one doesn’t have work in the current Sprint, questions that arise may be things like: should we temporarily reassign those Team members to other teams/projects that are lagging behind, to help them catch up? should we give them a feature that is further down the road in the backlog to work on in the meantime, with the thinking that it will give us a head start on it since they’re sitting idle anyway? The answer is, of course, to do neither. If the ‘idle’ Team were to join another Team temporarily, it wouldn’t speed things up – just the opposite, it would slow everything down. Disrupting that Team’s effectiveness and cadence, their contribution would be much smaller than their effect in reducing the other Team’s capacity. In addition, it could harm moral by suggesting that the other Team can’t handle the tasks themselves. And if the idle workers start developing a Feature that is further ahead on the Backlog, it undermines the Product Owner and Portfolio Management’s priority settings and decisions, which leaves room for “hey, could you do me a quick favour” requests within the Sprint that weren’t in the Sprint backlog. By the time the rest of the Team gets to that feature in the backlog, they may find that the work the idle Team had made on it is obsolete and needs to be undone before they can make new progress. The best solution is have ‘idle’ Team members look at the board and see if there are bottlenecks that they can help with within their own Team. They could also pay down their technical debt, or spend time learning something that expands their capacity as a Team to work outside of their current area/column(s) on the Kanban chart. For example, the Team in the previous examples might teach themselves something about testing or creating effective online help. The most effective thing (in terms of delivering value) is to not focus on the idle worker at all, but continue to focus on finishing the work and maximizing value delivered to the customer. This is where Portfolio Management can really excel, by understanding this fundamental truth and facilitating it.
Previous Topic
