obsidian/Main

Fork 0

Files

Claudio Fritsche 187f9b62eb vault backup: 2025-03-23 16:50:29

2025-03-23 16:50:29 +01:00

29 KiB

Raw Permalink 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
0	Not used
2	used infrequently and ineffectively
4	Used occasionally with mixed effectiveness
7	Used consistently and effectively
10	Optimizing

More effective Agile Team Structure

The focus is to have a cross-functional team with diverse expertise in different software domains such as front-end, back-end, architecture design, UX design, etc. A typical agile team requires at least the following specializations:

Developers from different layers of the application (front end, back end, etc) and with different expertise (architecture, user experience, security, etc)
Testers from different layers of the application
technical writers
experts in the development process being used (Scrum Master)
Subject Matter Experts (e.g. Industry experts)
Business experts who bring business understanding and ROI to the team (Product Owner) It is difficult to find a full set of skills and remain small (5-9 people), which is why some people might play multiple roles and the organization should help the members to build those skills.

Beyond skills Ability and Authority to make decisions should lie within the team in order for it to implement actual agile

Treat teams as black boxes where you only give inputs and receive outputs. The teams commit to a sprint goal that they will deliver, but the management should not care about how this is delivered. Managers should also not review minute and miniature details and not do micromanagement.

More effective Agile Team Culture

Motivate teams through Autonomy, Mastery, Purpose. This principle comes from the psychologist Daniel Pink. Motivation always needs to be intrinsic and cannot be forced upon someone. Autonomy refers to the ability to direct your own life and work - what you do, when you do it and who you do it with. If a person doesn't believe their organization trusts them, thy won't believe they have real autonomy. Mastery refers to the desire to learn and improve, thus to the idea to constantly getting better. This is especially important for technical staff. The opportunity of growth has been a stronger motivator for developers than advancement, recognition, salary, status, level of responsibility and other factors. Purpose refers to understanding why what you're working on matters. What is the big picture? How it the thing you're working on more important than yourself? How does it support the company or the world at large?

Another important point is to consider not only the project in a business perspective, but also consider the team to be part of the project. If the team is energized after the project has finished, they have grown, and will be an asset to the company for future projects. If they are burnt out they won't be of any use after the project. As a company you should grow as well, so take care of your people.

Developing a business focus means putting every single developer in direct contact with customers. This helps them to see the big picture and will teach them to think through the lens of the customer instead of overly technical. Further it enhances the Purpose pillar of the developers, which increase motivation. Keep in mind that this should become / be a habit, not a one time thing.

Assigning clear team roles, improves the efficacy of teams.

More Effective Distributed Agile Teams

One of the key principles of distributed agile teams is to tighten the feedback loop, such that problems arise early and can be solved timely and effectively, which in turn allows the team to grow. In fact, a lot of suggestions in the book are about tightening the feedback loops: Product Owners are there to tighten the feedback loop around requirements, cross-functional teams with different skillsets allow for faster decision making, fast automated testing tightens the loop between coding and testing. Geographically distributed teams loosen the feedback loop because of:

non-ideal communication
time difference
larger batches of work before they are being shipped,
differences in languages
differences in culture
development and testing happening at different locations
product ownership and development at different locations
work on shared functionality 50/50

Once again, the goal is to have self-directed cross-functional teams that have the ability and the authority to make binding decisions locally.

Dos

routine face-to-face communication (scheduled): most of the problems are miscommunication. Plan with visits every 6 weeks
increase logistical support for distributed teams: Scheduled meetings: make good meeting habits. Make sure all members have good devices (microphones, headsets, etc) and that a communication tool like slack is used. Consider using remote proxies, meaning someone at the remote office is responsible. Make sure to provide onboarding and training. Mentoring is also important.
Leverage Autonomy, Mastery and Purpose: Treat all offices equally, don't use terminology like main office, secondary office; onshore vs offshore, etc. This reduces the Autonomy, Mastery and Purpose of the offshore office. Each site should be able to perform work autonomously and be able to grow autonomously
Respect Conway's Law: Technical structure of a system reflects the structure of the human organization that built the system. This is a two-way street, meaning the system also influences the teams.
Treat Agile teams as black boxes: Don't focus on how the teams perform the work.
Maintain high quality: keeping software close to a releasable state minimizes the discrepancy across distributed teams
Be aware of cultural differences: willingness to communicate bad news or answering "no" to questions, response to authority, individual vs team accomplishment, work-hour expectations, work life balance.
Inspect and Adapt: regular retrospectives to assess what is working and what is not. Teams must be empowered to make the changes they identify as causes.

[!Important] Key Principle: Fix the System, Not the Individual Increased miscommunication leads to errors, meaning people spend more time fixing defects. It is crucial to decriminalize errors, such that people embrace them and learn from them. Treat errors as system errors and not personnell problems.

What is it about our system that allowed this error to occur?

More Effective Individuals and Interactions

Productivity differs up to a factor of 10 between individuals of similar level of experience. Also teams in the same industries see the same factor.

There is a tension between new learning and application of prior learning.

#todo/b Look at PDL (Professional Development Ladder)

Emotional intelligence is key. People with a lot of it perform much better

Meetings should be kept effective:

Clear purpose
What decision / deliverable
Schedule shorter rather than longet
Only people who are necessary

More effective Agile Projects

Keep Projects small: much higher successrate when team remains below 20 people (but project needs to be defined accordingly, e.g. you cannot build an airplane with 2 people)
The larger the project, the lower the per-person productivity. !
keep Sprints short: 1-3 weeks max. Requirements can only be changed for the next sprint. Increase team accountability. Increase responsiveness. Expose risks early. Encourage automation. Offer frequent sense of accomplishment.
Velocity based planning
Vertical slices: tighter feedback loops, delivers higher business value
Manage technical Debt: technical debt can be an asset but can quickly evolve into a liability. !
- can be intentional (shirt-term / long-term)
- unintentional (bad faith)
- Unintentional but planner well and used proper software development practices (good faith)
- Legacy
- Summary: !

More effective large agile projects

I only skimmed this chapter because it doesn’t apply to us for now. But a few core ideas:

Support large teams through architecture: design a good architecture upfront in order to be able to split the large project into sub units , where normal small agile teams can execute whatever is needed in an agile manner.
- loose coupling, modularity
- Avoid monolithic databases
- Use queues: this makes it very modular because the thing can be processed later (microseconds later). It avoids the very rigid unflexible way of coding. Think of it as seams: there is a lot of interaction within a process, but very little across a boundary. You can take this too far if you have too many
- design by contract
Typical architecture is microservices: its very well compatible with agile.
Most common problems:
- requirements
- Architecture
- Configuration management / version management
- QA/Test
- Project Management
- Process

More effective Agile Quality

If you can‘t find the time to do it right, where will you find the time to do it over?

Minimize the Defect Detection Gap: we need effective quality assurance to detect defects early on
- Unit testing
- Static analysis
- Code reviews (if performed in a timely way)
- Continuous integration
Create and use a Definition of Done (DoD) (p. 157ff)
- Completion criteria for: design, code, test, documentation and other work related to implementation of a requirement.
- State very clearly to avoid ambiguity: its true or false.

More effective Agile Testing

Increase emphasis on testing by devs.
Increase front loading (test immediately after function creation)
Increase Test automation
automated tests, written by developers:
- Api tests, unit tests, integration tests, acceptance tests, UI layer tests, support for mocking, random inputs and data, simulations
- Devs should be able to run tests locally within minutes
- Team should be able to run complete test suite fot a complete test pass within hours. Incl. all unit tests, user level tests
Devs need to take primary responsibility for testing their own code
- Signs are if they close items towards the end of sprint (prio to code than to test)
Code coverage of at least 70% (except for safety critical systems). Its
Monitor static code metrics: depth of decision nesting, file size, folder size, magic numbers, embedded SQL, comments, adherence to coding guidelines
Use coding guidelines for test code as well
Maintenance of test suite is important as well

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"

29 KiB Raw Permalink Blame History Unescape Escape