Ever been on a project where you needed someone (a specialist) outside of your agile development team to do work for you? For example, I once worked with a team that was developing a medical software application and frequently needed legal specialists to draft or review the text that would appear in dialog boxes. As a result, the team’s work was often blocked while it waited for the legal experts to get around to doing their work.
In this blog post I discuss several patterns for how you can engage specialists that reside outside your agile development team so as not to impede your team’s ability to achieve fast, flexible, flow. None of these patterns will work for everyone, and there is no “best” pattern. Rather, each pattern is intended to be a starting point for learning what works for you and your situation.
Remove Non-Specialized Work from Specialist
The first pattern is for the agile development team to immediately take for itself all work that an outside specialist is not uniquely qualified to do. So, to return to the medical system example, rather than rely on a lawyer to compose the dialog box text, perhaps the team instead could submit the first draft of the text to the lawyer for review, revision (if necessary), and approval.
As another example, a different team I encountered had enlisted the help of a graphic artist to develop critical assets for a product. I noticed that part of the work the artist had been doing was to convert art files from one graphics format to another. Converting files is not work that an artist is uniquely qualified do. I suggested that members of the development team do the file conversion work instead, freeing the artist up to create the art.
When the team takes on any work that a specialist doesn’t absolutely need to do, it lessens the problem of having to rely on an outside specialist. Basically in agile if we can’t eliminate the problem then we try to make it a smaller problem!
Outsource to a Component Team
But what about work that must be done by an outside specialist, someone uniquely qualified to do it? In many companies people with a common specialty skill are often put into the same group and operate like a component team that provides services based on their specialty skill to other teams.
So for example, the lawyers (collectively known as the legal department) could operate as legal component team. Any development team that needs legal services to complete a product backlog item would then separate out the legal work from the product backlog item. They would then put a request in the legal team’s queue or backlog to work on that piece (see diagram).
The legal team can operate in whatever fashion it has typically worked. In an organization that is embracing agile principles throughout the value chain (see blog post Agile Misalignment Through the Enterprise Value Chain), the legal team could operate as a Scrum team or run a Kanban system to manage its work.
No matter how the legal team operates internally, from the perspective of the development teams, the legal team is semantically identical to a classic component team (see blog post Distinguishing Between Feature & Component Teams for a more detailed description of component teams). The most common problem with this pattern is that the component team often becomes a bottleneck for the development teams.
For example, each development team puts its request into the legal team’s queue. This creates many dependencies since each development team is now dependent on the legal team to complete the legal part of the work before a development team can finish its feature (e.g., the feature in the medical software system is not complete until approved text for the dialog box is provided by the legal team and integrated into the software). The legal team will prioritize all of the competing development team requests for legal services using whatever approach the legal team deems appropriate. As a result, each development team doesn’t really know when its request will be fulfilled and will often be blocked waiting for the legal team (see diagram).
As a result, the legal team and the development team will operate asynchronously from one another. The resulting delays may or may not be a big problem depending on the length of the delay and how much lead time each development team has built in to its schedule.
Include a Specialist on Development Team
An alternative pattern to help avoid the problems of using component teams is to add the specialist (e.g., lawyer) as a member of the development team (see diagram). This approach would make sense if there were a sufficient amount of work to justify having the specialist as part of the team.
Being on a Scrum team would mean by default that the specialist would attend the daily scrum and arguably other Scrum meetings, such as sprint planning, sprint review, and sprint retrospective (like any other team member would).
Again using the medical software application as an example, the idea here is that there is enough legal work on this project that a legal team member is necessary for the development team to be cross-functionally diverse enough to get product backlog items done by the end of the sprint.
Unlike the previous pattern, notice in this pattern’s diagram there is no splitting of the product backlog item into legal work that is put in the legal backlog, and the rest of the work that stays with the development team. Since the development team now includes legal skills, the full product backlog item, including all of the legal work, goes to the development team and is completed synchronously during a sprint.
Of course, this approach has its downfalls as well. First, in most organizations there won’t be enough specialists to assign one to every development team. Also, often a development team doesn’t really need a specialist on a full-time basis.
Use Specialist as Consultant
Given that many teams don’t need a specialist full time, another pattern I have seen is to have specialists act as consultants to the development team (see diagram).
In this pattern the specialist is not actually a member of the development team, and therefore would not attend the Scrum meetings. Instead the specialist would make himself reasonably available to assist the development team with work that the specialist is uniquely qualified to do. For example, a lawyer would handle legal issues like drafting, reviewing, and approving text for dialog boxes.
The benefit of using a consultant as opposed to adding a team member is the flexibility it offers the teams and the organization. During times when the team is doing a lot of work that requires a specific specialist, the consultant could work on a nearly full-time basis for that team. At other times, when not as much specialty work is needed, the consultant might only offer a few hours per iteration. For example, at certain stages of development, a graphic designer might be needed full-time for several iterations in a row. Later, that same designer might only need to revise or approve the implementation of a concept once per iteration. A consultant pattern allows for these ebbs and flows in demand.
Let me give you an example of how this could work even if a team never needed a specialist full time. Suppose each lawyer at an organization is assigned to support several teams. So, the lawyer tells each team he will be available two hours a day to work on whatever that team needs him to work on. So at some designated time during the day, the lawyer walks over to the development team area with his laptop, sits down, and says, “OK, I’m here. What is the most important work you want me to do for you right now?” He then does that work. Then that same lawyer moves on to the next team he is supporting.
At the medical software company that I worked with, during the original implementation of this pattern we had the lawyer come for a two-hour window first thing each morning. However, after a couple of sprints the team concluded that often enough it didn’t always have two hours of work for the lawyer queued up by that time of the day. And, sometimes work for the lawyer would come up late morning, outside the two-hour window, so there would be almost a full-day delay before the lawyer would be available again to work on it. So, the team inspected and adapted and asked if the lawyer could come for the first hour around mid-morning and the second hour mid-afternoon. Overall this approach resulted in better flow and less delay since no new high-priority request for the lawyer would have to wait more than half a day.
Of course the same criticisms that were levied against the previous pattern can be levied against this pattern: There often aren’t enough consultants for each team to have a specialist full-time, even on a short-term basis. And if one consultant is assigned to too many teams, that specialist quickly becomes a bottleneck.
Conclusion
In this posting I presented several patterns for how a development team could engage with a specialist. There isn’t one pattern that is best for all teams. Instead the factors that I mentioned with each pattern should be considered when selecting a pattern to try. Since you are doing agile, don’t worry about initially selecting the perfect pattern. Try a pattern to see how well it works for your organization and then inspect and adapt, which might involve trying another pattern. Eventually you will converge on a good approach for your team.