Introduction

This article has been floating around my head for quite a while. It will encompass several themes. The first being, how do we “account for” the time and focus within our agile teams? Second is, how granular do we plan for and monitor the focus of our agile teams?  And finally, when planning and forecasting, should we plan at the individual level?

The “we” in these is a bit broad. I would include managers, directors, VP’s, C-level folks, the PMO and Project Managers. Virtually anyone who is tasked with “caring about” a technical team and what, how, and when they do what they do.

The Dinosaur Age

Well in this case, it’s not that long ago, but the analogy feels right to me. In this Dinosaur Age, project managers and “all management” for that matter, cared about people and their time. What are some of the aspects of that?

  • The world of time-sheets and project level tracking, relatively fine grained in nature. Usually captured “after the fact” so the data was error prone, but it served the accounting requirements of the organization.
  • Managers worry about keeping individuals “busy” in their project planning. Developers need to be coding and testers need to be testing. Nothing else matters as long as we’re optimizing at a functional (silo) level. We will “collaborate” when we “integrate”.
  • People are fungible resources[1] in this model. You care less about skill and capability, instead simply assigning tasks to people to the point of “100% utilization or more” is the goal.
  • Multi-tasking is the norm—especially for developers with specialized skills. In fact, it’s quite common to see a specialized person spread across 5-10-15 teams, with their “actual or realistic” capacity being ignored.
  • Quite often we try and predict projects (sourcing, utilization, needs) out for very long periods of time. We leverage individual’s capacity & utilization percentages, while filling in endless boxes on spreadsheets for this. Truly it’s an exercise of arithmetic!

A Story to Emphasize the Point

I led a rather large testing team for a number of years. Because the company was growing and the job market was quite active, we were continuously bringing new people into the organization. One of the things new hires struggled with was our product domain, which was data storage. The domain was very specific and the product interfaces were complex. It took our testers quite a while to come up to speed in understanding the domain, product set, and how to effectively test from the perspective of a systems administrator.

It struck me one day that I should come up with a spreadsheet to predict how quickly different level engineer/testers would come up to speed. If I could quantify their academic experience, background, technical skills, etc. then I could make a determination on how long before they became productive team members.

Why would I do this you might ask—where was the value?

I could then place these “ramp up assumptions” into the test plans and testing project plans so that I could accurately predict when projects would complete. You see we struggled to capture new hires in plans because of the variance in their learning curves. This would help me remove that variance. It would also help me in future team capacity forecasting when asked to contribute to our product roadmap planning.

I eventually created a large complex spreadsheet and used it successfully for a number of years. I even shared it with my development colleagues, since they had the same challenge, and they found it useful as well. I found myself constantly refining it and depended on it as my “new hire ramp oracle”.

But there was one problem. There was still wide variance in our plans and, dare I say it, many of our project plans (and projects), still failed. Unfortunately, my spreadsheet wasn’t the silver bullet I had hoped for.

Moral of the Story

The moral of the story is that traditional project management and people planning is an “in the weeds” activity. And I believe it’s at the wrong level. You shouldn’t be worrying about how to get Sally from 95% to 105% allocation for a project. Or splitting Bob across 5 projects and at a specific percentage allocation for each. Or what the magic number is to correctly account for meetings and other non-project related interruptions. It’s 25% by the way, so allocate everyone at 75% of their capacity…just kidding.

Essentially you are creating a false sense of control and micro-management that has nothing to do with the reality on the ground of your projects. It also treats everyone as if they were automatons or identical in skill and capacity. Worse yet is using these approaches for future project forecasting, planning, and commitments.

You are in the weeds, it’s ineffective, and it’s just plain wrong! Well, ok Bob. If this approach is wrong, what do you suggest we do?

I’m glad you asked…

Modern Day – Agile Approaches

Switching gears, I want to explore how I’ve approached similar activities in agile teams. Now the challenge is driven very much from the same goals. Time tracking is still necessary in projects. Resource (people) planning is still important, as is forecasting your future needs and growth.

You simply can’t ignore this in most companies, as you’ll be tracking a team budget and managing / forecasting it forward. I know, I know, you agile purists reading this will be crying “NO…” right now, but it’s generally a fact of life in a vast majority of companies.

Beyond that, it also factors into your release planning and portfolio management. That’s one of the main reasons that made me construct the spreadsheet earlier, was my need to try and bring some predictability to the skill & experience variances across our projects.

However, in the last 10+ years of my agile experience, I’ve been attacking the problem much differently than I used to. That’s what I want to explain in this article. How I’d recommend providing this data and performing these planning activities in agile contexts. Beyond that, I think they sensibly apply to ALL contexts, but you’ll need to be the arbiter of that.

Level First

It starts with realizing that managers and leaders should NOT be planning at an individual level. There’s simply too much change turbulence and adjustment going on. Instead, you should compose effective and small agile teams and then plan at a team level. Your teams will have skills and “personalities” that align with the work you expect them to perform. Often you’ll hear terms like Feature Team or Component Team[2] that are indicative of this alignment.

Another example is at Spotify[3] . They’ve created the notion of Squads and related notions of Tribes, Guilds, and Chapters as they scale their agile teams. The smallest unit, the squad, would be equivalent to a small (less than 10 member) agile team.  They are the smallest unit of execution and planning within the organization and product development is driven through each squad.

Lesson: Plan and forecast at a TEAM level. Don’t look below this level…ever!

Defining Your Team(s)

Create a balanced view to the types of teams you need. For example, when I was the Director of Software Engineering at iContact[4], we created Front-end/UI-centric and Backend-centric teams. Each team was composed of the skill sets to deliver end-to-end functionality. But some of their backlogs contained more front-end work and others backend work. We would staff the teams with from 4-7 developers and 1-2 testers balanced towards the work they would be doing.

We even went as far as trying to define a mission, vision, and personality for each team. In some cases, our selection of senior team members was driven by their skills, but also their work preferences.

Lesson: build balanced teams with the skills necessary to build their backlogs. Keep the team sizes approximately the same across the organization.

Ratio’s

As I mentioned in the last section, I think ratios are an important consideration as part of staffing well balanced teams. Now keep in mind that they ARE NOT silver bullets or magic numbers. They are guidelines when you’re looking at the overall balance across your teams when recruiting, growing or contracting your teams.

Ratio’s extend to your supporting casts as well. For example: architects, operations staff, Scrum Masters and Product Owners would be part of the consideration if you were growing a new team.

For example, Scrum recommends team sizes as 7 +/- 2; so a range in size with a top end view of 10. I like to include the Scrum Master and Product Owner in those numbers, in additional to full-time and part-time team members.  A common ratio we had at iContact was 4-6 developers, 1-2 testers, .5 architect, .5 Scrum Master and .5 Product Owner per team. Yes, our Scrum Masters and Product Owners handled two teams each.

In my personal experience, the “optimum” team size across several SaaS product domains where I worked was around six, so on the smaller side of the Scrum range. I think that number was effective because of reduced “communication channels” across the team. I’ve actually seen that overall number be effective in quite a few of the organizations I’ve coached.

Lesson: Maintain an understanding of your healthy team skill composition ratio’s, but don’t let it prevent you from continuously reexamining your balance.

Cross-Cutting Concerns

An important part of forming and supporting your teams is considering cross-cutting concerns. I would categorize these as early or late pipeline concerns. Early concerns would include UX, Architecture, and Business Analysis, while late concerns would include Documentation, Training, Customer Support, and Operations (DevOps).

Typically, these groups are dotted lined into the teams or shared part-time within the teams. Their support is crucial for the teams’ deliverables to be successfully deployed, so factoring them into your team mix is crucial. Equally crucial is establishing the right cross-cutting ratios for each team.

Let’s use Architecture as an example. I like to connect architects “into” agile teams. I don’t like it when they’re 100% outside of the team (throwing their ideas over the wall into the team) nor when they’re 100% inside of the team (so they have no time for research, prototyping, experimentation, and collaboration). I’ve found that there needs to be a balance so they can effectively “look ahead”, but then when they want to instantiate architecture, they directly engage their team(s) by joining them for a short time.

I’ve found this strategy to work well for all sorts of cross-cutting roles and functions. So you might establish a ration of sorts that your 10 Software Architects can effectively support the architectural needs of 20-25 teams. 

Lesson: You have to factor in cross-cutting concerns not only into your organization, but ratio’s need to be established to prevent multi-tasking and dilution.

Leadership Balance

As part of your team balancing act, you also need to consider the leadership component within each team. I consider the Product Owner and Scrum Master as leadership roles within the team. When you’re pairing them together you’ll want to consider their compatibility, skills, experience and connection within the team.

You’ll also want to provide some technical leadership within each team, not formally or title-based, but experiential. You might even go as far as establishing a Technical Team Lead or Feature Team Lead as part of your teams’ composition. Be careful though that the team is retains its self-direction technically.

One of my reviewers (Mary) reacted to this section with this caution:

I have had such bad experience with the Technical Team Lead role and losing team accountability that I am not a fan of you even recommending it. Maybe include something here about the Development and QA managers and the partnership they need to for with the SM and PO's on each team.

Mary is right that maintaining technical leadership (skills, experience) is a precarious and delicate thing. I think it helps to have the discussions when “setting up” teams, but in effect you want everyone to be a technical leader on a self-directed agile team.

Lesson: Teams need leadership, but not necessarily formally defined leaders. In the end, ALL team members should consider themselves “leaders”.

Velocity and the Release Train

Once you’ve established teams and the Product Backlog each will consume, then the focus shifts towards forecasting or forward looking capacity planning. This is where velocity comes into play. I typically recommend aggregating or normalizing[5] your velocity across teams who are contributing to the same product or project.

Then simply multiplying by your Release Train[6] tempo and your number of teams, you can get a feeling for the organizational capacity for each of your releases. This helps immensely in creating high level forecasts for your upper leadership team, PMO, and your Product teams.

And when you plan this way, please don’t plan your customer features at 100% of your overall capacity. I’ve found that a 75:25 or 80:20 mix of features to product investment (refactoring, bug fixes, infrastructural support, automation, etc.) is a balanced way to invest in your products.

Lesson: Establishing a regular tempo of iterative work and release, a heartbeat if you will, aligns the entire organization towards value delivery.

Maintenance & Support

Another important part of your iterative model is accommodating maintenance and firefighting activity. Minimally your velocity has to include these sorts of interruptions on a team-x-team basis. Another strategy is to form a team that “buffers” your other teams from the real world. I’ve leveraged both of these options successfully; separately and together.

The important thing is to not ignore or trivialize the rate of interruption.

The XP community has the notion of Yesterday’s Weather that can be useful here. It says: if you’re teams were interrupted at 30% of their capacity in the last sprint, chances are good that it will continue into the next. So plan / forecast for a rate of at least 30%.

But no matter how much you plan for it, there will be team-based interruptions that impact your velocity. This is one of the reasons you shouldn’t view velocity as a constant.

Lesson: You must reserve capacity at a realistic level to handle external interruptions to each teams’ work. There are no freebies here!

Another Story

We tried to plan about 2-3 releases in advance at iContact. These were quarterly releases, at a high-level, and encompassed all of our technical team members. Over time, we had roughly 8 – 12 Scrum teams and 3 Operations focused Kanban teams that were supporting our Product Development goals.

We were growing as an organization, so we grew by a “Scrum team” roughly every 1-2 quarters.

One of the first questions that would arise is where in our Product Backlog would we be investing these new teams? What sorts of features would we be building? What technical skills were required? In some cases we would split off a team to work on a newly created or “carved out” product area. In these cases, it was competitive advantage that would largely be the driving force. In other cases, we simply wanted to augment an existing team’s focus, so we could produce more functionality faster.

Once we understood what Backlog each team would be working on, we then planned their skill balance. Looking at the ratios required to create an effective team and whether our cross-cutting team members had sufficient bandwidth to accommodate each team. If not, we would plan to increase staffing there as well. We tried very hard to be balanced in our team ratios. Sure, we were usually light with testers and in other areas, but we aggressively worked to fill in gaps.

The next step for us was to look at release forecasting. Our average velocity per team was 25 points. Our Release Train was roughly quarterly in length, consisting of 4-2 week sprints. Using the rough team numbers above, we had approximately 1000 points per release (~ 10 teams) to invest in our SaaS products’ functionality. Every time we added a team, we added approximately 100 points worth of capacity to our ability to deliver customer features/ value.

As an aside, we would rarely invest ALL of that capacity into features for a release. Typically, we would reserve 25% for refactoring, infrastructure, bug repairs, interruptions, etc. So our Chief Product Owner had 750 points in which to invest in the highest value features per quarter. And our technical teams had significant bandwidth to maintain the technical soundness of the product AND our infrastructure.

To wrap up our strategy, when we planned we didn’t think in terms of individual team members. Instead we focused on:

  • The business needs, product priorities, and value investments;
  • Teams and their skill mapping towards the business needs and subsequent Product Backlogs;
  • Balanced the teams, including cross-cutting supporting casts;
  • Forecasted / planned at a Release Train leveraging a “lightly normalized” and cumulative Velocity;
  • As we grew, we took a team-based approach to planning for growth AND allowed the teams sufficient time for cohesion;
  • And finally, all of this was iterative, so we LEARNED what worked from a forecasting and delivery perspective, and made adjustments as necessary.

This worked incredibly well for us in a “rolling wave” fashion. While we often wanted to revert to our micro-management tendencies, we resisted “drilling into” the team’s capacity and focus. Even when the s**t was hitting the fan.

Overall, our teams appreciated this approach and they stepped up with ownership, a sense of urgency, and accountability for execution.

Wrapping Up

I highly recommend moving from individual to team-based arithmetic in nearly all of your management planning, accounting, and forecasting activities. It places the “weeds” where they should be—in the hands of the team to sort out. It also keeps your leadership view at the right level—towards goal-setting and guiding the organization.

I’ve also used the technique when planning for year over year hiring strategies. The discussions fundamentally change, here are some examples:

  • We’ll be adding a Front-end and a Back-end team to the mix in 2017. One will be working on a new product area and the other will tag-team with an existing team to augment our delivery in that area.
  • We’ll need 2 more Scrum Masters and 2 more Product Owners to complement those teams. The challenge will be finding the Product Owners with the appropriate domain experience. We better start looking for them now.
  • This will put significant pressure on our existing UX Design staff. We’ll need to hire another ‘designer’ to handle the additional cross-cutting workload.
  • This will increase our Quarterly Release capacity by 250 points. However, the teams probably won’t be fully hired and operational till early Q3, so the first two releases will remain at previous velocity levels.

And if the business wants to change Backlog (Portfolio / Release level commitments), then the conversation changes to:

  • Ok. Which team(s) do we divert to focus on the new initiative? Clearly we’ll need to drop what they were working on (or defer it).
  • Yes, we can divert work from one team to another team via the Backlog. But we’ve essentially said that we will divert a team, so we will effectively lose 125 points from our original plan and need to provide 125 for the re-focus efforts.

I don’t know about you, but I like the level of planning and dialogue that this approach creates. It’s balanced, appropriately focused, and just feels right to me. I hope you see the difference too.

Stay agile my friends,

Bob.

BTW: Here’s a complimentary article that speaks to moving from Project to Team-based funding models: https://www.linkedin.com/pulse/moving-from-project-team-based-funding-agile-michael-connolly

 

[1] I wrote a blog post awhile back that spoke to “language” as being important part of agile team leadership. You can read it here: http://rgalen.com/agile-training-news/2014/3/24/agile-leaders-watch-your-language

[2] Mike Cottmeyer has a solid discussion of these two team types here - http://www.leadingagile.com/2009/03/feature-teams-or-component-teams/

[3] Here’s a reference for the concept at Spotify –  http://techcrunch.com/2012/11/17/heres-how-spotify-scales-up-and-stays-agile-it-runs-squads-like-lean-startups/

[4] iContact was a small (~500 person) SaaS email marketing product company. It has since been acquired by Vocus, but the lessons learned there are still quite valuable. I had a blast working with those teams.

[5] Care should be taken when normalizing velocity across teams. By definition, Story Points (and Velocity) are unique per team. However, when you’re trying to forecast across many teams contributing to a singular product or project, it becomes nearly impossible IF the individual team velocities are highly skewed. For example one team has 25 points and another 200 per sprint. I typically coach so that the estimates – points – velocity is in close proximity for the work across ALL teams, for example: 20-28 points. Then I’ll average that and use it for very high-level forecasting and capacity discussions. In other words, I try to avoid the heavy handed model that SAFe recommends.

[6] More information on Agile Release Trains - http://scaledagileframework.com/agile-release-train/

 

Comment