A Learning Path to Becoming a Disciplined Agile Trainer

This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group.


The path to becoming a Disciplined Agile trainer is still under construction as we continue to add more workshops. Our latest – the Disciplined Agile Value Stream Consultant is the first workshop from a major players that is built on the basis of Flow, Lean, Theory of Constraints, organizational development and human behavior. It uses patterns-thinking to tie these all together.

Many of the concepts in DA’s line are distinct from other approaches. Learning these concepts can help you in what you are doing now and can prepare you for a path to certification if you like.

It is organized as follows:

  • foundational concepts we’ve found to be useful
  • differences between Disciplined Agile and other approaches

I am happy to take questions about any of these pages. If they are Linkedin posts, please tag me in the question so i’ll know you asked it. You can also ask me on the Disciplined Agile Linkedin Group, and again, please tag me so I’ll know to answer.

Foundational concepts we’ve found to be useful

  1. The Business Case for Agility. Agile is often described as iteratively building software in increments. This is a focus on the team and the mechanics of how they work. It is more effective to focus on the reason for being Agile – achieving business agility. Business agility is the ability to deliver highest business value quickly, predictably, sustainably and with high quality. Building software is not our goal, realizing business value is. Software is often a component of this, of course.
  2. Understanding Our Inherent Problem. Most companies manage in an hierarchical fashion. But our work flows across the organization. The hierarchical management of people conflicts with what should bes being managed – the value being added across the value stream. This sets the stage and justification for the dual operating system espoused by Hamel, Denning, Kersten and McCrystal
  3. The Importance of Theory. This is a collection of blogs that discuss why theory is so importan.
  4. Minimum Business Increments.  The MBI is an often missing, but critical piece of Agile development. It creates a bridge between strategy and development.
  5. The dilemma we’re in. Most people need a well defined starting point. But no one-size fits all. This means some sort of customization for the context the organization is in must be made.

You will likely find this page useful Agile Coach (Basic): Coaching Tips

Differences between Disciplined Agile and most other approaches

It is often easier to learn new concepts by placing them in contrast with other, known approaches.  Here are a rew posts on why this is important:

The following are some of the differences between approaches that are useful to know. Note that some of the entries have a second link to other useful information regarding the difference.

Differences in Approach

  1. Difference between offering solutions and teaching how to solve problems
  2. Prescriptions vs Contextualized Prescriptions and Using preset practices vs choosing your way of working
  3. Built simply but difficult to use or built with more complexity but simple to use
  4. PDSA and inspect and adapt
  5. Single and double loop learning
  6. Frameworks vs approaches based on value, principles, patterns and theory
  7. Why the size of an Agile approach is not the issue, its architecture is
  8. Whether you start at the team level or start at the business level

DIfferences in General Concepts

  1. Between MBIs and MVPs
  2. iterations and increments
  3. Scrum Vs Scrum with Lean  Also, the New Scrum Game
  4. Good ScrumBut and Bad ScrumBut and How Scrum Creates ScrumBut and What to Do About It
  5. attending to a framework vs focusing on what you’re trying to achieve

Differences in Practice

  1. implicit vs explicit agreements about workflow
  2. attending to complexity vs using inherent simplicity
  3. calculating cost of delay on MBIs vs features and stories
  4. Planning by first seeing what goes in the iteration/increment and then planning the releases and planning forward from the releases themselves
  5. Flow inside iterations vs Iterations inside Flow