Coordinating activities on agile delivery teams
One of the key characteristics of Disciplined Agile Delivery (DAD) is that it is goal driven. This simplifies process tailoring, simplifies identifying potential process improvements, reduces the prescription inherent in other software methods, and enables scaling. One of the process goals identified by the DAD process framework is Coordinate Activities, one of the ongoing goals throughout the delivery effort. The fundamental question that this goal addresses is what options do individuals on an agile team have to coordinate their work with other people that they are involved with? Note that this work may not occur completely within the team, that team members may find that they need to coordinate with people external to their team.
The process goal diagram for Coordinate Activities is shown below. The rounded rectangle indicates the goal, the squared rectangles indicate issues or process factors that you may need to consider, and the lists in the right hand column represent potential strategies or practices that you may choose to adopt to address those issues. The lists with an arrow to the left are ordered, indicating that in general the options at the top of the list are more preferable from an agile point of view than the options towards the bottom. The highlighted options (bolded and italicized) indicate default starting points for teams looking for a good place to start but who don’t want to invest a lot of time in process tailoring right now. Each of these practices/strategies has advantages and disadvantages, and none are perfect in all situations, which is why it is important to understand the options you have available to you.
An interesting thing about this process goal diagram is that it makes it very clear that there might be a bit more to coordination on an agile team than just holding a short meeting every day. For example, people may share information within the team, and with people external to the team, via conversations, reviews, and non-solo development techniques such as pair programming or modeling with others. Another interesting thing is that to avoid the problem of method branding (see The New Deal for Software Development) we use descriptive terms such as Coordination Meeting instead of Scrum Meeting or Daily Scrum.
Several of the issues are team focused, in particular Artifact Ownership and Coordinate Within Team. Several reflect the fact that DAD teams are enterprise aware and thus describe strategies to coordinate with others external to the team. For example, your team may need to coordinate with your organization’s enterprise architects and operations staff, potentially adopting some of the strategies captured by Coordinate Across IT (and you are also likely to do so via Share Information strategies). If your organization has a release organization then your team may need to adopt one or more Coordinate Release Schedule strategies (or, if there’s no release team then your team will still need to coordinate releases with other delivery teams, and with your operations team, somehow).
Several issues address scaling factors. For example, large teams (often called programmes) will find that they need to adopt strategies called out by Coordinate Within Programme. Teams that are geographically or organizationally distributed will need to consider strategies from Coordinate Between Locations. Naturally if you don’t face a scaling issue such as geographic distribution then the issue Coordinate Between Locations isn’t something you need to consider.
I wanted to share two important observations about this goal. First, this goal, along with Explore Initial Scope, Identify Initial Technical Strategy, and Move Closer to a Deployable Release seem to take the brunt of your process tailoring efforts when working at scale. It really does seem to be one of those Pareto situations where 20% addresses 80% of the work, more on this in a future blog posting. Second, as with all process goal diagrams, the one above doesn’t provide an exhaustive list of options although it does provide a pretty good start.
I’m a firm believer that a team should tailor their strategy, including their team structure, their work environment, and their process, to reflect the situation that they find themselves in. When it comes to process tailoring, process goal diagrams not only help teams to identify the issues they need to consider they also summarize potential options available to them. Agile teams with a minimal bit of process guidance such as this are in a much better situation to tailor their approach that teams that are trying to figure it out on their own. The DAD process decision framework provides this guidance.