Summary content for the SAFe 4 Agilist Certification
Below content is a compilation made based on the content of the training course Leading SAFe 4.5, pre-requisite to take the SAFe Agilist certification.
Experience preparing for the SAFe Agilist 4 Certification.
Let me quickly share my experience preparing for the SAF3 Agilist 4 Certification.
First thing is to take the mandatory training of 2 days. After that, I created this summary in around 5h or review and study. Then I took the 'practice test' available in SAFe site. As I got a passing score on the practice test, I automatically took the 'official exam' and also passed.
Sounded easy, right? But I would say it actually is. If you are familiar with SAFe methodology and attended the course (paying attention to it), a quick review (maybe using below content) should suffice for you to pass on the Exam.
Good luck!
Chapter 1 - Introducing the Scaled Agile Framework
"Only management can change the system" - Deming
Essential SAFe provides the basis for success:
- Lean-Agile Principles
- Real Agile Teams and Trains
- Cadence and Synchronization
- PI Planning
- DeOps and Releasability
- System Demo
- Inspect and Adapt
- IP Iteration
- Architectural Runway
- Lean-Agile Leadership
Nothing can beat an Agile team...
- Cross-functional, self organizing
- Applied SW Engineering practices (Kanban, Scrum, XP, etc)
- Delivering value every 2 week
Except a team of Agile teams
- Operates with Vision, Architecture and UX guidance
- Common iteration lengths and estimating
- Face-to-face planning for collaboration, alignment and adaptation
Implementation Roadmap
- Tipping point (clear need of a change)
- Train Lean-Agile Change Agents
- Train Executives, Mgrs and Leaders,
- Identify Value-Streams and ARTs
- Create Implementation plan
- Prepare for ART Launch
- Train teams & Launch ART
- Coach ART Execution
- Launch more ARTs and Value Streams
- Extend to the Portfolio
- Sustain and Improve
Chapter 2 - Embracing a Lean-Agile Mindset
SAFe House of Lean
"There is only one boss: the customer. And he can fire everybody in the company." - Sam Walton.
Customer delight
People do all the work. IT is a people business. Build long lasting relationships and partnerships based on trust.
Avoid Start-Stop-Start project delays. Integrate frequently.
Innovation comes from the Gemba. "Get out of the office". Provide time and space for creativity and Pivot without mercy or guilt.
Keep a constant sense of danger. Optimize the whole, not the bottleneck.
People are already doing their best, the problems are with the system. Decentralize decision-making. Inspire and aligh with mission.
Agile Manifesto
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
While there is value on items on the right, we value the items on the left more.
Chapter 3 - Understanding SAFe Principles
#1 Take an economic view
Deliver value incrementally. Early delivery has higher value.
Base decisions on economics: Cycle time, Product Cost, Value, Development Expense, Risk.
Do not consider money already spent. If you should have only one metric, use Cost of Delay (CoD)
#2 Apply system thinking
Optimize the whole, not individual components. The bottleneck will always change.
Reducing delays is the fastest way to reduce time to market.
It embraces identifying the Systems in the Process, which includes the Solution itself and the Enterprise building that system
#3 Assume variability; preserve options
Requirements must be flexible to allow multiple options/choices
Keep options as long as possible, as feedback is collected during the process, some options might become invalid and therefore too costly to adjust.
#4 Build incrementally with fast, integrated learning cycles
Fail fast, and move on.
Short feedback loops allow faster improvements
And with often integration, risk is reduced
#5 Base milestones on objective evaluation of working systems
There is no value on having several internal Phase Gate reviews all approved, but no actual code deployed/tested. Once app is visualized, it is not what customer wanted.
So, milestones must be relevant.
System Demo during PI are orchestrated to deliver objective progress, product and process metrics.
#6 Visualize and limit WIP, reduce batch sizes and manage queue lengths
Use information radiators
Stop starting and start ending.
Instead of starting multiple Stories, Dev can help QE to finish testing on in-progress ones.
Small batches provides lower variability on results.
Transaction cost (DevOps and how difficult it is to deploy) vs Holding cost (how long I need to 'keep it' until deploying it?)
Shorter queue lengths decrease wait time.
#7 Apply cadence, synchronize with cross-domain planning
Cadence creates predictable events and lowers cost.
Waiting time for new work turns predictable
Limits batch sizes to a single interval
Control injection of new scope
Synchronization ensures all teams and layers go on the same cadenced events at the same time
This facilitates cross-segment trade-offs
#8 Unlock the intrinsic motivation of knowledge workers
Autonomy -> Mastery -> Purpose
#9 Decentralize decision-making
Centralize infrequent, long lasting and significant economies at scale decisions.
Decentralize the rest
Chapter 4 - Creating High-Performing Teams and Programs
Form Cross Functional Agile Teams
Value doesn't flow in silos: handoff, delays, political boundaries, etc... all impact value delivery
Plan -> Team and Standup -> Review -> Retro
Scrum Master
- Coach the Agile team and facilitate team meetings
- Removes impediments and protects team from outside influence
- Attends Scrum of Scrum meetings
Product Owner
- Defines and accepts stories
- Acts as the Customer for Development questions
- Work with Product Management to plan Program Increments
Development Team
- Create and refine user Stories and Acceptance Criteria
- Define/Build/Test/Deliver Stories
- Develop and commit to team PI objectives and iteration plans
Organize Agile Release Trains for the flow of value
Virtual organization of 5 to 12 teams (50 to 125+ members)
Synchronized on a common cadence (PI)
Aligned to a common mission (same Program Backlog)
- Continuous Exploration
- Continuous Integration
- Continuous Deployment
Program Roles
- RTE
- Product Management
- System Architect/Engineer
- System Team
- Business owners
Chapter 5 - Experiencing PI Planning
Cadence-Based PI Planning meetings are the pacemaker of the Agile Enterprise
Input: Vision and top 10 Features
Output: Team and Program PI Objectives and program board.
Objectives might be linked directly to a feature, or to a grouping of features. And they might need an enabler feature to support it.
Stretched goals count on Velocity/Capacity, but not in commitment. When an item has many unknowns, consider moving to Stretched goals.
Story Points should consider the 4 variables. It is a whole team exercise to create shared commitment.
- Volume: how much is there?
- Complexity: how hard is it?
- Knowledge: what do we know?
- Uncertainty: what's not known?
First draft plans & risks are presented in first day.
Management meet after to review what actions need to be done to adjust the plan: what did we just learn? Where do we need to adjust Vision? Scope? Resource? Where are the bottlenecks? What features must be de-scoped?
By next day, team incorporate possible changes from management and create the
final plans. They could be change in Business Priorities, Changes to Scope, Movement of People, etc.
They are presented and Business Owners should accept it. If not, teams continue to refactor and review until they are done.
Last step is to address the remaining Risks and Issues brought during discussions.
ROAMing risks: resolved, Owned, Accepted, Mitigated
Confidence Vote (1 to 5) at Team and Program Levels. If 1 or 2 is voted, person need to speak out and explain why. Average above 3 is enough to approve the plan.
Team is committing to do everything in their power to deliver the agreed objectives.
PI Plan Retrospective
What went well?
What didn't?
What we can do better next time?
Action items must be included in the Program Backlog.
RTE Take Away by consolidating the Objectives of each teams (with its assigned business value) and then creating a summary of the PI Objectives.
Chapter 6 - Exploring, Executing and Releasing Value
Continuous Exploration, Continuous Integration, Continuous Deployment
This is the mantra of the ART
To manage Continuous Delivery, team uses Program Kanban. Product Manager is the owner of it.
Features are passing through a funnel, where they are progressing to each stage:
Funnel -> Analyzing -> Backlog -> Implementing -> Validating on Staging -> Deploying to Prod -> Releasing -> Done
Features in Backlog are the ones Ready for the next PI.
ART Sync is used to coordinate dependencies among the sync meetings.
Scrum of Scrum
- Visibility into progress and impediments: it can replan based on
- RTE facilitates, SM joins, with other selected team members and SMEs if needed
- Weekly or more often (if needed)
- Time-boxed to 30 to 60min and followed by a Meet After
PO Sync
- Visibility into Progress, Scope and Priority Adjustments: review impacts in case a Story is not delivered. If impacts only two teams, Meet After with them only.
- RTE or PM facilitates. PMs, POs and Other stakeholders join
- Weekly or more often (if needed)
- Time-boxed to 30 to 60min and followed by a Meet After
Continuous Exploration
He really ensures that what was requested really makes sense, instead of just do what was requested.
Always in collaboration with Sys Arch, Biz Owner, Teams & PO, Customer
Also, goes in events and fairs, stays tuned to market researches, do benchmark with other companies (from related segments), break paradigms.
Vision inspires Action
Think as it would be receiving a post-card from the future, describing his program.
It can put perspective by spreading the Features along the year roadmap.
Important: roadmap is not a commitment. Only the current PI is a commitment. Otherwise it would become a queue and any new work would have to go to last position.
Features must have a Benefit Hypothesis & Acceptance Criteria
The more info, the better. Team must understand why that feature is being developed and what value (benefit hypothesis) it will bring in case it gets delivered.
MBI <> EPICS <> FEATURES <> STORIES
Prioritize the features (in Program Backlog) for Optimal ROI.
Consider two variables. But use CoD if you have to pick one.
- Cost of Delay
- Cost to Implement
Use Weighted Shortest Job First to prioritize
WSJF = CoD / Duration
CoD is made up by:
- User and Customer Value (they prefer this over that; Revenue impact; potential penalty)
- Time Criticality (How user/biz value decay over time)
- Risk Reduction & Opportunity Enablement (what else does this do to our biz?)
Calculate WSJF using relative estimating. Each column must be at least an '1'. Use Fibonaci.
Use Job Size as a proxy for Duration (calendar, delays, handoffs, botlenecks, etc)
Continuous Integration
Integrate every vertical slice of a User Story
Avoid physical branching for Software
Frequently integrate
Use development by intention in case of inter-team dependencies: develop first the interface and integrate, then add the functionality
System Demo made every two weeks. PM demonstrates to Biz Owners (after he received the team's demos).
Built-in Quality: Crappy code doesn't scale.
Include practices in your development, otherwise you can scale:
- Every increment of the solution has quality standards: required for high sustainable development velocity
- Continuous integration, test first, automate tests, pair-work, collective ownership and more
Architecture Run Way
Include enablers in middle of your PI, it will allow future features to flourish.
Don't waterfall the iterations! (where in first Iteration you define, next one you build, third you test)
You need to do it altogether in the same iteration.
What is DevOps?
It is a capability of every Agile Release Train.
Development creates instability by introducing new features; Operations create stability and enhance services.
Automate the continuous delivery. Small batch sizes. Metrics. Recovery automatic in case of issues. Provide confidence to the team to break things and move on.
Continuous Deployment (but Release on Demand )
Decouple deployment from Releasing: Deploy anywhere; Release to Prod;
Releasing usually involves more work (documentation, approvals, user notifications, etc...)
Innovation and Planning Iteration
Saved time for Innovation (otherwise nobody will innovate and will only work on urgent things)
Inspect and Adapt: try to calculate the business value assigned when those stories were included in the PI Board...
System Demo
Led by the PM and POs and presented to BOs, RTE, Stakeholders, Team, SM, everyone. Working software.
Performance reporting: compare business objectives delivered vs planned by each team. Check how teams are performing during the Program Iterations.
Problem Solving Workshop
Teams agreed in the problem and brainstorm to find a possible solution. Included in backlog once defined.
Chapter 7 - Leading the Lean-Agile Enterprise
Transformational leadership: leaders inspire and motivate followers to achieve higher performance
Four Dimensions:
- Vision: Articulate a clear vision and intent. Minimize Constraints. Inspire Passion and Motivation to Achieve Goals. Drive organizational alignment
- Authenticity: Be a role model; Integrity always; Lifelong Learner; Trust & Respect with Transparency;
- Growth: personalized support, coaching and encouragement; keep communication lines open; direct individual recognition; build an environment of mutual influence;
- Innovation: challenge status quo; encourage innovation thinking and failure as a learning; embrace uncertainty;
Principle of a mission: specify the end state, its purpose, and the minimal possible constraints.
knowledge workers: know more of their work than their leaders.
Leadership styles:
- Leader as Expert:
- He is the best in that position; knows everything; go-to guy in the team; work is when people leave him alone;
- Limits learning of others (because they come for him); Focus on technical aspects in detriment to human factors
- Leader as Conductor:
- Central decision maker; orchestrates all individuals to work; subtle manipulator; work is coordinating others;
- Use systems and process to control the work; conflict tend to arise for him to resolve (he coordinates everything)
- Leader as Developer of People
- Creates a team jointly responsible for success; How can we solve this problem and also develop people? work is developing others
- Benefits: increase teams responsibility, engagement, motivation; there is no limit to power of getting things done;
Chapter 8 - Empowering a Lean Portfolio
- Strategy & Investment Funding: connect portfolio to enterprise strategy; fund value streams; establish portfolio flow;
Define Strategic Themes. They are differentiating, specific and itemized business objectives that connect a portfolio to the strategy of the enterprise
Assist in Epic evaluation as they are the 'theme' behind the strategy
The Themes might not be related to IT for the company.
Don't do...
Cost-Center Budgeting: any project will require collaboration of several cost-centers (to provide resource). Slow projects, low program trouput
On its turn, Projects leads to Cost of Delay. Initial estimate is exceeded, who to blame for that excess? How to justify? Why did it happen?
Instead, Fund Value Streams
It is a sequence of steps used to deliver value to the customer. It contains all the people, processes involved on doing the work to deliver the value
With value streams, no blame game for delays. And increased flexibility to select/replace features that will be delivered (in case they have high ROI)
EPIC is something new, substantial in scope that warrant analysis, ROI, lightweight business case and approval. It can cut across Value Streams.
Program Epics are implemented by one single ART;
Portfolio Epics can be implemented by several ARTs;
Portfolio Kanban brings control over the Portfolio demands coming to the ARTs.
Follow the flow and don't treat it as a queue (remember the wait time and pre-commitment)
- Agile Portfolio Operations: Supports Agile PMO; Enable the flow of value via coordinating the value streams;
- Lean Governance: Forecast and budget dynamically (instead of committed for an year); measure lean portfolio compliance;
Forecast needs estimate of effort of work. Usually System Architects will break the Epics in Features and use Stories Points to size them
Adjust budgets twice a year, to avoid spending much time reviewing or else to have a long/fixed budget for entire year.
Metrics here must be different from the usual ones (because those are already there in Program Level).
In Portfolio level, pay attention to Employee Engagement, Customer Satisfaction, Productivity, Agility, Time to Market, etc...
Chapter 9 - Building Large Solutions
Scale up the Program layer!
A Solution Train is made by several ARTs
Suppliers are used treated as another ART. Even if they are using different methodology, it is expected they attend PI and follow the same ART pace.
Customers (Direct and Indirect) are inseparable from the development processes
It also have pre and post PI Planning events, to create synchronization with the ARTs.
Concerned more about Capabilities, which will span across the ARTs. They describe Solution behaviors. A Capability must be structure to be contained in one single PI, broken into several Features.
Example:
Capability: Save documents in a Cloud
Feature: Save a Word Document in a Cloud
All same events:
- Solution Train Management Review and Problem-Solving
- Solution Demo
- Solution Inspect and Adapt
- Solution Retrospective
Exercise:
Feature: One ART within one PI
Capability
: One Solution Train within one PI
Program Epic: One ART across multiple PI
Solution Epic: One Solution Train across multiple PIs
Story: One Team, one Iteration
Portfolio Epic: Multiple Value Streams and Multiple PIs
Solution Intent
Unique source describing how my solution behaves and how it will behave
Change the goal of a phase gate to processes with Quality Built-In
Key Ceremonies
| LARGE SOLUTION | Solution Demo | Inspect & Adapt | |||
| PROGRAM | PI Planning | ART Sync | System Demo | Inspect & Adapt | Program Backlog Refinement |
| TEAM | Iteration Planning | Daily | Iteration Review | Iteration Retro | Backlog Refinement |
| PORTFOLIO | Epic Owners | Lean Portfolio Manager | Enterprise Architect |
| LARGE SOLUTIONS | Solution Train Engineer | Solution Manager | Solution Architect |
| PROGRAM | Release Train Engineer | Product Manager | System Architect / Engineer |
| TEAM | Scrum Master | Product Owner | Dev Team |
Reference Books
"Escape Velocity", Geoffrey Moore, About Clear Vision and Strategy
"Managing for Excellence", David Bradford and Allan Cohen
"Agile Software Requirements", Dean Leffingwell
"Switch", Chip Heath and Dan Heath
"The Five Dysfunctions of a team", Patrick Lencioni -> for Scrum Masters
0 comentários:
Postar um comentário