By Ken Collier and Lynn Winterboer (first published in TDWI BI This Week on July 30, 2013)

Agile leaders focus more on the continuous delivery of high-priority value to business stakeholders and less on making sure each worker is always busy. We explain how your BI program will benefit by limiting developer multi-tasking.

Ben and Susan are each a DW/BI director at their respective companies; each leads a department of roughly the same size. Both have the staffing necessary to organize three dedicated, cross-functional teams. Ben’s department is organized into dedicated teams while Susan has functional skills “pools” from which project teams are staffed. Both directors are planning for the coming year and have a similar set of 12 projects to schedule.

Through collaboration with business stakeholders, product owners, project managers, and the program management office (PMO), Ben has a prioritized backlog of funded project requests to schedule into the calendar. With help from technical leaders, he has completed some high-level project sizing and assigned durations of two, three, or four months per project. Projects longer than four months are divided into multiple phases, each designed to fit into one of these smaller time periods. This ensures that long-running projects do not block other projects by dominating the department’s capacity.

Ben assigns a dedicated team to each of the first three projects in the backlog. He then estimates when each team might be free to start its next project, continuing in this manner until he has a reasonable program plan for the coming year:

Because Ben continuously pulls from a program backlog, the whole process takes less than an hour of Ben’s time, and he is comfortable sharing this project road map with stakeholders and the PMO. This company’s agile culture includes an agreement that once a project is started, the team will stay focused on that project until the project time frame is finished. Adaptation to project reprioritization does not affect projects that are already underway. Because business and management stakeholders are involved in the prioritization process, there are no surprises about the program schedule. Everyone also understands that the program backlog is always evolving based on the changing needs of the business.

Meanwhile, Susan is also doing resource planning for her department. She has met with each of the BI team’s key stakeholders to get their input on priorities for the year. She’s heard passionate explanations from each about why their top priority projects are important to the company, such as “I need sales pipeline analytics ASAP so I can ensure the marketing team is ready to support our key industries!” (from the VP of sales and marketing) and “I need net profit margin per product so I can report accurately to our investors!” (from the VP of finance).

Susan understands the importance of each of these projects, and wants to get them started as quickly as possible. Moreover, her CIO is focused on maximizing personnel utilization, desiring that every team member be utilized 100 percent on project work. Susan believes if she gets team members started on more projects sooner, and has them spread across multiple projects, her CIO and stakeholders will be confident she’s doing everything she can to focus her teams appropriately. Therefore, she structures each project to have a dedicated core team of two developers with the part-time support of product owners, project managers, data modelers, testers, and business analysts. Several of these projects are expected to take 6-12 months to complete, so Susan needs to run at least six projects concurrently in order to meet the urgent needs of the business.

As Susan’s delivery strategy gets underway project team members plan in two-week iterations for the multiple projects to which they are assigned. This means that each team member is attending at least two, and sometimes three, planning meetings every two weeks. They are also attending multiple daily stand-up meetings, iteration showcases, and retrospectives. Project managers and product owners are only able to devote cursory time to assist on each project, and they often feel disconnected from what’s actually happening. The core developers dedicated to each project are frustrated because they cannot count on having the support they need from data modelers, testers, business analysts, and others. This is further complicated by the fact that there doesn’t seem to be any common time when the entire project team can work together.

Every team seems to over-commit on each iteration, failing to finish stories as planned. In part this is caused by the significant overhead incurred as team members switch from one project context to another (approximately 20 percent per additional project, per Weinberg, 1991).

Susan failed to account for this waste in her resource plan. This triggers two side effects. It is evident that the projects will not finish on time, and teams’ (and Susan’s) ability to accurately predict when each will finish is nebulous. Each team is cutting testing corners under the duress of over commitments, which will cause increased maintenance/support issues.

As much as Susan tries to create a great culture and work atmosphere, people in her department are unhappy. They are stressed by the job pressures and often feel like hamsters on a wheel, running fast and getting nowhere. There is a general lack of collegiality in the BI group and people often blame their colleagues when things go badly. Many staff members have remarked on the difficulty of trying to do too many things at once, but Susan doesn’t think they understand the pressure she is under to meet the needs of the business.

Consider the differences in the directors’ situations.

	Ben		Susan
Project focus	Finishing projects as soon as possible		Starting as many projects as possible
Staffing philosophy	Prioritize project delivery over staff utilization		Prioritize staff utilization over project delivery
Corporate prioritization	PMO facilitates cross-functional prioritization for the BI team so the BI director is not left with making these important decisions him/herself		BI director makes cross-functional prioritization decisions
Corporate culture	Supports a team staying focused on a single project until it is complete		Team splits focus across multiple projects at a time
Stakeholder expectations	Stakeholders understand the relatively short timeframe when they need to be available for each project to be successful		Stakeholders must be available for long periods of time if they want their projects to be successful
Project completion	Project focus is constrained; each successive project starts later but is completed earlier		Project focus is stretched; each project starts as early as possible and is completed much later
BI director’s confidence	Confident enough to get started on project work, knowing he’s done the right amount of planning at this point. Glad it only took him an hour! Expects several easy re-planning sessions throughout the year due to changing corporate priorities.		Worn out after an entire afternoon spent wrestling with a spreadsheet and resource allocations. Hopes she didn’t miss anything in the details. Uncomfortable with the message she will take to the CIO and stakeholders, not to mention the impacts of stress on her team. Expects several painful re-planning sessions throughout the year due to changing corporate priorities.

Big Themes

It is often counter intuitive that dedicating a team to one project at a time will better satisfy stakeholders, yet agile teams that focus exclusively on one thing at a time are able to deliver value more quickly to their organizations because:

• Starting projects earlier does not ensure they will be finished sooner
• Project multi-tasking has an unseen penalty cost that will further delay finish dates
• Focusing on maximizing utilization over project completion has unintended consequences

Resources

Brown, R. (2010, June 29). Multitasking Gets You There Later. Retrieved June 20, 2013, from InfoQ
Cohn, M. (2009). Succeeding With Agile. Boston: Addison-Wesley Professional.
Weinberg, G. M. (1991). Quality Software Management Volume 1: Systems Thinking. Dorset House.