In my normal cadence, this week would be another installment in the Baby Steps to SOA series. However, with a few weeks of vacation under my belt, I was not prepared to tackle the important discussion of centralizing eCommerce business logic quite yet. That being said, my vacation time did allow me to finally finish reading Dean Leffingwell’s Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise.
The content of the book, along with the content scaledagileframework.com (SAFe), provides a great blueprint for bringing agile mindsets to larger enterprises. It goes beyond just the problems on the development team and covers all the tiers of the enterprise, including the executives.
Investing at the Portfolio and Program level
Most of us who practice agile have already gone through the basics of getting our development teams formed up with Product Owners and Scrum Masters (or their equivalent) and getting our software built incrementally. However, in large enterprises, the development teams, including the Product Owner, are not the ones making the decisions on what is going to be built. They simply manage how the next release will be built. The folks who manage the fiduciary needs of the company need to be part of the process.
This group of people are referred to in Leffingwell’s book as the Program Portfolio Management (PPM) team. They need to understand just enough about their investment options to make a decision on what will get built. A Kanban system using both Business Epics and Architectural Epics for investment decisions outlines how the PPM team can decide which epic should go into the queue next. Using standard Work In Progress (WIP) constraints and an ever-evolving understanding of the epic, the PPM team can move the epic from initial consideration through to the implementation backlog.
Kanban for the PPM team
There are a few great diagrams in the book, and some have been replicated on the SAFe website. The following outlines the Kanban system for a business epic (click for a larger view):
The essential flow is as follows (quoted from the SAFe website):
- Funnel–the capture state, where all ideas are welcome
- Backlog–where preliminary estimates of effort and cost of delay are established
- Analysis–where the work is done to establish technical viability, impact, and availability of resources
- Implementation– where epics are allocated to the release trains that are impacted or that are available with the resources and skills necessary for implementation of that particular epic
This scaled framework really shows us a way to speak to all levels of the enterprise in an agile manner but still reach the same traditional executive investment decisions on what to build and when. Adding a few elements like state transition requirements and WIP constraints prevents the enterprise from moving beyond the capacity of our teams and making the same mistakes of the past. I strongly recommend a read of the whole book, but in particular the sections on moving epics from initial conception all the way down to a release. At that point, our standard release backlog that we’ve all become accustomed to can take over for prioritizing the work items for the next release!
To read more:
- Agile Software Requirements, Dean Leffingwell, 2011: http://scalingsoftwareagilityblog.com/agile-requirements-the-book/
- Scaled Agile Framework (SAFe) website: http://www.scaledagileframework.com/
- Scaling Software Agility blog: http://scalingsoftwareagilityblog.com/
NOTE: Figures reproduced with permission. SAFe and Scaled Agile Framework are trademarks of Leffingwell, LLC.