A few weeks ago one of my customers asked me for advice about daily standup meetings (also called Scrum meetings, morning meetings, or better yet coordination meetings). Her feeling was that her teams could become more disciplined in their approach to coordination meetings so she asked if it would be possible to see how teams in other companies run their meetings. I indicated that there are a lot of good videos on YouTube and that I would write something up soon in a blog posting. So here goes.
Here’s a few interesting videos that I found on YouTube:
A few people have commented that Disciplined Agile Delivery (DAD) promotes a wide range of practices, which they like because it makes their options explicit but which they also potentially dislike because there’s so many practices to choose from. This then leads to the question of why do we need so many practices? First, there are a lot of practices out there to begin with and our philosophy is to help people know that they have options and help them to select the right ones. Second, our experience is that for a practice to be easily consumable it should be:
Practices that are small, cohesive, and loosely coupled are easier to configure into more interesting solutions. For example, the practice of test-first programming (TFP) is combined with refactoring to form test-driven development (TDD). The practice of (writing) executable specifications can be combined with TDD, or TFP for that matter, to give you behavior driven development (BDD) or acceptance test-driven development (ATDD). The combination of iteration modeling, model storming, look-ahead modeling, and BDD can give you a strategy for addressing emergent requirements and design during an iteration.
Of these three aspects, we’ve found that coupling has the greatest impact on your ability to tailor your approach to meet the unique situation you find yourself in. Just like highly coupled software is difficult to maintain and enhance, processes built from highly-coupled practices are too. For example, consider the way that Scrum describes product backlogs. A product backlog is one of several strategies that agile teams may use to manage their work. In the case of Scrum, the strategy is to prioritize requirements by business value and then focus on implementing the highest priority work at all times. Unfortunately Scrum has coupled many important practices to the product backlog concept. For example, initial requirements modeling is often referred to as populating the backlog. Prioritization of new requirements and exploring upcoming requirements is referred to as grooming the backlog. There are several potential problems to consider:
In conclusion, we have found that adopting small, cohesive, and loosely coupled practices enables you to adopt and tailor a process strategy that better reflects the context of the situation that you face. Not only is high cohesion and loose coupling great strategies for software, their great strategies for software process too.