Scaling Agile to the enterprise can be challenging once you start looking at the Program and Portfolio level. How do you design an effective coordination system that encourages collaboration, communication, transparency and is flexible, easy to implement and rapidly evolvable? We will explore key aspects of creating a simple but effective agile-ready coordination system for managing such initiatives, based upon the authors' observations and experiences across widely differing companies.
Many otherwise astute agilists have struggled when faced with the challenge of scaling methods like Scrum to large, multiteam projects and programs. Luckily, this shared hardship has resulted in some creative solutions to the problems such efforts can pose. We will explore key aspects of creating a simple but effective agile-ready coordination system for managing such initiatives, based upon the authors’ observations and experiences across widely differing companies.
Guiding Principles
The goals of an agile-appropriate portfolio coordination system might be stated as follows:
Build trust and engagement through transparency by making priorities, dependencies, and capacity visible and discussing them regularly.
Facilitate informed strategic guidance via clear communication to key stakeholders about current and potential delivery challenges.
Bridge silos and functional organizations with regular, coordinated collaborative touch points.
Provide rapid, targeted portfolio management with minimal time or capital investment.
We will explore how these objectives might be achieved in a process with minimal overhead and setup time.
The Scrum of Scrums Is Not Enough
Much of the early agile literature spoke from the perspective of a single team. Scrum, the most popular agile framework today, espoused a simple mechanism called the Scrum of Scrums for coordination between multiple teams. However, this mechanism is rather loosely defined and often is inadequate for complex dependency management across multiple releases and a portfolio of projects.
Originally, the Scrum of Scrums was described as a daily meeting between ScrumMasters across teams, which followed a similar structure to the daily scrum but focused on progress, plans, and blockers at the team rather than individual level. One key problem with this system was that it implicitly relied on ScrumMasters to know the details of every issue. Also, the fact that external stakeholders are often needed for negotiation, communication, or blocker removal can make their absence a progress-killing issue.
Many teams have moved beyond the Scrum of Scrums or modified it in ways that they find better suited to the complexities of their situations.
The Ubiquitous Visual Management System
Large, visible “information radiators” have been a common theme in agile implementations, and they figure perhaps even more prominently in the lean manufacturing implementations that inspired many agile values and practices.
For example, Japanese companies such as Toyota long shunned complex material resource planning systems in favor of simple paper charts, bins sized to fit just so many parts, and other similarly low-tech tools. The persistent presence, ease of creation and change, and ability of such systems to facilitate group interactivity was hard to beat.
In today’s agile teams, one continues to encounter physical Scrum taskboards being used alongside full-fledged software suites, proof of the efficacy and persistent appeal of physicality.
Creating a Portfolio Management System and Team
Let us tell a story by way of example: Nine teams are working together on the delivery of several major projects on an enterprise business intelligence platform. The teams are mostly focused on delivery of independent feature groups, but there are two exceptions. One team helps to create and manage shared data services and enterprise service bus integration; this team’s backlog is populated by the other teams. Another team is a vendor that is implementing its software to provide some visualization pathways for mobile and tablet devices. It’s operating on a slightly modified waterfall development lifecycle.
The rapid pace, continuous integration, and high information flow across a set of agile teams require an equally nimble coordinating structure. The teams also want to engage frequently with high-level stakeholders, so meetings have to be short and focused, which will be a welcome change in any case. The system as a whole will consist
| Attachment | Size |
|---|---|
 3604399.pdf | 1.16 MB |
About the author
Arlen Bankston, Executive Vice President and Managing Partner, LitheSpeed, LLC. Arlen is an established leader in the application and evolution of process management methodologies such as Lean, Six Sigma and BPM, as well as Agile software development processes such as Extreme Programming (XP) and Scrum. He is a Lean Six Sigma Master Black Belt and Certified ScrumMaster Trainer. He also has twelve years of experience in product design, leveraging principles of information architecture, interaction design and usability to develop innovative products that meet customers' expressed and unspoken needs. Arlen has led Agile and Lean deployment and managed process improvement projects at clients such as Capital One, T. Rowe Price, Freddie Mac, and the Armed Forces Benefits Association. Arlen's recent work has centered on combining Lean Six Sigma process improvement methods with Agile execution to dramatically improve both the speed and quality of business results. He hasalso led the integration of interaction design and usability practices into Agile methodologies, presenting and training frequently at both industry conferences and to Fortune 100 clients
About the author
With twenty-five years of project management, software development, engineering, and business experience, Bob Payne is the VP of coaching services at LitheSpeed, LLC and a leading proponent of agile methodologies and agile engineering practices. As host of the AgileToolkit podcast, Bob has produced more than 120 podcasts, recording a variety of industry leaders and agile practitioners
