One of the seven principles behind the Disciplined Agile (DA) framework is Pragmatism. People are often surprised when we suggest that mainstream methods such as Scrum and Extreme Programming (XP) are prescriptive. But they are indeed. Scrum prescribes a daily stand-up meeting (Scrum) no longer than fifteen minutes to which all team members must attend, that teams must have a retrospective at the end of each iteration (Sprint), and that team size should not be more than nine people. Extreme Programming mandates pair programming (two people sharing one keyboard) and Test-Driven Development (TDD). We are not suggesting that prescription is a bad thing, we’re merely stating that it does exist. Many agilists are quite fanatical about following specific methods strictly. In fact, we have met many who say that to “do agile right” you need to have 5-9 people in a room, with the business (Product Owner) present at all times. The team should not be disturbed by people outside the team, and should be 100% dedicated to the project. However, in many established enterprises such ideal conditions rarely exist. The reality is that we have to deal with many suboptimal situations, such as distributed teams, large team sizes, outsourcing, multiple team coordination, and part-time availability of stakeholders.
The DA framework recognizes these realities and rather than saying “we can’t be agile” in these situations we instead say “let’s be as effective as we can be.” Instead of prescribing “best practices” DA instead provides strategies for maximizing the benefits of agile despite certain necessary compromises being made. As such, DA is pragmatic, not purist in its guidance – DA provides guardrails helping you to make better process choices, not strict rules that may not even be applicable given the context that you face.
This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.