Disciplined Agile Value Stream Consultant Workshop Layout and Study Guide

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.

 

Note by Al Shalloway, creator of the workshops.

Disciplined Agile is currently creating the Disciplined Agile Value Stream Consultant Workshop (DAVSC). This workshop teaches someone to lead organizations to Agile at scale. The second is the DA FLEX Playbook for SAFe and is mostly a subset of the DAVSC for SPCs who want to improve their SAFe implementations.

The core of FLEX is a playbook which provides a list of actions that organizations can take to improve their ability to achieve value quickly.  Interleaved within these plays are the concepts needed to understand them as well as the principles that explain why they work.

This page is not an exact replica of the workshop. It does present a self-study approach to learning much of what’s in the DA VSC.  This content is not guaranteed to remain publicly available.

The Disciplined Agile Value Stream Consultant Workshop

The curriculum of the two workshops is shown blended together. Any section that is unique to just one workshop is marked with DAVSC or SAFe depending upon which track it is unique to. The numbers represent the week content is presented.

  1. The role of the Disciplined Agile Value Stream Consultant
  2. 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.
  3. The Idealized Value Stream of an Effective Organization.  This represents the steps organizations must take to effectively and efficiently create and enhance their products and services
  4. The Disciplined Agile / FLEX Approach for Adoption and Improvement. It’s not start with a framework or figure it out yourself, it’s start with a tailored approach based on patterns of adoption.
  5. 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
  6. <<< what’s after this will be refined soon>>>
  7. The DA Philosophy of change. DA is not a preset solution, but rather a way to improve on an ongoing basis.
  8. Seeing the challenges in your value stream. Participants identify the common challenges in value streams they’ve seen.
  9. Offerings Vs Capabilities (#2)
  10. Minimum Business Increments.  The MBI is an often missing, but critical piece of Agile development. It creates a bridge between strategy and development.
  11. Factors For Effective Value Streams (#3) (instructor notes). Value streams are affected by the batch size of work in them, how people are allocated to them, the workflow of the value stream, the amount of work being done at one point and both the quality and architecture of the product
  12. The Focused Solutions Team is a group of individuals or teams that focus on creating MBIs or MVPs.
  13. Shared Services and Enterprise Architecture as Professional Service Providers.  People providing shared services (e.g., business intelligence) and architects need to be available on a more timely basis than is usually done. This is not difficult to achieve but it requires attention to eliminating delays by increasing collaboration.
  14. Test-First as a Process. The intention of test-first is to get clarity on what it means to be done. It is a collaborative effort across the roles of the customer, developer and tester
  15. DAVSC: Overview of the DA FLEX Playbook.(#4a) Although organizations are unique, they all have to accomplish reasonably similar actions. Understanding what needs to happen is the first step in eventually identifying the specific plays to take for an organization.
  16. What SAFe Provides Us. The Good, the Bad and the Missing. (#4b) SAFe is popular for good reason – it attends to many aspects of an organization that many Agile approaches don’t. However, it doesn’t create an Agile organization on its own for several reasons – mostly the way the framework is architected and its lack of a few key concepts required for business agility.
  17. SAFe From a Value Stream Perspective. SAFe presents itself as a collection of roles, events, actions and rules. While someone who is knowledgeable about the importance of flow can “see” the value stream in SAFe’s big picture, most either cannot or have difficulty in doing so. Viewing SAFe from a value stream perspective both simplifies it and educates the observer in how it works.
  18. The DA FLEX Playbook for SAFe – the what and the why. The intent is to improve the current SAFe implementation and build on what’s been done. This section shows what needs to be done and why. The rest of the workshop is the how.
  19. DAVSC: The development intake process. (#5) It is important that whatever intake process you use it be centered on creating value with the least amount of work required. This requires the USE of MBI which also creates alignment across the value stream.
  20. Planning, Collaboration and Dependency Management (include SAFe improvements). This section illustrates how planning events are really more about collaboration and dependency management than they are about creating plans. Discussing it this way provides insights how to improve SAFe program increment planning event.
  21. DAVSC: Product management as a means of controlling teams backlogs. What teams should work on can be coordinated in a number of ways. Having the teams themselves figure it out is not usually the best method.
  22. How to map your value stream and why it’s so important (#6).  Value stream mapping is one of the key
  23. Turning a Value Stream Map into a Kanban Board (video starting at 6:36).  Value streams take effort to keep up to date – so don’t expect they will be maintained. However, value streams can be represented by Kanban boards which should be used even if you are doing scrum.
  24. Creating Visibility Across the organization.
  25. Create Strategies and Initiatives. Most companies are reasonably good at strategic thinking and creating initiatives from them. But this information and the rationale for it is often not available at lower levels. This disconnect can only be solved by creating a line of sight from strategy threw deployment.
  26. Management’s role, including effecting culture (#7) (include product management, people management, process management)
  27. Systems Thinking, Complexity and Inherent Simplicity. How to See in a Complex World.
  28. The three forces to resolve (#8).  Managing dependencies, removing dependencies, relationships between the groups.
  29. The Dilemma We’re In
  30. DAVSC: Creating an Improvement Backlog
  31. Identify the challenges you have in SAFe 
  32. SAFe: Creating an improvement backlog for SAFe
  33. (#9) Working with a common cadence and synchronization.  This is SAFe’s method and all consultants should know it. However, it’s not the only way to accomplish the objective. After covering this an alternative based on flow will be provided. SPCs will find this both a review and how to improve SAFe’s methods.
  34. Improve cross-functionality of teams. There are several degrees of cross-functionality. Understanding them enables a pragmatic approach to team formation and individual allocation.
  35. Improving your Value Creation Structure. How teams are organized and how people are allocated to them is a major factor in team effectiveness and efficiency. Focus on borrowed team member and FSTs.
  36. SAFe: Shorten Program Increments over time. Three month planning events are longer than they should or need to be. As we decompose trains into dedicated product teams it is possible to have shorter planning events, even moving to a pure flow model in many cases. Introduces idea that ARTs can use PIs while FSTs do monthly coordination with ARTs.
  37. (#10) Agile budgeting, portfolio & product management method aligned around products. This is the “project to product” shift of Mik Kersten that is embraced by SAFe but missing in how to accomplish it. Agile budgeting is easier to accomplish when an organization has a handle on how to define work (MBIs) and how to allocate people to it (FSTs).
  38. (#11) Agile Portfolio Management.  Portfolio management needs to be done from flow’s perspective of lowering cost of delay of value. Using MBIs greatly simplifies this task. For those interested in SAFe, much of the Portfolio and Full levels will be seen to be more complex than necessary because of this lack of focus on value.
  39. (#11) Create a network of semi-autonomous, cross-functional team or groups of teams.  We now put the concepts we’ve learned into how to manifest Stephen Denning’s Law of the Network. This is not merely a group of Agile teams working on their own but how a network of semi-autonomous, self-organizing Agile teams work together to manifest the goals of the organization.
  40. (#11) Promises across the organization. (#11) When undertaking an initiative to improve your organization it is more important to make agreements about how to work together than it is to just agree to follow a framework. These promises provide the guidance, or guardrails, for how people should work together.
  41. (#11) Use Acceptance Test-Driven Development (BDD). Many consider ATDD/BDD a kind of testing. But it’s mostly about creating clarity on what needs to be done. It is not a task only for developers and testers.
  42. (#12) How to effect change in complex systems. (#13).  This provides an overview of the topics on management and affecting change.
  43. (#12) What’s in our way – VUCA, Friction, Complex systems. When trying to effect change it is important to understand what works against us.
  44. (#12) Art of Action Steven Bungay
  45. (#12) How to affect change (Guided continuous improvement)
  46. (#12) Managing Transitions by William Bridges
  47. (#13) Use DevOps. The importance of DevOps is well known. It is not gone into depth here. This topic shows how many can gain value from DevOps just by implementing a few simple agreements between the two groups to improve collaboration and visibility.
  48. (#13) Business Architecture and the role of the Business Architect (#12)
  49. (#13) The Chief Product Owner.
  50. (#13) The DA Program Manager at Scale. This person coordinates the development activities from start to finish. Consider it DA’s equivalent of SAFe’s RTE.
  51. (#13) Metrics.
  52. (#14) Wrap Up.

The following concepts to be introduced throughout the workshop. 

  • Assessment for the business and teams a la Agility Health (currently done in spreadsheets) 
  • Metrics – will be added as we go. 
  • Cheat sheet – summary of the entire process. Get built as we proceed. 
  • References to additional materials.  These will be on portal.netobject
  1. DAVSC: Dynamic Feature Teams. When you have groups of teams totally less than 100 people in development and they usually work on individual features but sometimes have to work together on big ones, creating dynamic feature teams can be very effective. (might be a background).

Background / Parallel Learning

The workshop covers the most essential materials concepts needed. However, it can’t cover everything. Fortunately, conveying much of this information can be done via articles and short videos.  See DAVSC Background and Parallel Learning for more useful information to go deeper into the material covered in this workshop.

Go here to ask questions and/or provide feedback while this workshop is being built.