How to Use Agile with a Consulting Team

I had two different students ask me a very similar question – how do you apply agile in a consulting environment? Here is the specific request from one of them.

My team is made up of 3 different developers. Our bosses want us to do an agile-ish approach, where we do daily stand-ups, work in sprints, do retros, etc. However, none of us are dedicated resources, and can be pulled into client work at any given time. From everything I remember from class, it sounds like what is being proposed for us runs counter to so much of what you taught us (i.e., working on sprint work only with as few distractions as possible). Would you agree?

My other student had a similar request – he was working in an agency and had to juggle different client work all the time. They don’t have dedicated teams and team members float to where the demand is. Can you leverage agile in this context? Let’s explore!

What Makes it Difficult to Apply Agile in Consulting

Let’s face it, applying agile ways of working in a consulting environment can be difficult. Most people engaged in consulting are specialist and not generalist. That leads to efficiency (though not effectiveness). Their expertise is typically leveraged across multiple client engagements and that creates a number of challenges to using agile in consulting:

• A tendency to assign people to multiple teams
• Leveraging projects and project managers for each client to keep all the work on track
• Lack of team member autonomy and self-organization
• Working at a pace that is not sustainable
• A heavy focus on client satisfaction which can have a negative on team members to deliver and meet expectations

There is one other consideration. People that mis-apply Scrum will cause more waste than the value provided by the framework. Consider the example of the student question above. If they use Scrum and work in Sprints, they are going to pay the price if people are spread across multiple teams. That is because Scrum has some overhead.

Don’t Ignore the Overhead of Scrum

Scrum carries with it a certain amount of overhead that should not be ignored. The overhead of the meetings consume about 15% each person’s working capacity, as described in this related article, There are Too Many Meetings in Scrum.

Team members are expected to participate in a regular cadence of Scrum events and meetings each sprint. While these meetings foster collaboration, knowledge-sharing, commitment and accountability, the overhead should not be ignored. Teams are expected to have a shared understanding of the work to be done by their team and feel a collective ownership for completing the goals of the Sprint. Like the Rugby teams that inspired Scrum, a good Scrum Team is aligned on common objectives. The regular cadence of meetings help them to recalibrate and ensure they are maximizing the value they deliver.

But the goal of maximizing delivered value falls apart pretty quickly when people are assigned to multiple Scrum teams.  If you put a person on two teams at the same time, 30% of their capacity is wasted in meetings. Someone on 5 teams has 75% of their time in meetings and 25% trying to get all the work done. They are the ones that show up late to the meetings and spend the time talking about all the tasks they didn’t get done because, wait for it, they were in meetings.

That overhead is more of a feature of Scrum than a weakness. I mean, you could eliminate the meetings but then it wouldn’t be Scrum anymore.

A recent article by Gallup, Too Many Teams, Too Many Bosses: Overcoming Matrix Madness describes some of the costs of working this way:

On average, matrixed workers spend more time in meetings and less time thinking about and doing their own work. One-third of highly matrixed workers say they spend most of their day in internal meetings. In contrast, only 2% of non-matrixed employees and 12% of slightly matrixed employees say their day is bogged down with internal meetings.

Many matrixed employees feel overwhelmed by the onslaught of messages, questions, information requests and meetings with bosses, peers, subordinates and customers. A staggering 45% of highly matrixed workers say they spend most of their day responding to requests from coworkers.

— Robert Sutton and Ben Wigert, Gallup

Organize Into Effective Agile Teams – One Team per Person

Here is a really novel idea – organize the people that you have in the most effective way. The people you have are going to be the limiting factor for how much work you can do. That’s right, the limiting factor for how much valuable work you can do is the number of people that you have. So organize the people you have in the most effective way. And that means putting each person on just one agile team.

Now I have had enough conversations on this to know that just saying that will make many of your heads explode. We don’t have enough people to put them on dedicated teams!

Hmm, let’s unpack that. Either you have enough people or you don’t – Use your math! It is the same number of people any way that you organize them! You aren’t Michael Keaton in Multiplicity who could just keep creating copies of himself:

People are your limiting factor. So it makes sense to use your valuable people in the most effective way possible.

Instead of spreading people across teams like peanut butter, try a novel idea – one team member on one agile team. Yep, you read that correctly, stop assigning people to more than one Scrum team. One person, one team. Assigning people to more than one team does more than just have them sitting in more meetings. It also creates the following undesirable side effects:

• Everyone is constantly multitasking and switching gears between the various clients and teams they have been assigned to. Multitasking is a huge obvious cost that everyone ignores, though studies have shown that it eats up about 20% of a person’s capacity for each additional project they are working on.
• All meetings are slower and less effective. Everyone is busy and assigned to multiple teams and multitasking. Which makes meetings painful, slow and no longer effective in creating alignment, collaboration and shared consciousness. Instead, meetings are ineffective and wasteful. Everyone is multi-tasking and only partially paying attention. That means everything takes longer. Multitasking is like a tax on every person and every team. All meetings are longer than needed and costly when you consider the run rate of all the team members.
• Cost of Project Managers to corral people and make unrealistic promises to clients
• Lack of autonomy due to lack of self-managing teams and a corresponding lack of motivation. Do I really get fired up about all 3 or 4 of my teams? Do I feel passionate about all of them? Am I excited to throw myself as a human sacrifice just to make the company a few more schmeckels?

The bottom line is that it is ineffective to spread people across multiple teams. Doing so creates a ton of waste and inefficiency and reduces predictability. Why would you assign your valuable people to multiple teams and squander your their valuable time with all the overhead, meetings and other inefficiencies described above?

So does that mean we should not use agile in consulting teams? Not at all, it just means that you need to do so thoughtfully. Don’t just tell your people to take an agilish-approach, use sprints or daily meetings. That won’t be an effective use of agile in consulting teams. 

How to Use Agile For Consulting Teams

Now, I’ve coached consulting teams and other teams in similar situations and I have an approach in mind. There are probably many approaches and if you have another one, please add your comments below. Here are some specific things that I think you can do:

1. Eliminate Projects from the Vocabulary – A key paradigm shift is to eliminate the idea of projects. Sure clients have requests and deadlines, but forcing an agile team to work in one or more projects is a stick in the spokes which slows things down and gums everything up. Drop projects. Consider everything that your clients need as simply work that can be put into a prioritized backlog.

[See my related post about how using projects and project managers actually makes failure more likely or this related and very humorous post by Bry Willis].

2. Create One Backlog for Each Team – Break those projects down into chunks or features and put them into a single backlog. Some of those features may have due dates but those dates and commitments don’t get “assigned” to the team. Rather, a Product Owner needs to set priorities and manage client expectations as we describe next.

3. Have One Product Owner Prioritize the Backlog – Rather than having multiple project managers aligned to clients and promising things that others need to deliver on, have a Product Owner for each team and each backlog. That product owner needs to work closely with all the clients that the team supports. It may be just one client or it may be several. With a predictable velocity, the Product Owner can forecast delivery dates with some level of accuracy. They can also make decisions and tradeoffs between clients.

4. Organize Around Dedicated Teams Pointed at the Prioritized Backlog – See my rant above on this topic.

A key side benefit of dedicated teams is a predictable level of delivery or velocity. Teams that work together over time get quite predictable in their delivery. That is going to be essential for the Product Owner to manage delivery expectations with clients. The more you move away from dedicated teams, the less predictable your delivery becomes and the more likely that the dates being promised by the Product Owner won’t be realistic and achievable.

5. Cross Train and Invest in Team Skills – Right off the bat one challenge will be making sure that the team has all the skills needed to deliver the work in the combined backlog of client “features”. Without handing off to another team. This may require some selective staffing or an investment in cross-training. Most consultants are grateful to be asked to cross-train so long as they are given the time to to it.

6. Work at a Sustainable Pace – This may be the toughest thing to do. Most consulting firms have a “whatever it takes” approach when it comes to working. Traditionally the commitments and promise dates were not based on reality and as a result, people needed to cram to get everything done. That included late late night and weekend work.

So rather than agree to clients dates which are often arbitrary, negotiate so that clients get the features they need in the time desired. That is possible with a skillful product owner managing the prioritized backlog and a dedicated team working at a sustainable pace. That results in predictability.

Don’t think this can work? Here is an example of a team I worked with over 10 years ago who used exactly this approach.

A Real Life Example of an Agile Consulting Team

Many years ago, I supported several teams that worked for an IT consulting firm. The firm built commerce and CRM solutions for different clients and they did it using 4 agile teams. One of those teams is described in the following excerpt from my book, Agile Project Management. [Download Agile Project Management here].

The key aspects of this team include:

• Team had one backlog, prioritized by one product owner
• Team worked in 2 week sprints
• Team leveraged features – sometimes called minimum marketable features
• Team members not shared with other teams – mostly

In short, the team was effective in using agile in consulting.

Overview of the “Far Flung” Agile Team in IT Consulting

The Far Flung Team was a distributed team that operated as part of a small software solutions company.  They were a small team, distributed globally and they built solutions for multiple external clients of the company they work for.

The Far Flung Team supported multiple customers, which posed a unique set of challenges. How could the team prioritize needs across multiple clients? They could not really afford to partition and dedicate the work in one sprint to only one of their clients. Some clients had major development needs and others were in maintenance mode and had small needs.

What the team settled on was an approach to maintain separate prioritized backlogs for each client, but then pull them together so that they could view them as one combined backlog. They pulled from this combined backlog for each sprint. A client services manager served as proxy for the client Product Owners. The client services manager helped to prioritize the combined backlog for the team. It became very common for the team to deliver stories for multiple clients in the same sprint.

Like Team Mobility, the Far Flung Team is small by Scrum standards with only four full-time members and one half-time member. The team was supported by a Scrum Master who was shared with two other teams. This smallness was felt most in terms of team member specialization, as well as continuity and capacity when team members took vacations or holidays. Four of the team members were developers with similar skill sets, while the half time person focused on requirements and testing. The specialization was primarily around client accounts; there was usually just one developer who fully understood each client.

The Far Flung Team was also distributed and rarely had the opportunity to work together in the same space. Three of the team members were located in Chicago, one was in Milwaukee and one was located in France! The team dealt with this by using instant messaging and web conferencing tools during the working days of their sprints. Also, the team members in Chicago and Milwaukee would meet at the company offices for their beginning and end of sprint meetings, like Sprint Planning, Review and Retrospective. The team member in France didn’t have this luxury and had never met most of the other team members in person.

The team was also unique in that several of the team members were developers but had other outside interests and treated the job as part time. Two of the team members played guitar in a band, which led to unconventional work hours and patterns.

Because of their diverse backlogs and their physical distribution, the team used CA Rally as an online ALM tool. The use of the CA Rally tool helped them to coordinate their efforts and have a common view of the work in the Sprint. They did not have a corresponding physical task board since no two people worked in the same place.

A Day in the Life of the Far Flung Team

A typical day for the team would start early for the team member located in France. Like another member of the team, he also worked as a musician. His performances sometimes kept him up late so it was not a problem for him to sleep in a little and shift his work day to align with other team members. He would often develop things early in the day and send them over to other team members to review or test.

Next up was one of the Chicago-based team members who was an early riser. He and his European counterpart would use Jabber and Skype to connect and collaborate. Another team member would work from the company offices and join the IM conversations when she arrived. The last team member to arrive was another musician in the group. He often showed up at his computer at home right at 10:00am in time for the daily Scrum meeting.

The daily meeting at 10 would generally flow pretty smoothly from day to day. These meetings usually took 20-25 minutes, which is beyond the 15 minutes that Scrum prescribes. Each person would bring up the task board in Rally and provide updates to their tasks, including changing the hours remaining or dragging the task to another column to change the progress. In addition to task status, team members shared updates from the clients as appropriate, since some of the team members were the point of contact for clients.

The rest of the day would be pretty quiet, with some IM conversations, and occasionally a phone call or Skype call. Calls frequently revolved around specific functionality for a particular client and the client services manager would schedule client personnel to participate as appropriate.

As mentioned previously, the team would all meet in the Chicago office for the beginning and end of sprint meetings (except for the French team member). The team would do the review to the internal client engagement manager, their Scrum Master, and other members of the company’s management team. There would frequently be other reviews scheduled separately with individual clients to go through a story, but this was more common mid-sprint or after the end of the sprint. After the Sprint Review, the Scrum Master would facilitate the team retrospective. This would be over a teleconference with a screen sharing tool for the team member in France. Then the team would break for lunch.

After lunch, the team would perform Sprint Planning. This generally lasted 3 hours and sometimes was not entirely completed. The team in the Chicago office bid farewell and did not see each other for another 2 weeks.

Key Challenges for the Far Flung Team

The key challenges for this team were the physical separation and the team size. The distance made it difficult for effective team building and self-organization. The team performance was hindered by lack of growth and a fair amount of storming was common.

For example, the team had found it easier to divide and conquer rather than collaborate on stories. This meant that one team member was frequently responsible for each story, and for each customer. For the highest performing team members this did not cause a problem. It did cause a problem for the most junior developer who frequently did not finish the stories he committed to complete. He was reluctant to ask for help or let others know he was in trouble.

The physical separation made communications more difficult and disconnects were common. It was not uncommon for a client to complain about communication gaps between team members. This was somewhat mitigated by the fact that each Client had a developer that understood them and was their single point of contact. However, communications were less than perfect and the team struggled when members were on vacation.

The physical separation also hindered cross-training. There was virtually no pairing and little development of the more junior developers. The team worked in silos.

The team size was another challenge for Far Flung. Having just four and a half team members is below the recommended Scrum team. Compounded by the physical separation, this created problems with specialization, and key person risks for specific client accounts.