Most agile transformation journeys start with selling the benefits of using agile, followed by an analysis to determine tools and process gaps, then creating a strategic approach and training requirements before finally doing the big kickoff. As we start unmasking existing organization challenges and the obligatory pushback started rolling in from some stakeholders and team members, a consistent theme started to emerge: “We’re not doing pure Agile” or “this is Scrum-but” or “Scrummerfall” or any one of the other Scrum derivations.
Then one day it hit me like a ton of bricks: We’re really not doing pure agile because…we really don’t want to be doing pure agile! With that epiphany, I realize what the problem was: Everyone was focused on wanting to do what they thought was pure agile--at the expense of being agile!
Back in the day, agile projects consisted of collocated teams using index cards to plan and track agile delivery. In this new age of geographically dispersed, follow-the-sun, integrated program teams, we need a different approach. Additionally, agile strategies are being applied throughout the entire software delivery lifecycle, not just development--and often in very complex environments that require far more than a small, co-located