Wilson Mar bio photo

Wilson Mar

Hello!

Calendar YouTube Github

LinkedIn

Are organizations really more Agile with SAFe?

US (English)   Norsk (Norwegian)   Español (Spanish)   Français (French)   Deutsch (German)   Italiano   Português   Estonian   اَلْعَرَبِيَّةُ (Egypt Arabic)   Napali   中文 (简体) Chinese (Simplified)   日本語 Japanese   한국어 Korean

Overview

This page contains my notes about working with the Scaled Agile Framework for enterprises (or SAFe), which are proven success patterns for implementing Lean-Agile software and systems development at enterprise scale, in the context of using CA Agile Central.

Detractors of SAFe

https://seandexter1.medium.com/beware-safe-the-scaled-agile-framework-for-enterprise-an-unholy-incarnation-of-darkness-bf6819f6943f

Summary

This page also reconciles the use of CA Agile Central for SAFe. The on-line tool was renamed from Rally after CA bought it in 2015. CA offers online classes at https://ondemand.agileu.com

SAFe Version 1.0 was first published in 2011. SAFe V3.0 was released July 28, 2014. The framework’s name was changed in January 2016 to
“SAFe 4.0 for Lean Software and Systems Engineering” on ScaledAgileFramework.com:

v5

v4.5

The full view diagram:
safe4 5-650x455-219544.jpg

v4.5 “Essential SAFe” consists of the bottom two layers named “TEAM” and “PROGRAM”. “Portfolio SAFe” adds the top “PORTFOLIO”. “Large Portfolio SAFe” replaces PORTFOLIO with “LARGE SOLUTION”. “Full SAFe” includes both “PORTFOLIO” and “LARGE SOLUTION”.

v4

There are 3 level and 4 level views. The 4-level view diagram:
safe_4

The 3-level view diagram:
safe v4

v3

safe 3

Changes from v3 to v4 incorporates “Lean” principles and terms.

SAFe Requirements Model

figure-1-safe-requirements-model

Alphabetically

PROTIP: To make sure I’ve clicked through all the positions on the above diagram at http://www.scaledagileframework.com, I made this alpabetical list of links:

  1. About SAFe
  2. Agile Release Train (ART)
  3. Agile Architecture
  4. Agile Team
  5. Architectural Runway
  6. Budgets
  7. Built-In Quality
  8. Business Owners

  9. CapEx and OpEx
  10. Communities of Practice
  11. Coordination (of Value Stream)
  12. Customer

  13. Daily Stand-up (DSU)
  14. DevOps
  15. Develop on Cadence, Release any time
  16. Economic Framework
  17. Enablers (spikes)
  18. Enterprise
  19. Enterprise Architect
  20. Epics
  21. Epic Owners

  22. Features and Capabilities

  23. Inspect and Adapt workshop (using Problem Statement, Fishbone Root Cause Diagram, Pareto Chart)
  24. Innovation and Planning Iteration

  25. Implementing
  26. Implementation Roadmap
  27. Implementation Plan (create it)

  28. Iterations
  29. Iteration Execution
  30. Iteration Goals
  31. Iteration Planning
  32. Iteration Retrospective

  33. Innovation and Planning Iteration
  34. Lean-Agile Center of Excellence
  35. Lean-Agile Mindset
  36. Lean-Agile Leaders

  37. Metrics
  38. Milestones
  39. Model-Based Systems Engineering (MBSE)

  40. Non-Functional Requirements (NFRs)

  41. PI Objectives
  42. PI Planning

  43. Product Owner (PO)
  44. Product and Solution Management

  45. Portfolio Business Epic (items that cross trains)
  46. Portfolio Backlog
  47. Portfolio Kanban
  48. Portfolio Level

  49. Pre and Post PI Planning
  50. Product Management (PM)

  51. Program Backlog
  52. Program Kanban
  53. Program Increment (PI)
  54. Program Level
  55. Program PI Objectives
  56. Program Portfolio Management (PPM)

  57. Refactoring
  58. Release
  59. Release Any Time
  60. Release Train Engineer
  61. Release
  62. Release Management
  63. Roadmap

  64. SAFe Core Values
  65. SAFe Lean-Agile Principles
  66. SAFe Requirements Model
  67. Scrum Master
  68. ScrumXP
  69. Shared Services

  70. Solution
  71. Solution Architect/Engineering
  72. Solution Context
  73. Solution Demo
  74. Solution Intent
  75. Solution Management

  76. Spanning Palette
  77. Spikes
  78. Strategic Themes
  79. Stories

  80. Supplier
  81. System Architect/Engineering
  82. System Demo of all accumulated features to customer representatives.
  83. System Team

  84. Team Backlog
  85. Team Demo
  86. Team Kanban
  87. Team Level
  88. Team PI Objectives
  89. Test First

  90. User Experience (UX)

  91. Value Streams
  92. Value Stream Backlog
  93. Value Stream Coordination
  94. Value Stream Engineer
  95. Value Stream Epics
  96. Value Stream Kanban
  97. Value Stream Level
  98. Value Stream PI Objectives

  99. Vision
  100. Weighted Shortest Job First (WSJF)

    A quote is offered in each abstract above.

    The Rally / CA Agile Central tool adds these concepts:

  101. A defect suite groups defects together
  102. Work items refer to Tasks
  103. Work Product

  104. Rank among items in lists
  105. Expedite flag
  106. Test Sets
  107. Test Case (TC)
  108. Changesets
  109. Tags
  110. Dependencies of Task Predecessors and Successors
  111. Flows (CA Flowdock)

    There are so many concepts in the framework because it incorporates concepts from many others (Deming, Ishikawa, Agile, Scrum, XP, Lean, Kanban, Systems Thinking, etc.).

    Projects in CA

    PROTIP: The word “project” is absent from the SAFEe vocabulary. In many ways, the Project Management Institute’s frameworks lost out because of its temporary focus (the definition of “project”) vs. SAFEe’s implicit assumption of continuing permanance.

  112. Each “Workspace” holds projects for each organization in CA Agile Central.
  113. QUESTION: Project in CA is “Capability” in SAFe, such as “Shopping website” and “Shopping team”.

    Change Management in CA

    The Rally / CA Agile Central tool adds change management fields:

  114. Affected Customers
  115. Affects Doc
  116. Attachments
  117. Change Author
  118. Closed Date
  119. Creation Date
  120. In Progress Date
  121. Watches for specific work items
  122. Requests

    PROTIP: Standardize abbreviations to avoid confusion while making more content in item descriptions.

    PROTIP: Memorize the acronyms (in parentheses) using my Quizlet of flash cards. Click on the term’s text for it to be pronounced out loud. Click above a term to see its definition (and visa versa). Click the star to mark ones you want to see again. Click the right button for the next flash card.

Competitors

A competitor to SAFe is Daikibo (“large scale” in Japanese), trademarked by Cognizant consultants. Xavier Morera has a video tutorial on it on Pluralsight.

QUIZ: Does the Product Owner size backlog items along with delivery team members?
No.

I think part of the reason for the success of the SAFe framework is that it directs the work of many roles in the organization, not just to only developers or only quality assurance people or only project managers, etc.

SAFe recommends training in their Implementation Roadmap:
implementation-roadmap-v25-current-3

But here is another:

agile rollout schedule 516x236

Miraculous results?

Several case studies and the About page claim significant improvements:

  • 20 – 50% increase in productivity
  • 50%+ increases in quality
  • 30 – 75% faster time to market
  • Measurable increases in employee engagement and job satisfaction (Happier, more motivated employees)

Introductions to the framework by Dean Leffingwell, in several media:

Guidance Articles

Cadence (timing)

An Agile Release Train (ART) provides architectural, engineering, and User Experience guidance to help teams build systems that support current and upcoming user and business needs. Each ART is a long-lived, self-organizing team of Agile Teams, a virtual organization (5 – 12 teams) that plan, commit, and execute together to a single Vision, Roadmap, and Program Backlog.

Individual Agile Teams typically consist of 5-9 people who work in Program Increments (PIs) of 10 weeks consisting of 5 two-week sprints to release deployments of finished deliverables to customers.

There are also System Teams that provide enablement.

The mid-range planning timebox contains releases of 3-months each.

“Develop on Cadence, Release Any Time.”

CA’s tutorial (at [0:23]) recommends estimating 6 hours per regular day from each team member.

CA provides horizontal swimlanes to highlight tasks marked expedite.

Status

CA’s Kanban Board has these default columns of task Kanban states:

  1. Backlog
  2. On Deck
  3. Ready to Pull
  4. Test Planning in Team Kanban
  5. Building (In Dev in Team Kanban)
  6. In Testing in Team Kanban
  7. Accepted
  8. Released

WIP limit limits how much work in each state.

In CA’s Personal Work Burndown Chart, blue columns of ToDo’s vs. green columns of Accepted items «strong>remaining</strong> at the end of each day:
agile-central burndown chart 519x428

The Burn-up Chart CA defines as “work delivered (completed) during the release – to proactively anticipate whether the release scope will be delivered”. The black line shows total work planned.

There are also burn-up and burndown charts by Story, Iteration Scope, and Release.

BLAH: Do new items added during each day get highlighted in the Chart? Not in CA.

CA’s Defect Repair Work board (by Team) has these statuses:

  1. Submitted
  2. Open
  3. Fixed
  4. Closed

ANALOGY: “Points” within the context of one Agile team or project are like airline points. Points for one airline don’t have the same value with another airline.

CA’s Velocity Chart displays the baseline estimate of how many points planned for each iteration within a release:

agile-central velocity report 1078x496

CA does not project into the future.

QUESTION: Why is “Not Accepted” included in an iteration bar?

Levels Backlog

PROTIP: The hierarchy of levels (Team, Program, Value Stream, and Portfolio):

  1. Portfolio Backlog (within the largest of businesses) of Business and Enabler Epics in the Portfolio Kanban addressing Strategic Themes connected to the Enterprise Business Strategy.

  2. Value Stream Backlog (for larger organizations)

  3. Program Backlog containing features and capabilities.

  4. Team Backlog contain tasks.

  5. Defects

QUIZ: Is there a Product Backlog with User Stories?
No.

QUIZ: Are Tasks a backlog item?
No.

The top level labeled “Economic” for organizations over a 100 people.

Blocked status shows up in CA Agile Central Pie Charts but not in the Cumulative chart.

agile-central cumulative chart 650x603

Tracking Hierarchies

The different hierarchies can be confusing.

CA’s Track menu, where many use within CA Agile Central, has a hierachy of status by Iteration, Team, Release, and Work Product:

agile-central delivery list track menu 154x166

CA’s Iteration status board has these statuses: agile-central status state icons 152x402

  1. Idea
  2. Defined
  3. P = In-Progress
  4. Completed
  5. Accepted

The above statuses also appear as individual icons in Test Case status views for each Release.

However, where does one go in CA Agile Central to see the Roadmap status illustrated by this conceptual Venn diagram from a CA tutorial, which shows each Day within a Sprint within a Release within a Product Roadmap within a Product Vision:

agile hierarchy ca-rally 650x389

Alternately, this conceptual hierarchy shows Tasks within one-week Stories within multi-week Stories (Epics) under a Portfolio feature under a Portfolio initiative:

agile hierarchy ca-rally 650x461

CA’s Notification Rules can be to these Work Product Types:

agile-center notification select 516x234

Quality

Clicking “Quality” in CA’s menu reveals the Test Plan.

I think CA’s menu should say “Testing” instead of “Quality” because Quality encompasses more than just testing.

agile-central quality menu 266x258

CA sells a Quality Center module to support regression testing.

Types of tests supported:

agile-central test case type 322x168

Due to the volume of testing data, organizations should access the system via an REST API

  • https://help.rallydev.com/github

CA’s Defect Summary Matrix of status vs. priority for each Release:

agile-central release defect matrix 614x278

Quality metrics

From Mark Richards https://t.co/Jrn218N0D5

safe v4 quality metrics

Principals

The Foundation layer include: Lean-Agile Leaders, Communities of Practice, Core Values, Lean-Agile Mindset, and Principles.

agile-lean-vs-traditional

http://www.scaledagileframework.com/safe-lean-agile-principles/

agile-principles-team-adoption

  1. Take an economic view

    Measure EMV. incremental value delivery. shortest time.

  2. Apply systems thinking (complex interactions)

    It’s a systems problem, not a people problem.

  3. Assume variability; preserve options (cone of uncertainty)

  4. Build incrementally with fast, integrated learning cycles
  5. Base milestones on objective evaluation of working systems
  6. Visualize and limit WIP, reduce batch sizes, and manage queue lengths
  7. Apply cadence (timing), synchronize with cross-domain planning
  8. Unlock the intrinsic motivation of knowledge workers
  9. Decentralize decision-making

TODO: agile-lean-vs-traditional.png

Planning

http://cloud.huit.harvard.edu/files/hcs/files/iam_and_safe.pdf

v4 inserted a Value Train for large enterprises.

Definition of Done (DoD)

Capabilities are split into features to be implemented. Featuresmare split into stories for implementation by teams.

Teams

In SAFe, a Systems Team is a specialised team responsible for maintaining the development environment used by Agile development Teams and for end-to-end solutions testing.

PROTIP: SAFe does not address directly how people get bonuses and raises, which can have major impact.

Dashboards for different roles are reached in CA Agile Central’s home icon:
agile-central dashboards 400x245

Communities of Practice (CoPs) aka guilds are different than Centers of Excellence (CoE).
A CoE is group of people with specialized skills and expertise whose job is to provide leadership and purposely disseminate knowledge within organizations. *
A COP is a collection of people who share a craft or profession who have banded together to learn from each other to develop themselves (and the organization).

Deloitte

Even when enlarged to full page, Deliott’s Agile Landscape is too small to read
agile landscape deloitte</a>

It mentions Cynefin for making sense of complexity.

Social Media

Scaled Agile’s Community Platform

Videos

ITMPI.org (IT Metrics and Productivity Institute) by Al Shalloway

[1:53] “The nature of work is not top down.” Usually no one is managing (measuring) work waiting. Waiting creates extra work, waste.

  • https://plus.google.com/u/0/112759785983081879416

iZenBridge Consultancy Pvt Ltd

  • https://www.youtube.com/watch?v=ogb1KT9ek34 Introduction of Scale Agile Framework (SAFe)

Lean Samurai

  • https://www.youtube.com/watch?v=RXzurBazN-I in 7 minutes

Other Information

https://en.wikipedia.org/wiki/Scaled_Agile_Framework

  • https://www.youtube.com/watch?v=RLBReQXQcvY in 8 slides
  • https://www.youtube.com/watch?v=-744CZ3V1E0
  • https://www.youtube.com/watch?v=TolNkqyvieE

  • https://www.youtube.com/watch?v=V71bGAxGAd8