I’m happy to announce that the Disciplined Agile Consortium (DAC) is now working with SEMAT. SEMAT, Software Engineering Method and Theory, is an international community of people, companies, and universities. Led by Ivar Jacobson, SEMAT is working together to create a common ground, or kernel, for software engineering. As you may know I am one of the original signatories who first indicated their support for the SEMAT effort and am currently a member of the SEMAT advisory board.
So why are we working with SEMAT? We hope to gain several benefits:
- Share DA concepts more widely. We intend to work together to essentialize some of the key concepts that are unique within the Disciplined Agile (DA) framework. This will help to get our leading-edge material into the hands of more people.
- Leverage essentialized practices. The SEMAT community has already captured, what they refer to as essentialization of, a wide variety of great practices such as TDD, continuous integration, coordination meetings, and so on. Our approach in DA is to put such practices into context but not to go into detail describing them (instead we reference existing descriptions). So, SEMAT provides DA with a great source of existing material to reference.
- Collaborate with the SEMAT community. There are many practitioners, trainers, and researchers within the SEMAT community and it’s always a great idea to work with smart people!
- Enable our customers. A big advantage with SEMAT is that they’ve published, and continue to publish, a lot of great process material. This is exactly the type of material that organizations need to support the learning activities of their staff as well as their own process definition efforts.
Of course it is still early days and there is a lot to do. Please stay tuned here for further updates!
I recently wrote a detailed article about process tailoring workshops. In a process tailoring workshop a coach or team lead walks the team through important aspects of the delivery process and the team discusses how they’re going to work together. This typically includes choosing a lifecycle, walking through the process goals one at a time and addressing the decision points of each one, and discussing roles and responsibilities.
There are several reasons why you want to tailor your team’s process:
- Every team is unique and faces a unique situation.
- You want to have a common vision as to how you’re going to work together.
- You want to streamline how you work together.
- You may actually need to document your process.
The article covers the following topics in detail:
- Why process tailoring?
- When do you run process tailoring workshops?
- The risks associated with process tailoring workshops
- Planning a process tailoring workshop
- What should you tailor?
- Running a process tailoring workshop
- Documenting the results
I hope you find it useful.
This brief article explains our thinking around our terminology choices in the Disciplined Agile (DA) framework. It overviews the terminology principles that we follow, discusses why Scrum terminology isn’t appropriate, and maps common Scrum terms to DA terms.
Our Principles Around Terminology
The following three principles drive our terminology decisions:
- Terms must be clear. If you need to explain the term, it likely isn’t the best. For example, how many times have you had to explain what a Scrum meeting is? Call it a coordination meeting instead, and people have a much better idea of what’s going on.
- Terms must be method neutral. Every team is unique and owns its own process. Part of owning your process is choosing the overall method, or lifecycle, that you’re following. Because the DA framework is a hybrid that leverages a variety of methods, were we to adopt one method’s terminology over another it would only make sense for people following that lifecycle. For example, Scrum terminology makes sense if you’re following the Scrum-based Agile/Basic lifecycle but not the Lean Continuous Delivery lifecycle.
- Terms should already be in use elsewhere. We are not in the business of creating new terms when existing ones are perfectly fine.
The Problem with Scrum Terminology
Many people ask us why we don’t simply use Scrum terminology. We originally wanted to, because that would be the easy thing to do, but we quickly realized that Scrum terminology just doesn’t get the job done for three reasons:
- It doesn’t apply in all situations. For example, the term “sprint retrospective” doesn’t really make sense when you’re following a lean lifecycle that doesn’t have the concept of sprints/iterations. Furthermore, it breaks principle #3 above in that the Scrum folks tacked “sprint “onto the front of the existing term “retrospective” to brand it with Scrum marketing.
- It was motivated by marketing reasons. The Scrum originators purposely chose unusual terms such as sprint, Scrum Master (later concatenated to ScrumMaster), and Scrum meeting to signal to people that Scrum was different. Well, in DA we’re purposely choosing pragmatic terminology to signal to people that it’s time to up our game as software professionals.
- It reflects 1990s thinking. There’s nothing wrong with that per se, other than the fact that we have learned a lot the following decades that we can apply.
Mapping Scrum to Disciplined Agile Terms
The following table maps common Scrum terms to the terms that we prefer in DA. As you can see, the mapping is very straightforward.
- “Modeling” is common IT terminology.
- “Look-ahead modeling” is an existing Agile Modeling practice
- Not all teams have backlogs.
- The term isn’t clear (one reason why it evolved from backlog grooming to backlog refinement a few years ago)
- Agilists really need to get over their cultural issues around modeling and documentation
- There is a wealth of material about effective modeling strategies that many agilists are unaware of because they search on terms such as mapping or grooming instead of modeling
- Only Scrum teams have Scrum Masters
- The term “Scrum Master” isn’t descriptive of what someone in that role does
- The responsibilities of a Team Lead are a bit more robust than those of a Scrum Master, so this mapping isn’t perfect
- Coordination meeting is a much clearer term
- Iteration is used as a term in XP, Agile Modeling, Unified Process and many others
- The term sprint is ok, but it doesn’t reflect the agile principle of maintaining a steady pace (you don’t sprint through a long race)
- You can hold a demo at any time, not just at the end of a sprint
- Original term for the technique
- You can hold a retrospective at any time, not just at the end of a sprint
There is no standard terminology in the agile world, nor will their ever be. Your team, as part of owning your process, will need to decide which terms they prefer to use. We’ve seen many DA teams choose to use Scrum terminology (e.g. sprint instead of iteration) because they originally started with Scrum and that’s what they’re familiar with. That’s their decision and as always our advice is for a team to do what they believe to be right for the situation that they find themselves in.