Applying agile project management to large multi-team/multi-discipline projects can help overcome these boundaries. But if the boundaries and interactions of the teams aren’t handled properly, you can bet your ass you’ll be back to the same deadlock issues commonly experienced with the Waterfall Model.
Change is inevitable in the process of inventing a new product. It can come in the form of understanding limitations, including the complexity of a solution that may be much better addressed by changing an aspect of “the system” that crosses team boundaries. Since these changes may shift work from one team to another, territorial battles ensue in the desire to not add additional work to a team’s schedule that is already overloaded. These boundaries may arise from organizational, managerial, budget, and geographical roots; to name a few.
Managers are often motivated to get their slated tasks completed, but this often ends up in finger-pointing when pressure arrives — especially when shifting blame to other groups. This appears to lessen the blame for not making a given commitment, but in the end, the whole project takes a loss.
When working on large projects where multiple teams are necessary, these factors need to be overcome. The teams need to identify high-level and customer-facing features that involve a piece of work from Group A and a piece of work from Group B as a single story. Each person may get an assignment they can commit to completing by date X, but the entire team can be unified by this common goal.
Tearing Them Down
Bottom line, we are all playing on the same team, working toward the same goal: Deliver a great product. Breaking these boundaries down and working together is the only way to really get stuff done.
Geographical boundaries between teams (especially when involving time-zone shifts) is another difficult hurdle. Email communication alone can be dangerous and leave room for interpretation. Having access to Skype, WebEx, etc., can make communicating about the task at hand, along with hitches that may pop up, easier to overcome.
Transparency is a key component to making this all work, and it takes hard work to maintain across these boundaries. Our team has been using daily cross-team stand-up meetings and small sync-up points to help line up completion of dependent subtasks, break through team boundaries, and own any problems that come up… together.
To close the integration loop even tighter, we’ve lately been using resource lending. If team A is waiting on team B for a prerequisite features, team A could lend a resource to team B to help increase the velocity in order to tackle the prerequisites in a more timely manner. Basically the resource from team A becomes a resource to team B for a period of time until the scales are once again balanced so that development can proceed.
To be innovative, we have to make sure everyone is seeing the forest and not just a single tree. We all succeed and fail together when it comes to release time. Don’t let these boundaries bog you or your teams down. Tear down the walls!
Don’t forget to share!