Author: Robert Galen

Distributed Agile Teams: The ART of the START

Written by Robert Galen on November 20, 2013. Posted in Articles. 2 Comments on Distributed Agile Teams: The ART of the START

galenNov20 I’ve been sharing about agile methods for over ten years at conferences and workshops. One of the top three questions I always receive from attendees is:

Does agile work with distributed teams?

And sometimes the question is phrased another way:

The notion of co-located teams is nice in theory, but in real life we have team members all over the world. We need to cobble together teams based on our business needs from wherever they are. Does agile support that level of high distribution?

I often smile at the repetitiveness of the question. It indicates clearly that enterprise level software development is often distributed. It also indicates that outsourcing is still alive and well. I’ll try to provide some answers to these questions by sharing two stories of distributed teams I have experienced.

A Tale of Two Distributed Teams

The “Good”

I was lucky enough to be invited to do an agile jump-start for a new client. They are a rather large firm that builds hardware and software devices supporting mechanical control systems. They were kicking off several projects that encompassed many teams, some of them offshore and many distributed. They were looking to leverage Scrum as the method for starting these projects, and they invited me in to do some training and get the teams sprinting in this new style of product development.

When I arrived at my first class session, I learned that they had invited four complete Scrum teams to attend. In fact, one of the teams was based in India, and they had flown the entire team in for several weeks. The first week was for our Scrum boot camp, and the next few were to work with local teams as everyone started sprinting together.

I distinctly remember at the time thinking how novel this was. My typical experience with firms kicking off agile in distributed teams was more along the lines of the following:

Throw disparate individuals (local and remote) together into “teams”
Tell them they’re “going agile”
Send them some references on agile; at best, run them through a short class
Expect the team to start sprinting … ASAP
Expect great results
Rinse and repeat if you still have a customer …

Clearly I’m joking a bit here, but there is a good bit of truth in these steps. Many firms don’t start up their distributed agile teams very well. So I was understandably surprised at how thoughtful my client was in investing in their teams’ start.

I returned to the client several sprints later to do an informal assessment. By now the remote India team had returned home and was happily working with the local teams. I sat in on some of their stand-ups and other meetings. I was incredibly impressed with how well they were working as an agile team. I was even more impressed with how they integrated and collaborated with the local teams — it was virtually seamless.

It struck me that the cost the company had incurred in bringing everyone together to generate a solid start was paying them back big time. That solid project start-up had put everyone on the same footing and really solidified them as a set of cross-functional teams that had the same vision and were working toward the same goals.

As an aside, I’ve seen this same investment pay similar dividends at multiple clients. Now let’s explore another story.

The “Bad to Ugly”

I was invited to visit another set of teams to help them with some difficulties they were having working across distributed locations. They were executing sprint number five of a 12-sprint release sequence. There was a distributed UX/design team, two front-end UI development teams (one in the US and the other in Brazil), and a back-end development team in Singapore. In short, a very distributed mix across four distinct teams working on a single project.

One key challenge I remember was that the front-end and back-end teams were really struggling to figure out how to work together. They were using email and documents as their primary means of collaboration. But quite often, it would take days to sort out a simple interaction that was required to move a user story forward. And the issues weren’t focused on one team or one locale. There were pervasive communication problems across the teams.

One idea came up in a local (US) team’s retrospective. It turned out that nobody had ever “met” the offshore Singapore team that they had to integrate with (at an API level and at a project collaboration level). The idea was to have a video conference call across the two teams as a means of introduction and familiarization. Everyone thought it was a great idea and we scheduled the intro.

I volunteered to serve as the facilitator of the video introduction. There were eight members on our local UI team. We fired up the video and zoomed into the room in Singapore, eagerly expecting to meet a team roughly our size and composition.

And they started filling the room — and filling, and filling!

In the end, over 30 people came into the room from Singapore. We were amazed and during the course of the introduction quickly realized some things:

We had assumed some of them were men and they were actually women and vice versa … who knew?
There were two expectant mothers in the room … who knew?
We thought there were roughly 8-10 members of the team, and there were 30. Even funnier, we’d been working with them as if their capacity was 8-10. Who knew?
Clearly nobody on either side had ever seen or met each other. Apparently ALL collaboration was via email, text messages, and documents. Not a phone/video call to be had.
We learned about their background and skill levels, realizing that they knew much more than we had been giving them credit for … who knew?
We learned that they were heavily multitasking and being interrupted across many projects. Ours wasn’t their highest priority … who knew?
We finally realized that they didn’t like this “agile stuff” and preferred more traditional development approaches. So this was a major and difficult change for them and their leadership … who knew?

It was a fantastic, baseline setting call for the two teams. It created a much better understanding and led to much improved empathy, understanding, teamwork, and results going forward. But why this wasn’t the first thing that happened when the teams were formed and the project begun? They could have avoided a tremendous amount of frustration, waste, and missed progress. Who knew?

Three CORE Starting Patterns for Distributed Agile Teams

I hope my two real world stories have convinced you that a fundamental aspect of successfully implementing distributed agile is how you start your teams and projects. Here is a bit of a checklist to help you improve your distributed agility:

Establish the Team(s)

Formation – Take some time to thoughtfully form your teams. Introduce them. Allow for social collaboration of some sort.
Leadership – Take a look at the leadership within your organization and ensure that each team has some experienced technical leadership. Also ensure that each team’s local functional leadership is aligned with agile leadership fundamentals.
Co-Locate in Clusters – Look across the members you have to work with and try to cluster team members together (geographically) as much as possible.
Skills Aligned with Backlog – Remember that team skills need to align with the Product Backlog and that each team must have sufficient skill and domain experience to deliver high quality results.
Cross-Cutting Concerns – Consider how the team will handle cross-cutting concerns like UX design, architecture, and integration testing and deployment.

Train the Team Together

Basic Training – If possible, training should be approached as a whole team effort and is best done face-to-face. Everyone needs to hear the same things. Simulations should be a part of the training so that the teams get the opportunity to work together.
Roles & Responsibilities – Developing clarity around expectations is crucial for agile teams to start up. Taking the time to establish team and cross team roles and responsibilities and/or rules of engagement early will pay dividends during sprint execution.
Focus on Scrum Master and Product Owner – These are the most important and specialized roles within agile teams. Ensure you’ve selected wisely, don’t overload other roles, and provide sufficient training and ongoing coaching for these individuals. It’s crucial in distributed teams!
Start the First Sprint Together – If at all possible, start your first sprint with the team in the same locale. If that’s not possible, then start slowly, so that teams aren’t rushing to produce working software, but rather a “working team” should be their first goal.

Establish Norms, Standards, and a Charter

Team Norms – Set norms for listening, respect, behaviors, collaboration, quality, retrospectives, etc. Establish these as a team, post them on walls, and continuously remind yourselves of your agreements.
Meeting Norms – There can be an awful lot of meetings when moving to agility and conducting them can be exacerbated by time zone differences. Place heavy focus on just enough, just in time, and well facilitated meetings. Don’t forget the power of a time box.
Definition of Done – I have a nice presentation that depicts four levels of Definition-of-Done (DoD) or Done-Ness consideration within agile teams. There’s a link in the references. This is an area to truly focus on when working in a distributed team.
Tooling – Tools become more important in support of distributed teams, but they can also get in the way of collaboration and learning. Carefully select a minimal set of tools, while reinforcing face-to-face collaboration. Then grow your tools over time based on team feedback and needs.
Commitment to Agility – It is clearly harder to support agile tenants and tactics when participating within a distributed team. It will test your mettle. Establish broad commitment to your agile principles across teams and stick to them.
Chartering & Release Planning – These can be critical for cross team integration, dependencies, sharing a mission and vision, and determining and measuring success. The more time you can spend in up-front chartering activity, the better your results will be. So resist sprinting too soon!

Sprint Review Together!

One final point, distributed teams should perform their sprint demo/reviews together as much as possible. That would include members of each team and teams that are working together to deliver a project or product. The more you can integrate the demonstration of results, the more you will drive effective cross-team collaboration.

And improvements surfaced during the reviews will naturally cascade into the teams’ retrospectives, driving collaborative improvements.

Wrapping Up

Going back to my theme of what attendees ask me about distributed agile teams, there’s often another question:

Do we really have to do ____? It’s really hard to support that agile practice because we’re distributed!

You could fill in the blank with any of the following: swarm, collaborate, stand-up, groom, sprint plan, code review, design review, pair, test, talk to each other, etc.

My consistent answer is always — yes, you do. Now you may need to get creative with the how and the when in your support of solid agile team collaboration tactics, but skipping them when the going is tough is rarely good practice.

I’ll leave you with this thought.

Is agile harder to do in distributed teams? Of course it is. But is it possible to do it well in distributed teams? Absolutely. It’s truly up to the business to commit to properly starting their projects and the teams to commit to agility and figure out how to drive great results.

It’s simply another choice as you “go agile”. Please choose wisely.

Don’t forget to leave your comments below.

Agile Project Manager: WHIPping Things Into Shape

Written by Robert Galen on October 30, 2013. Posted in Articles. 4 Comments on Agile Project Manager: WHIPping Things Into Shape

I once was leading / coaching a team that struggled mightily to work together as a team. I was the Director of R&D at an eCommerce SaaS product company. We had been leveraging Scrum for a number of years with reasonably good success and had approximately 10 Scrum teams focusing on the various aspects of our online product.

But there were a couple of teams that were really struggling, which often seems to be the nature of things. Out of ten teams, we had about three that were high performing, three that were moderately performing, and three that struggled along. Don’t get me wrong, the team members were solid people and good employees. It was just that this whole “agile collaboration thing” was hard for some of them to grasp and embrace.

One particular team truly struggled. They had failed quite a few sprints in a row and I was intervening as a coach. Let me digress for just a moment on the whole failure thing, before you all start throwing tomatoes:

We measured success or failure not by hours, or points, or stories completed. We measured it by the team meeting their Sprint Goal that was established when they planned and committed to their sprint. There is a lot of angst in the Scrum community over using Pass vs. Fail or even using the word “commitment”. For the purposes of this article, I do not necessarily want to try and debate this practice. You can see references to some related posts at the end of the article. Suffice it to say that, at the time of this example, we measured and cared about sprints passing versus failing.

As they failed, they would talk about adjustments in their retrospectives. But the modifications were often quite trivial or safe. I felt they were not addressing the issues that were truly impacting their performance. I remember in one retrospective, they decided that the estimation units they were using were flawed. So they moved from a modified Fibonacci to Gummy Bears. Needlessly to say, the next sprint was not positively influenced by the adjustment.

This went on for quite some time.

I am normally a patient coach and I try to influence teams to observe and improve on their own. But this team truly was not “getting it”. So, after about their fourth or fifth failure in a row, I gathered the team’s Scrum Master and Product Owner in my office for a “chat”. I insisted that the failure pattern that they were experiencing needed to stop. I told them that I felt their root problem was that the team was not collaborating on their work. That they were operating as a Scrummer-fall based team and that individual work was the norm rather than teaming, swarming, collaboration, and teamwork. They agreed and they voiced their own frustration with the lack of improvement. But they did not know what to do and they were reluctant to “tell” the team what to do.
I quickly suggested two things. But the change had to be theirs. If they did not like my adjustment recommendations, then they should pick meaningful ones of their own, but they should stop dancing around the root challenges and truly attack meaningful adjustment ideas in their retrospective. Clearly, something had to change – for the team’s sake.

My Two Adjustments

I recommended two simple adjustments for their team:

First, I asked them to co-locate or sit together as a team, find a place where they could all sit together for one sprint. I spoke about the quintessential Agile team environment, where everyone sat at a long table – along both sides. The entire team residing in a single room, where they could see and hear each other and where they would be naturally pairing. A room where they could pull away from the laptops and gather around a whiteboard and where they could have their daily Scrum right there in the same space.

Could they just try it…for only a 2 week sprint?

Next, I asked them to limit their work-in-progress or WIP. I did not necessarily have a “magic number”, but I thought that a WIP limit of three might be useful for them. And, as a note, this would be a hard limit. The team could only work on three user stories in the Sprint Backlog at one time. These would be the highest priority stories. In order for them to pick-up the next story, they would have to complete one of the current three and demonstrate that it met their definition of “done”.

That was it. Two small changes fully targeted at their collaboration challenges.

Well, fast forward past their next retrospective and the team “accepted” my recommendations and tried them out. They found a large conference room that they took over as a team room and everyone moved into the room: front-developers, testers, back-end developers, Scrum Master and the Product Owner.

The whole team co-located for a sprint.

Their sprint planning went on largely as before, but the workflow strategies were strongly influenced by the WIP limits. In fact, they only planned on attacking the first three stories, leaving the remainder of the work to emerge during the sprint. So, they did a bit of guessing on how much would fit into the sprint.

But, importantly, they left sprint planning with a commitment to a body of work and a commitment to swarm on their work as a team. They were willing to give the adjustments an honest try.

Results

I rarely like to use numbers to illustrate results because they can be misleading and miss much of the nuance. However, in this case, I want to leverage some of the team’s numbers simply because it illustrates the impact these modifications had AND the results the team realized.
The team previously would commit to a body of work and deliver only 60-75% of the work (stories) toward their sprint goals. That was typical. They also often missed delivering higher priority stories over lower priority stories.

The sprint where they made these two adjustments, the team delivered to 140% of their commitment; pulling more work in than they had thought feasible. Not only that, they delivered in priority order, so if something had happened they would have delivered higher value first.

But there is even a hidden fact I have left out. It just so happened that this team received a new team member a few days before the sprint started. While being an experienced engineer, this person was totally new to the company, product, and team. As part of the team’s renewed focus on collaboration and swarming, they embraced the new developer and he actually had a net-net positive impact on the sprint’s results.

What Changes Do WIP Limits Influence?

Even before Kanban became more popular I was leveraging WIP limits in my coaching as an aid to driving collaboration and swarming around work. The reality is that when a team swarms around their work and removes delays, hand-offs, and inspection points, they simply get more done. But it is often hard for some teams to realize it.

Getting back to our team, what did they experience over their initial sprint?

The daily Scrum became more of a collaborative planning session than a status meeting for the team. The discussions surrounded who would work with whom to maximize their focus on the limited WIP and effectively working together.
Since the team only had a few things to work on, keeping them “flowing” towards completion was important. So any delays, impediments, or issues became immediately visible and required team-wide adjustments. This helped in getting work “done” as well as improving their throughput.
It was funny. Even though they all sat in close proximity, the team had not truly collaborated previously. But removing all of the walls and getting everyone co-located changed the collaborative dynamic. There was much more dynamic pairing across team members and natural cross-team communication.
Another aspect of the room was work visualization. There was a shared whiteboard where the team had their sprint plans. Story and task card movement was incredibly visual and the team spent time at the board every day adjusting their visualizations for work pairings and workflow.
Quality was better as the developers and testers paired more frequently and naturally. They found bugs quickly and focused on repairing them rather than talking about or documenting them for later resolution.
As I mentioned earlier, the team really did not plan the sprint end-to-end in the traditional sense. Instead, they planned each new story as they picked it up, changing their collaboration as required. It was dynamic, fast, and optimized the throughput of the team towards getting things DONE!

The key conversations in the daily stand-up moved from “What has each individual done or what do they plan to do?” to “How does the team maximize their daily focus to get the highest priority work done as quickly and as well as possible?”

Wrapping Up

As for my example team, some might wonder what happened after that initial sprint. Did they move back to their old offices? Did they change back to their old habits? And did they continue to improve?

I will leave that answer for another time and another article.

The real point is – are you struggling to collaborate as a team? Are your developers holding on to work too long? Do you have too many stories in play at once and miss delivering important work? Is Scrummer-fall alive and well in your organization? Or are you just not as productive as you think you could be?

If so, please consider sitting together and limiting your WIP. You just might see a different result.

Don’t forget to leave your comments below.

The Agile Project Manager – Individual vs Team Arithmetic

Written by Robert Galen on October 2, 2013. Posted in Articles. 3 Comments on The Agile Project Manager – Individual vs Team Arithmetic

Introduction

This article has been floating around my head for quite a while. It will encompass several themes. First is, how do we “account for” the time and focus within our teams? Second is, how granular do we plan for and monitor the focus of our 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 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 people, capacity & utilization percentages, 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 accurately 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!

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 predictive spreadsheet earlier, was the need to try and bring some sanity 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¹ that are indicative of this alignment.

Another example is at Spotify² . 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.

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³, 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.

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 team “communication channels” across the team. I’ve actually seen that overall number be effective in quite a few organizations I’ve coached.

Cross-Cutting Concerns

An important part of forming and supporting your teams is to consider 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 (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.

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 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.

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 ¹your velocity across teams who are contributing to the same product or project.

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

Roadmap Decomposition into Backlogs & Work Teams

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

Quite often your Product team will make Product Backlog adjustments as progress is being made—potentially moving work from one team to the next.

Literally all roadmap and portfolio planning at this level is on a team basis. Individuals and their capacity, not matter how crucial or specialized, does not come into play. Essentially, we’re intentionally trying to stay out of the “weeds”.

Another Story

We tried to plan about 2-3 releases in advance at iContact. These were quarterly releases and encompassed all of our technical team members. Over time, we had roughly 8 – 10 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 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.

So 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 Product Backlogs
Balanced the teams, including cross-cutting supporting casts
Forecasted / planned at a Release Train leveraging cumulative Velocity

This worked incredibly well for us in a “rolling wave” fashion. While it was often hard, we resisted “drilling into” the teams and micro-managing capacity and focus. I think the overall results helped us “stay out of the weeds”.

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 keeps your leadership view at the right level—guiding / leading 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 2014. 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 as well.

Thanks for listening,

Bob.

Don’t forget to leave your comments below.

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

2 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/

3 iContact was a small (300 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.

4 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 135 per sprint. I typically coach so that the estimates – points – velocity is in close proximity for the work. Say 20-28 points across team. Then I’ll average that and use it for very high-level forecasting and capacity discussions.

5 More information on Agile Release Trains – http://scaledagileframework.com/agile-release-train/

Selecting an Agile Coach: Critical Considerations P2

Written by Robert Galen on September 4, 2013. Posted in Articles. 4 Comments on Selecting an Agile Coach: Critical Considerations P2

galen sept4 At the risk of sounding a bit self-serving, I thought I’d share some thoughts around how to select an agile coach. Since the Agile Methods nearly always require a seasoned guiding hand to help you accelerate your adoption and transformation, this is one of the more important decisions you’ll make. Here is the continuation of a list of critical areas (click here for part #1) I consider when hiring a coach and in sharpening my own experiences as an agile coach.

Independent vs. Group Affiliations

One of the more difficult decisions you have to make is who to approach. Coaches essentially come from the following affiliations:

Type	Description	PRO	CON
Independent coach	Either a sole proprietor or a small collection of like-minded coaches; usually have training as a service	Usually quite experienced, vertical areas of skill, well known & established, strong consistency	Bandwidth and availability – scheduling. Rarely want long term engagements, costs
Agile Coaching firm	A company/group that specializes in agile coaching. Often training is part of their services portfolio.	Consistent coaching model, bench strength and collaboration	Varied coaching skills, typically want to embed coaches, costs
Agile Tooling firm	A company whose primary business model is tooling, but they’ve also provided training and coaching services	If you’re ‘leading’ your adoption w/tooling, bundled services.	Tooling can get in the way – conflicted goals, inconsistent coaching
Search firm	A search & recruiting firm that has ‘discovered’ agile methods and coaching services. Dual priority of coaching & staffing / staff augmentation	Aggressive pricing, bundled services, ability to find coaches – scale themselves	Inconsistent coaching quality, coach retention, it’s not their primary business model

The major advantage with the firm model is they will have multiple coaches to serve your needs. This usually surfaces in bench strength and more timely support of your ad-hoc needs. However, these firms will have coaches at varying levels of experience and you’ll rarely get the chance to cherry pick the best coach that provides your best match. Instead you’ll be engaging the firm rather than a specific coach.

When engaging individuals, you’ll almost always engage a sole proprietor with perhaps a handful of like-minded colleague partners behind them. Often you’ll have to wait for their schedules to “free up” and, if they run into problems such as illness, it may impact your engagement.

However, the advantage is that you’re engaging a known quantity and there will be no unintended “bait and switch” activity going on. It also makes selecting the coach easier because you’ll be interacting directly with your coach.

Purist vs. Pragmatist

For over 10 years I’ve been categorizing agilists, myself included, as either a purists or pragmatists. There’s nothing wrong with either side, but it’s how they approach implementing and coaching the methods that is at play.

A purist often focuses on one method, and while promoting it, doesn’t take liberties in the implementation. For example, a purist Scrum coach would either implement core Scrum as defined in the Agile Atlas (if they’re from the Scrum Alliance) or core Scrum as defined in the Scrum Guide (if they’re from Scrum.org). There would be very little “wiggle room” in their implementation and, if you deviated from anything in the definition, you’d be confronted for a ScrumButt.

I liken pragmatists to being passionate and determined in their agile adoption guidance. However, they apply experience, common sense, and some situational flexibility to their engagements. They consider where their client is “coming from”, before they suggest next steps—so as to not set the bar unreachably high.

I liken myself to be a pragmatist, but know many purist coaches. The world needs both kinds, but you’ll probably want to be uniquely selective to one side or the other. If you’re selecting multiple (or a team of) coaches, mixing and matching at this level rarely produces good results.

Professional Engagement

The focus here is does the coach contribute to the overall agile community? In particular, have they written coaching guidance via books, blogs, and articles? Do they have recordings available of presentations or podcasts that you can view? And importantly, how long and how active have they been contributing. This is also a wonderful way to verify the coaches experience claims.

Additionally, do they volunteer in the agile community? For example, have they presented at a Scrum Gathering or Agile Conference. Do they participate in their local agile groups, as a leader, presenter, and attendee?

A big part of this is checking the “passion level” of the coach. Are they an agile coach because they’re simply interested in the money or are they passionate about agile and are they willing to “give back” to the wonderful agile community we have.

The “Match”

Beyond pure experience and skills, the coaches’ personality and style needs to mesh with your teams, your leadership team, and your culture. One of the things I do for prospective clients is give a free lunch & learn as a means of getting to know one other. Borrowing a term from a famous dating service, I refer to it as: “It’s Just Lunch”. This is the chance for us to meet and explore the compatibility between myself and the organization.

And don’t forget the match goes both ways. As a coach, I want to make sure that the organization I’m coaching aligns with my own principles and practices. I’m primarily looking at the leadership team to determine if they’re sufficiently knowledgeable and committed enough to guide their teams through the agile transformation. And they’re checking me out to ensure I don’t do “too much damage” during the transformation.

I highly recommend this approach of “trying before you buy”; usually by having immersed discussions and potential ‘auditions’ for nearly a day.

Rates

Of course rates matter. But my recommendation is to make cost a secondary consideration. You’ll want to get the best coach possible for your organization, by aligning with as many of these selection considerations as possible. I think it best to defer rate discussions until quite late in the process.

Once you have narrowed the field to one or two coaches, then bring rates into play. Usually the length of the engagement is a significant factor for discounts and some coaches even provide a pro bono aspect to their coaching, so explore these as options. In the end, don’t let money influence you towards a lesser coach. You’ll pay dearly for this misstep.

Checking References

Finally to check references or not to check, that is the question. The answer is…please check! But be sensitive to the timing of checking references. You’ll want to go through your due diligence and basic analysis first. Most coaches only want to engage their references (remember they’re customers like you) if the deal is reaching maturity and as a near final step in the process.

And don’t ask for too many references. One or two should suffice. Once you get the references, you want to strike quickly. The coach has probably primed the references for your call, so you don’t want to take 2-3-4 weeks and then surprise them out of context.

Wrapping up

So here are questions and a critical consideration list when it comes to selecting your next agile coach. You may not want to run through all of them, but I hope they help your selection conversations:

How much experience do they have? Internal vs. external coaching? What about variety in their coaching? Explore what ‘typical’ coaching engagements look like—how do they ‘enter’ an organization? And when do they know it’s time to ‘exit’?
How much method breadth do they have within their coaching? Do they apply cross aspects of one method to others? Ask for an example or two of how.
It’s one thing to be well-read. It’s another to be well experienced. Explore the latter. Ask about their successes AND their failures as a coach. What determines success? Or failure?
Ask the coach if they’ve ever turned away clients. And if so, what are the general reasons for this decision. Here you’re looking for indications of their selection criteria and “hot buttons” for agile coaching success.
Check their certifications. This is a two-edged sword. Some coaches have a literal “alphabet soup” of credentials. Others have a much smaller list. Some certifications are much stronger than others. For example the CSC and CST. You can go to the Scrum Alliance site and check certifications here:
It’s not easy to determine whether your coach is a purist or pragmatist. Questions on non-Core Scrum activities, such as Hardening Sprints or Sprint #0 or multi-tasking Scrum Masters will probably evoke discussions that will give you a clue as to their ‘leanage’.
Have a “bench strength” conversation with your coach, if they’re an individual or part of a group. Speak to coaching consistency as they scale. Ask how many teams they can coach in parallel with their preferred model.
Ask your coach where they spend the most time coaching, at the team level, management level, or leadership level. Does organizational maturity influence these percentages? Ask where they are the most “comfortable”?
Ask your coach how they serve the agile community? How do they share lessons learned? Have they ever coached an individual or team pro bono? Ask when and why. What about sharing their knowledge and wisdom—how have they done that. Or if they haven’t, ask when they plan on doing so.
Try to ascertain the ego level of the coach. Ask if one of their coached teams or organizations fail (or regress) how do they take that? Have they failed? How do they retrospect on failures and successes? How do they adjust their coaching styles for different situations—ask for a couple of examples.
Ask them to rate themselves as coaches. Ask them to identify 2 coaches who are better than they are; and ask why? Ask them to share who they’ve been mentored by most recently and what have they learned.

One final point, please don’t perceive these steps as daunting to the point of preventing you from pursuing a coach. I see so many agile teams that could use a solid coach that I don’t want the selection process to scare you away. Take whichever of these considerations make sense to you and leverage them in your search. I’d rather you simplify the criteria and steps and get the best coach possible, then shy away entirely.

Good luck in your agile journey…Thanks for listening,

Bob.

Don’t forget to leave your comments below.

Selecting an Agile Coach: Critical Considerations P1

Written by Robert Galen on August 7, 2013. Posted in Articles. 4 Comments on Selecting an Agile Coach: Critical Considerations P1

At the risk of sounding self-serving, I thought I’d share some thoughts around how to select an agile coach. Since the Agile Methods nearly always require a seasoned guiding hand to help you accelerate your adoption and transformation, this is one of the more important decisions you’ll make. Given that criticality, here is a list of critical areas I consider when hiring a coach and in sharpening my own experiences as an agile coach.

First, Reflect

You’ll want to consider WHY you’re looking for a coach. What challenges are you facing? What sorts of skills are you expecting them to bring? If you’re just starting up, then finding a coach that has experience “jump starting” agile teams will be your initial goal. If you’ve been agile for a while and looking for a “tune up” and assessment, then that might take you in a slightly different direction. Most coaches can handle both sides of that spectrum, but it’s useful to be clear on where you are on the adoption curve.

Realize that there’s a special relationship established between the agile coach and the organization they’re coaching. First of all, you need to be prepared to establish a partnership with your coach. Be ready to share your “dirty laundry” and your personal challenges. Be ready to trust the coaches you select; not only their experience, but their character and integrity.

Be open to learning from them, but be also open to challenging them to “raise the bar” in your agile adoption efforts.

And important part of any coaching relationship is measurement. How will you measure the results they provide? A typical measurement scenario is to focus on the teams and their productivity—measuring before, during and after coaching. But it’s not as simple as that. Agile measures are quite different than traditional measures, so you’ll want to do some research. You’ll also want to include your team and measure their personal reactions to the coaches.

Finally, do some initial research into agile coaching firms and individuals. Leverage your network and LinkedIn to survey the landscape. Word of mouth and personal recommendations are a powerful place to begin your search.

Work Experience

It’s normal for agile coaches to either focus on the organizational / team coaching (non-technical) areas or on technical coaching areas. In the latter, they usually focus on tooling and technical practices, for example Continuous Integration or Deployment (CI/CD), Test-Driven Development (TDD), and Refactoring & Patterns. For these coaches you’re looking for work experience that often aligns with your technology stack and domain dynamics. Often architects or very senior developers transition into this style of coaching. You’ll also want to see some public speaking and teaching in their backgrounds to ensure they can effectively teach their skills in pairs and small groups. Quite often the interview or selection of these coaches is more of an audition—where the come in and pair with team members in your organization. You’ll be assessing technical coaching chops by “doing” rather than “telling”.

For organizational coaches, beyond the direct agile coaching experience, you also want to consider the work experience behind the coach. What technical background and roles have they held? What sort of diversity in those roles? And have they held leadership roles in organizations.

I’ve found the best coaches to have a breadth and a depth to their work experience that rounds them out. For example, having held architecture, analysis & design, development, and testing roles in a variety of software organizations can be a distinct advantage for these coaches. Another advantage is having grown in their careers to hold senior leadership (Director, VP, and/or C-level) roles.

In general, knowledge of software development, testing, project management, and team leadership is incredibly helpful for coaches. So look for the breadth, but also the depth.

Coaching Experience

Now let’s get the elephant on the table. There are simply too many agile coaches around today! It seems like every agilist who has a modicum of experience at a team level is hanging out their coaching shingle. I feel like they’re misleading the community and potential clients. Sure, they might have a successful experience or two, but in limited contexts. Agile is simple to grasp, but hard to execute contextually. Only with many years of broad, deep, and varied experience do you get a coach that will have the skills and instincts to truly guide you.

Is there a magic number of years of experience? Probably not. But I personally look for coaches with around 10+ years of experience. I’m looking for in-the-trenches experience, for example they’ve been an internal coach as part of an agile transformation, as well as external consultative coaching experience. They’ve worked with small and large organization, while having encountered entrenched Waterfall and entrepreneurial and open minded start-ups. The point being, they’ve been “around the block”.

Don’t necessarily get stuck on coaches having a direct “domain match” to your existing business and product domain. For example, I recently was approached to coach a BI and Analytics team and the client was looking for direct BI experience. From my perspective, I’m not sure that it matters so much, particularly if you’re a deeply experienced coach. In fact, domain awareness can sometimes get in the way of your effectiveness.

The Methods

Whether you know it or not, there isn’t a succinct agile methodology. Rather there is a ‘family’ of methods that attempt to support and adhere to the Agile Manifesto and its corresponding principles. Some of the more popular method and framework areas include:

Methods: Scrum, Extreme Programming, Kanban, Lean Software, AUP, DSDM, and Crystal. The more widely used are Scrum, XP, and Kanban.
Tactics: Continuous Integration & Continuous Deployment, Test Driven Development (TDD), Pairing, User Stories, Release Planning.
Frameworks for Scaling: SAFe, DAD, Scrum of Scrums, PMO, Agile COE, Agile CoP, etc.
Bodies of Knowledge (BOK’s): PMI-PMBOK, IIBA-BOK, Pragmatic Marketing, PDMA, Testing-BOK, etc.
Soft Skills: Leadership Coaching, Facilitation, Emotional Intelligence, 5 Dysfunctions, Open Space, MBTI or other personality type, etc.
Tooling : Tools become particularly important in at-scale and distributed agile contexts. If tools are a focus, clearly look for matching experience.

The broader the experience your coach brings, real experience mind you, across these areas the more flexible and sound they’re approaches will be as they tailor things to your context. I guess what I’m saying is don’t get a coach who has a “one size fits all” approach to each of their agile engagements. Varied experience and a context-based approach will always be more valuable to you as you evolve your agile transformation efforts.

Certifications

Again at the risk of sounding self-serving, I think the CSC (Certified Scrum Coach) designation is a differentiator for coaches. In particular, it helps assure that the coach has moved beyond singular team coaching and towards Enterprise-level or organizational transformation coaching at scale. So you gain some assurances that their experience is broad and deep and contextual.

Beyond that, the ‘bar’ for the CSC is arguably quite high, with roughly 75% of applicants not being accepted. Not only is your knowledge and skill evaluated, but candidates are interviewed by CSC peers in a rather lengthy and rigorous process. As of this writing, there were approximately 200,000 CSM’s in the Scrum Alliance, but only ~ 60 CSC’s in the world, ~25 of which are in North America.

Now I think certification has to compliment real world chops, so don’t blindly hire CSC’s. But the credential (s) a coach brings to the table certainly matters and should be a part of your decision-making process.

Models – Embedded vs. Others

There seems to be two overriding models in the coaching community. Some coaches want to embed with your teams full-time. The contract is usually for a set period of time and the coaching is by and large continuous. Usually these engagements are in larger organizations so that the coaches can influence more than one team at a time. They typically get involved in organizational transformation as well.

The other model, and the one that I subscribe to, is a more part-time coaching model. Usually this model is more tightly coupled to your Sprint tempo, with the coaches engaging at the endpoints of each Sprint. They help close the previous Sprint and then plan for the next. Sometimes they’ll provide remote coaching between the endpoints, but it’s essentially an iterative model that parallels your own team(s) Sprint and Release tempos.

The key differences in the approaches are cost and autonomy, with the latter approach typically being less costly and promoting the teams to more quickly stand on their own. However, the former approach does align with most consulting contract experience and it is a simpler business model to orchestrate.

My experience is that the latter model places pressure on the teams to become self-directed, self-reliant, and higher performance more quickly. But both models can be effective.

Trainer vs. Coach

I’ll use the CST (Certified Scrum Trainer) vs. CSC (Certified Scrum Coach) comparison here to make the point. There are quite a few CST’s who also do a bit of coaching. The challenge is the ratio of coaching vs. training. If you teach classes too often, you lose your edge when it comes to “in the trenches” coaching experience and ability. Essentially, you’re too academic and you’ve lost touch with real world challenges. There are quite a few trainers who do a majority of training and high-level consulting, and very little coaching. In my opinion, they should largely decline coaching assignments as they’ve lost their relevancy.

At the same time, every good coach must have the ability to do training classes as part of their toolkit. The key is to looking for coaches first, who are also knowledgeable and experienced trainers. This combination turns out to be the most powerful.

Prescription Balance

There is a genre of agile coach that doesn’t tell teams how to do things…under any circumstances. They are intentionally non-prescriptive. The thinking generally goes that in order for a self-directed team to form and gel, it’s inappropriate to tell them what to do. They have to discover the path on their own, with the coach being their guide. This is honorable and true for a more experienced agile team, but what about providing guidance for new or inexperienced teams?

It would be like throwing a group of 8-10 years olds without baseball experience on a field, giving them the “rule book”, and the tools (bats, balls, bases, etc.) and saying—go play baseball. They would be spinning their wheels mightily for quite a while and they might never figure out the entire nuance of the game.

It turns out that coaches need to be balanced, but also comfortable in giving team’s firm direction when it’s necessary and important. Many are uncomfortable with that, and you’ll want to stay away from those IF you’re just beginning your transformation / adoption.

I believe that constraints, rules, and direction are actually an important part of creating the landscape for agile teams and organizations to mature quickly. It’s getting the right level of experience to understand when to tell and when to allow the direction to emerge that is developed across years of coaching experience.

But should you also ensure that your potential coaches aren’t “too prescriptive”? Of course you should because that will undermine your agile path as well.

Wrapping Up

This is a two-part article with advice towards selecting your next agile coach. As with anything in life, you need to leverage your own experience, context, and common sense in this process. I would also like to mention your “gut”. I’ve found that my gut gives me quite a lot of information when I’m looking for specific individuals on my teams. I’d encourage you to use yours when selecting a coach.

When your interviewing your coaches, please strive to create conversations instead of simply Q&A interviewing. Not that long ago, I went through a coaching interview. It was a panel of 4 interviewers and for 90 minutes they peppered me with questions. Only at the very end, did I have some time for my own questions and they were cut off by the lack of time.

This isn’t a good interviewing strategy in general and certainly not for an experienced coach. I’d strongly encourage for you to ask situational, open-ended questions in an effort to share stories and get to learn about each other. In other words, simply have a conversation. I think you’ll get more out it.

Thanks for listening,
Bob.

Don’t forget to leave your comments below.