obsidian/Main

Fork 0

Files

Claudio Fritsche d084823591 vault backup: 2025-01-14 16:38:08

2025-01-14 16:38:10 +01:00

8.3 KiB

Raw Blame History

title, created_date, updated_date, aliases, tags, type, book_name, author, status

title

created_date

updated_date

aliases

More Effective Agile by Steve McConnell

🏷️Tags : #01-2025 #book

Summary

[!summary] Summary 3 Sentences only!

What are the main ideas?

If I implemented one idea from this book right now, which one would it be?

How would I describe the book to someone else?

Ideas and Thoughts

[!info]+ Inspiring Questions

Did you think about other concepts from other books?

Do the concepts fit to your past, to your memories?

Can you relive them and reflect them from a different angle?

Clippings

[!info] Import Clippings from Kindle Annotate Clippings with thoughts and cross references

Thoughts and Ideas

Assign Scrum Master Role to some team member
Team setup: does scrum work with hardware and mixed teams?
Who is product owner?
What roles do we want?

More effective Agile beginnings: Scrum

The main common failure is not to use SCRUM in its entirety, but only implement certain parts. Scrum is already broken down to the minimum processes, everything you take away in addition will break the system (might not apply to power scrum users, but certainly to beginners).

Most common Challenges

Ineffective Product Owner: Before agile the most common source of failure was poor definition of requirements. Since the product owner is responsible for requirements it comes at no surprise that this is a common challenge. Businesses should treat this role as the highest leverage role for the scrum team and fill it accordingly. With former training business analysts, customer support staff and testers can make excellent POs.
- No Product Owner
- Only 1-2 teams per product owner
- PO doesn't understand the business
- PO doesn't understand how to specify software requirements
- PO doesn't understand the Development team's technical challenges, thus does not effectively prioritize --> accumulation of technical debt
- PO is not co-located with the rest of the Scrum team --> no timely answers to requirement questions
- PO is not empowered to make product decisions
- PO's agenda differs from the business's: team works towards a different goal than the business
- PO does not represent typical users --> for example: PO is a power user of the software
- PO refuses to abide by scrum rules --> change requirements mid sprint, or other disruptions
Insufficient Product Backlog refinement: the backlog is the developer's food and you never want to starve your development team. The PO's job is to update the backlog continously and keep it high quality..

Enjoy the Fruits of Your Labor

The agile mindset is about decriminalising mistakes and develop a Growth Mindset. Use mistakes as learning opportunities, Inspect and Adapt, and gradually become better. The main benefits for your organisation:

teams that stay focused on goals and that are responsive when things change
teams that monitor the effectiveness in order to replace ineffective practices with better ones meaning throughput increases over time
teams that monitor workflows. they will know where the work is and if it's progressing as it should. Increasing visibility and keeping delivery promises with high quality
teams work well with other teams and outside world
constant discoveries, but few disruptive surprises. If they appear you find them early and can react to them
high quality work at all times and identify opportunities for improvement. High motivation

Maturation Phases

several sprints to learn scrum, learn small increment,
over time focus shifts to organisations interaction with teams
iteratively teams are transformed. They deliver quickly and change direction quickly, meaning the organization has strategic opportunities to plan and execute differently and better
meaning everything gets better and better over time.

Summary of Key principles

Inspect and Adapt: Agile is empirical with focus on learning from experience. Meaning the framework should create opportunities to reflect periodically and make adjustments based on experience.
Start with Scrum: might not be the final journey, but is the best structured and best supported place to start.
Build Cross-Functional Teams: The teams should be self managed, meaning they need to include a full skillset to make well informed decisions that are binding to the organisation.
Integrate Testers into the Development Team: Close feedback loop between development and test by having the people work together.
Motivate Teams Through Autonomy, Mastery, and Purpose: Motivation factors are inherently supported: Teams work with Autonomy and to become better over time (Mastery). healthy Agile team and motivated Agile team are strongly intertwined.
Develop a Growth Mindset: Agile teams have a big steady focus on getting better.
Develop Business Focus: Developers should understand the business to fill the gaps in requirements.
Tighten Feedback Loops: Don't take any longer to learn lessons than you need to. This supports more rapid progress from Inspect and Adapt and faster imporvements in Effectiveness.
Fix the System, Not the Individual: If a developer is not performing look for the system problem that is frustrating the person. Usually it's the system, not the people.
Increase Team Capacity by Building Individual Capacity: Team attributes are the combination of individual members attributes and interactions. By strengthening the people, you strengthen the team.
Keep Projects Small: They are easier and more often successful. Not all work can be structured like this, but if you can you should do it.
Keep Sprints Short: they support a frequent inspect and adapt feedback loop and expose problems quickly before they grow into large problems
Deliver in Vertical Slices: Feedback is important and teams get better feedback on their product in vertical slices and thus improve more. This means the business improves more as well.
Manage Technical Debt: Focus on Quality. Managing technical debt supports higher team morale, faster progress and higher quality products.
Support Large Agile Projects Through Architecture: Good architecture even allows large projects to use agile. Good architecture can make a large project feel smaller
Minimize the Defect Detection Gap: The cost of fixing a defect grows with the age of the defect. --> Detecting early and fixing it is cheaper and increases quality.
Create and Use a Definition of Done: a good definition of done helps catch incomplete or faulty work early, minimizing the gap between defect insertion and detection.
Maintain a Releasable Level of Quality: High quality helps catching additional defects that slip through
Use Automated Test, Created by the Development Team: Helps minimizing the defect detection gap. Everyone on the team feels responsible and reinforces that quality is the responsibility of everyone.
Refine the Product Backlog: this ensures the team tackles high priority tasks first and doesn't invent new requirements
Create and Use a Definition of Ready: make sure requirements are truly ready before the team begins implementing them.
Automate Repetitive Activities: You have more benefits when automating repetitive tasks.
manage to Outcomes, Not Details: Leave autonomy with the team by communicating desired outcomes, not implementation details.
Express clear purpose with commander's intent: this leaves the team a clear ability to make timely, local decisions
Focus on Throughput, Not Activity: Busyness is not the objective, valuable work is.
Model Key Agile Behaviours: Effective leaders model the behaviours they want to see in others.
Decriminalize Mistakes: The goal is to surface mistakes as fast as possible without hesitation from the team so you can learn from them. A mistake you don't learn from penalizes the organisation twice.
Plan Based on Measured Team Capacity: Agile is an empirical approach: teams and organisations should plan their work based on their measured past performance.

More Effective Agile Steve McConnell 
-file: "More Effective Agile by Steve McConnell.md"

8.3 KiB Raw Blame History