From my vantage point, I see more and more companies adopting Agile methods (some perhaps to jump on the bandwagon du jour). So, now there’s an increasing group of experts who have been seasoned through real-life experiences on Agile projects at these companies. Companies like Capital One, DTE Energy, BMC Software, Kronos, Google, Yahoo, Siemens, and British Telecom have had multiple years of experience implementing Scrum and/or other Agile methods. Whole communities of experts have built up in recent years around these implementations. I’m keenly interested in how the basic Agile model is evolving with this growth. Certainly, as experts in these communities applied Agile practices they would have needed to adapt them to deal with the myriad challenges that exist in large companies. My own solution when faced with complex issues on Agile projects, is to fall back on Agile principles. In addition, having the Declaration of Inter-dependence helps to better clarify how to act. Then, creating a customized, situation specific solution that evolves the basic practices while still staying true to the underlying principles is possible. Time for some specifics?
Earlier this month, I was invited to speak at the Seattle chapter of the Agile Project Leadership Network (APLN). I chose to share my thoughts on how my own Agile model has been evolving to meet the challenges on complex, multi-project environments.
Many years ago, I read E.F Schumacher’s book, Small is Beautiful. Recently, I came across it again and figured that its central thought serves as a great metaphor for us in the business world, and also within the Agile community. Schumacher proposed the idea of smallness within bigness as a decentralized, eco-friendly, sustainable business model. For a large organization to work, he postulated, it must behave like a related group of small organizations.
For instance, the basic Agile team model is a small team with 7+-2 people. One way a project team can grow large while staying small, or preserve the Agile smallness within bigness, is by building the “whole” into the “parts.” A small seed group breaks off from the original team to form its core. This core group, typically a manager, lead developer and business analyst, ensures that the agile team vision and culture are propagated intact to the new team. A light Lean-Agile PMO can be used to coordinate and support related activities between the teams. I’ve helped implement this quite a few times. Here’s a paper titled, Agile Project Management: Steering from the Edges that I co-authored that outlines one of the case studies. An abbreviated version of this paper was published by the Communications of the ACM in December of 2005.
Managers within a Lean-Agile PMO apply Lean principles at the program and portfolio level. For example, they can cap Work-in-Process(WIP) by limiting the number of projects in flight. This is a simple yet incredibly powerful way to reduce portfolio waste and to significantly improve project throughput or time-to-market.
In the APLN session, I spoke about small teams and small batches, and how these key Agile concepts can be evolved using Schumacher’s smallness within bigness theme. Here’s the presentation: Small is Beautiful: The Evolution of Agile to Complex, Multi-Project Environments. More details on the content of the presentation will follow in a future post.
