obsidian/Main

Fork 0

Files

Claudio Fritsche 4250b7a159 vault backup: 2025-01-15 12:18:05

2025-01-15 12:18:05 +01:00

19 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?

[!Quote] Inspect, Adapt & Grow Contents

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?

What's Really Different About Agile?

Main Benefits of Agile vs Sequential:

Short release cycles allow for more timely and less expensive correction of defects and faster feedback loops, meaning you can learn and adapt faster.
End-to-End development in small batches allows for testing and faster feedback loops
Just-in-time planning doesn't waste time creating plans that are then thrown away.
Just-in-time requirements results in less time invested upfront for requirements that might eventually be discarded
Continuous automated testing is very powerful
Frequent, structured collaboration: daily scrum, sprint planning, sprint retrospective
focus on empirical, responsive improvement model allows the team to learn and grow fast.

Responding to the Challenges of Complexity and Uncertainty

Cynefin

Cynefin means habitat or neighbourhood in Welsh and they are considered to be clusters of meaning. 5 Domains: Complex, Complicated, Chaotic, Obvious, Disorder

In the Obvious domain, problems are well understood and clear. Example problems are taking an order at a restaurant, filling a car with gasoline, etc. The approach to solving them is sense, categorize, respond. There are only miniature problems like detailed if statements with live within this domain in software development, all other problems are not in this domain, which is why we can safely ignore it.

In the Complicated Domain you know the general shape of the problem, what question to ask and how to obtain answers. Multiple correct answers exist and you need to find the relationship between cause and effect. This is often hard, which makes this domain the domain of experts. The approach to solving problems is sense, analyze, respond, note the analysis instead of categorizing in the second step. Example problems: prepare a gourmet meal, database query for certain results, prioritize user requirements for version 4.1 of a mature system, etc. A lot of software development falls within this domain, and a sequential linear approach can work.

In the Complex Domain the relationship between cause and effect is not immediately clear, even to experts. You don't know all the questions to ask - finding the right questions is part of the challenge. Experimentation is needed to progress, some amount of failure is part of the process and decisions are often made on the basis of incomplete data. The approach to those problems is probe, sense, respond, meaning you can't analyze your way out of problems, but you need to probe and experiment with different solutions to start. Examples are buying a gift for someone who is difficult to shop for, meaning you know you most likely will need to exchange it later; Fixing a bug, which is not found during debugging, but only in production systems; creating software for changing hardware that is evolving. Many software development problems fall into this domain and this is where agile excells.

In the Chaotic Domain there is no discoverable relationship between cause and effect even with extended probing, because it is in constant turbulence. This domain also includes a time pressure element, which other domains lack. The approach to problems in this domain are decisive, action-oriented in order to impose order onto the chaos: act, sense, respond. Examples of such problems are: provide natural disaster help, while it is still happening; stopping a food fight in a highschool cafeteria; defining a feature set in a highly political environment with powerful stakeholders; fixing a bug in production by reversing the version, because no probing nor analysis has found the bug. The sizes of the problems are mostly smaller than project size for typical software projects.

In the Disorder Domain you lack clarity which domain applies to your problem. The approach here is to decompose the problem into subelements and assess the domains of each subelement. Remember that each project might have problems in various domains.

! As shown in the graph above, it is always better to use an agile approach and maybe sacrifice some efficiency if your problem was only complicated. The other way round could be disastrous and lead to the cancellation of the project.

Succeeding on Complex Projects: OODA

! The origin of OODA was the US military in order to accelerate decision making. It is a method to establish context, formulating a plan, performing work observing results and incorporating learnings into the next cycle.

Observe the current situation, outside information that is relevant and any aspects of the situation that are unfolding (emergent). OODA places a strong emphasis on observation, experience and learning and thus is very empirical.

Orient is where you relate the observations to your situation, meaning you decide how the observations are relevant to you and your current situation and how possible responses look like. This is an opportunity to challenge your assumptions, adjust for cultural and company cultural blind spots, de-biasing data and information. A classical example is the first iPhone, which was technically inferior to many other phones, but solved the user experience problem instead, which turned out to be more important.

Decide is where you make a decision based the observations and the orientation in the previous two steps. The goal is to disrupt the opponents OODA-loop by forcing them to play your game instead of you playing their game.

Act is finally where you implement the decision, after which you start over in the cycle by observing the impact of your actions and learning from them.

In contrary to sequential development practices, OODA considers uncertainty as opportunity to act and create something new, something you can exploit to gain an advantage over your opponent.

[!important] Inspect and Adapt Inspect and Adapt is a useful shorthand for OODA. Agile teams should avoid being idealistic about their practices and instead adjust their practices based on empirical observations about what has been proved to work. Apply Inspect and Adapt to everything (plans, designs, code quality, tests, processes, team interactions, organizational interactions, etc), meaning every factor that can make a difference to a team's effectiveness.

More effective Agile beginnings: Scrum

Summarize everything until failure mode #todo/b

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 continuously and keep it high quality. Split too long stories into 2, write down details of other stories to create nice work packages for the developers,
Stories Too large: should be completable within a single sprint. For a team of recommended size (3-9) aim for 6-12 stories per sprint. The maximum story size should consume max half the team for max half the sprint, most stories should be smaller
Daily Standup not held daily: Stick to it, no matter what. Focus on the 3 questions: what did you do yesterday, what do you do today, what is blocking progress? Keep it time boxed to 15 minutes --> max 2 minutes or so per person.
Overly long sprints: Most sprints are 2 weeks. 3 weeks or longer is too risky because of: planning mistakes, too optimistic commitments, procrastination and so on.
Emphasis on Horizontal Slices Rather than Vertical Slices: Vertical slices refer to end-to-end functionality across the technology stack. horizontal slices on the other hand do not produce any demonstrable business-level functionality. Focusing on vertical slices supports better feedback loops and earlier delivery of business value.
Separate Development Teams and Test Teams: A common holdover from sequential development. Scrum team needs cross-functional expertise to operate effectively.
Unclear Definition of Done (DoD): When something is marked as done, the team should have confidence that it is actually done, meaning no more work remains for that item in order to add it to the production release.
Not Driving to a Releasable Level of Quality Each Sprint: Excessive schedule pressure is that team puts focus on appearance of progress above actual progress. Another example is skipping the testing, in order to get more actual code done (also related to DoD). Successful agile teams drive each story to production level before tackling the next one.
Retrospectives not held: when feeling overwhelmed by the amount of work, teams often skip retrospectives. This is a huge mistake! Without it you don't learn from planning and commitment mistakes leading to the same problem over and over again.
Retrospectives not Implemented in the next sprint: doing the retrospectives, but not applying the learnings. This means you cannot progress.
Scrum And: You don't need more than scrum to start.
Ineffective Scrum Master: Scrum master is responsible for avoiding these failure modes.
- No scrum master
- Scrum Master is supporting too many teams
- Dual Scrum Master prioritizes development work over Scrum work
- Scrum Master does not understand Scrum well enough to coach the team and project stakeholders

All points above share that they usually diverge from pure Scrum, meaning they implement "Scrum, but...". Further all attributes demand high discipline practices, meaning if the system is not properly set-up the people tend to drift away from it. The scrum master is responsible for ensuring those practices and the meetings (sprint planning, daily scrum, sprint review and sprint retrospective) provide structural support as well as social support to stick to the scrum.

[!Tip] Success Factors in Scrum Each of the failure modes above can be converted into a success factor.

A Successful Sprint

A successful sprint will support the main goal of Scum which is maximizing the value of the product:

deliver usable, valuable increment (aggregate functionality) fulfilling DoD.
the sprint's increment increases in value compared to the previous sprint
the Scrum process is improved compared to the previous sprint
Scrum team learns something about itself, its business, its product or its customers
Motivation remains the same or increases with each sprint

The time allocation per developer should be something like the following (out of 60 hours: 6h project focus for 10 business days. Startups have less overhead and thus more likely 7-8h of project work per day):

48h development work, including testing
2h daily standups
3h product backlog refinement (5%)
4h sprint planning
2h sprint review
1h sprint retrospective

Summarizing: 80% of the work should go into development and 20% into planning and process improvement.

A Scrum Scorecard

Score	Description
2	used infrequently and ineffectively
4	Used occasionally with mixed effectiveness
7	Used consistently and effectively
10	Optimizing

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"

19 KiB Raw Blame History