Notes and highlights for

Learning Agile: Understanding Scrum, XP, Lean, and Kanban

Stellman, Andrew; Greene, Jennifer

methodologies , Scrum and Extreme Programming ( XP ) .

Highlight (pink) - Page 2 · Location 159

Lean and Kanban ,

Highlight (yellow) - Page 2 · Location 160

You’ll learn that while these four agile schools of thought focus on different areas of software development , they all have one important thing in common : they focus on changing your team’s mindset .

Highlight (yellow) - Page 2 · Location 163

the practices that make up the day - to - day work , and the values and principles that help you and your team fundamentally change the way that you think about building software .

Highlight (pink) - What Is Agile? > Page 2 · Location 165

Agile is a set of methods and methodologies that help your team to think more effectively , work more efficiently , and make better decisions .

Highlight (blue) - What Is Agile? > Page 2 · Location 172

This mindset helps people on a team share information with one another , so that they can make important project decisions together — instead of having a manager who makes all of those decisions alone .

Highlight (pink) - What Is Agile? > Page 2 · Location 174

opening up planning , design , and process improvement to the entire team .

Highlight (pink) - What Is Agile? > Page 2 · Location 180

“ going agile ” means helping the team find an effective mindset .

Highlight (pink) - What Is Agile? > Page 4 · Location 202

Figure 1 - 2 . Both people seem to have a valid reason for their attitude toward the daily standup meeting . What effect will this have on the project ?

Note - What Is Agile? > Page 4 · Location 203

problem is that 1. PM : Needs to solve planning and solving the details when they come. 2. Developerss: Need time to focus

Highlight (pink) - What Is Agile? > Page 4 · Location 204

The project manager will be thinking mainly about how people are deviating from his plan ,

Note - What Is Agile? > Page 4 · Location 205

this mentality is wrong

Highlight (pink) - What Is Agile? > Page 4 · Location 205

The developer , on the other hand , wants the meeting to end as quickly as possible , so he’ll tune out everyone else while he’s waiting to give his update ,

Note - What Is Agile? > Page 4 · Location 206

this mentality is wrong

Highlight (yellow) - What Is Agile? > Page 4 · Location 207

Let’s be clear : this is how many daily standups are run , and while it’s not optimal , a daily standup that’s run this way will still produce results . The project manager will find out about problems with his plan , and the developer will benefit in the long run because those problems that do affect him can be taken care of sooner rather than later — and the whole practice generally saves the team more time and effort than it costs . That makes it worth doing .

Highlight (pink) - What Is Agile? > Page 5 · Location 212

example , what would happen if the project manager felt like everyone on the team worked together to plan the project ?

Highlight (pink) - What Is Agile? > Page 5 · Location 219

the developer felt like this meeting wasn’t just about giving status , but about understanding how the project is going , and coming together every day to find ways that everyone can work better ? Then the daily standup becomes important to him .

Highlight (yellow) - What Is Agile? > Page 5 · Location 221

The daily standup becomes his way to make sure that the project is run in a sensible , efficient way

Highlight (blue) - What Is Agile? > Page 6 · Location 224

When every person on the team feels like they have an equal hand in planning and running the project , the daily standup becomes more valuable — and much more effective .

Note - What Is Agile? > Page 6 · Location 226

Low key - This is the best thing in the book.

Highlight (blue) - What Is Agile? > Page 6 · Location 228

But if everyone on the team shares the mindset that the daily standup is their way of making sure that everyone is on track , they’re all working toward the same goal , and they all have a say in how the project is run , it becomes much more effective

Highlight (pink) - Who Should Read This Book > Page 7 · Location 255

ideas to your team , and to overcome some of the challenges that you face every day when helping a team become more agile .

Note - Who Should Read This Book > Page 7 · Location 256

This is literally collective mindset where it comes to a point everyone is chimining and resolving I had an issue with XYZ. You just need to debug (without the manager being present even!)

2. Understanding Agile Values

Highlight (yellow) - Page 16 · Location 418

Manifesto for Agile Software Development :

Note - Page 16 · Location 419

The Gov is the OPPOSITE OF THIS. And you dont want a COMPANY FOR PROFIT of this

Highlight (pink) - Page 16 · Location 419

Individuals and interactions over processes and tools

Note - Page 16 · Location 419

This interaction could reduce a process or tool. Or make it better. Becouse of this interaction

Highlight (yellow) - Page 16 · Location 419

Working software over comprehensive documentation

Note - Page 16 · Location 420

Makes software a priority OVER any documentaiton. What is better to have the Authenticator at 99% reliablility OR have 200 pages of documentaiton????

Highlight (blue) - Page 16 · Location 420

Customer collaboration over contract negotiation

Note - Page 16 · Location 420

Collaboration is key. Lets say I own a Cleaning Compoany, and the cleaning company found a crack in the building.... If you leave that wihout reporting...then what happens the client eventgually would have to fix it and MAYBE sacrifice budget. Good will pays offl, but you can only have Good will if you have that report.

Highlight (orange) - Page 16 · Location 420

Responding to change over following a plan

Note - Page 16 · Location 420

This happen when people are connected with their managers/pm over whatever plan is already established. Plans are not perfcet

Highlight (yellow) - No Silver Bullet > Page 19 · Location 479

Many people felt that developers could build software just by following a set of instructions , like following a recipe or assembling a product on an assembly line .

Highlight (blue) - No Silver Bullet > Page 19 · Location 482

one of the most quoted papers in software engineering is Fred Brooks’s 1986 essay , “ No Silver Bullet , ”

Highlight (pink) - No Silver Bullet > Page 20 · Location 485

methodology

Highlight (yellow) - No Silver Bullet > Page 20 · Location 486

a technology that programmers could use to prevent or eliminate bugs .

Highlight (blue) - No Silver Bullet > Page 20 · Location 497

Waterfall really can work . In fact , if you actually know what you need up front , then writing it down first is a pretty efficient way to build software .

Highlight (yellow) - No Silver Bullet > Page 20 · Location 503

Good practices , especially ones like code reviews and automated testing , which are aimed at finding bugs as early as possible in the process . They usually called this “ defect prevention , ” and it required teams to actively think about how those bugs got into the code in the first place .

Highlight (blue) - No Silver Bullet > Page 20 · Location 506

Drawers full of documentation that have rarely been opened , because the people on the team understand that the act of writing down the plan — and the questions that get asked during that planning — is more important than mindlessly sticking to it afterward .

Highlight (yellow) - Agile to the Rescue! (Right?) > Page 26 · Location 633

from dysfunctional to functional , and that’s very good . They’ve gotten what we like to call better - than - not - doing - it results . But is this really all there is to agile ?

Note - Agile to the Rescue! (Right?) > Page 26 · Location 634

This is how I felt exactly when my new manager at microsoft joined. I worked in Agile before and it felt like a waste of time (mainly becouse of the mindset) Becouse it was "I did Authentication" Today: "I will continue working in Authentication" Same Repetitive Then join miccrosoft where no Agile was done --- Somebody came and implemented Agile --- So it kinda feels functgional but still lots of room for improovement

Highlight (blue) - A Fractured Perspective > Page 27 · Location 659

A user story is a way to express one very specific need that a user has .

Highlight (blue) - A Fractured Perspective > Page 27 · Location 661

this : “ As a bar patron , I want to be able to play the newest hit that was just released today . ”

Highlight (orange) - A Fractured Perspective > Page 28 · Location 665

the lead developer and architect , sees a user story as a small piece of functionality , written out in a simple , easy - to - understand way . He can break it down into tasks , create an index card for each of them ,

Note - A Fractured Perspective > Page 28 · Location 666

Essentiually this would breka down the task into action items that are small pieces of implementation

Highlight (blue) - A Fractured Perspective > Page 28 · Location 668

value that will be delivered to the company ,

Highlight (blue) - A Fractured Perspective > Page 28 · Location 670

Bruce , the team lead , sees a user story as a specific goal that the team can organize around . He helps them figure out which stories should be done next , and uses the progress to keep them motivated .

Note - A Fractured Perspective > Page 28 · Location 672

You reach senior / team lead by just delivering --- Not impact --- Impact is something a Product Owner cares about not a SDE I / SDE II nor SENIOR engineering. Managers are messured becouse of resource administration NOT even impact. M1 are messured based on the throughpout of the team M2 -> Impact on how the project can do XYZ example that the GOV contract followes through

Highlight (pink) - A Fractured Perspective > Page 28 · Location 672

Adding user stories to a team like this will help improve the way they build software , because each of the people in those four roles will see a way that user stories helps him or her personally .

Highlight (blue) - A Fractured Perspective > Page 28 · Location 684

developers making incorrect assumptions , jumping into programming , and having to make changes to the code that could have been avoided , and that leave it more fragile .

Highlight (pink) - A Fractured Perspective > Page 29 · Location 687

a fractured perspective ,

Note - A Fractured Perspective > Page 29 · Location 688

aka miss comunication or partial view of what the product should look like (or individual vision on the proyect itself)

Highlight (blue) - A Fractured Perspective > Page 29 · Location 707

A project manager who sees user stories taped to a whiteboard as a direct replacement for a Gantt chart in a Microsoft Project

Highlight (yellow) - A Fractured Perspective > Page 30 · Location 712

In other words , when the team doesn’t communicate , the people in each of the project roles can adopt a new tool ( user stories ) , but still hold onto the old attitudes that caused friction and team problems .

Highlight (pink) - A Fractured Perspective > Page 31 · Location 736

Why Does a Fractured Perspective Lead to Just Better - Than - Not - Doing - It Results ?

Highlight (pink) - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 33 · Location 762

as the Agile Manifesto , was created

Note - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 33 · Location 762

Fun fact Agile Manifesto was NOT created by product managers but from engnieers like the one that did TDD or Clean Architecture and others https://agilemanifesto.org/iso/es/manifesto.html Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

Highlight (orange) - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 33 · Location 763

Snowbird Retreat in the mountains outside of Salt Lake City , Utah , to come up with a solution to the software development problems they had all seen throughout their careers . After days of discussion , they agreed on a core set of ideas and principles ( and also on the name “ agile ” ) . They bundled them into a single document , which started a shift in thinking across the software development world . The Agile Manifesto contains four simple values . Here’s the entire Manifesto : We are uncovering better ways of developing software by doing it and helping others do it . Through this work we have come to value : Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is , while there is value in the items on the right , we value the items on the left more .

Highlight (pink) - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 34 · Location 787

like daily standup meetings and retrospectives ( where everyone talks about how the project or iteration went , and what lessons can be learned ) — throughout this book .

Highlight (pink) - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 35 · Location 800

It could be software that a company sells to make money , or it could be software that people who work at the company use to do their jobs more efficiently . For a project to add value , it needs to deliver or save more money than it cost to build .

Highlight (pink) - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 35 · Location 807

It often also happens to be the kind of documentation — like wireframes or sequence diagrams — that programmers don’t mind writing .

Highlight (pink) - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 35 · Location 811

test - driven development , in which the programmers build automated unit tests before they build the software that it tests .

Highlight (pink) - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 35 · Location 813

because it gives developers a record of what the code is supposed to do , and of the expected behavior for individual elements of the software .

Note - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 35 · Location 814

For example - Aproving a notifcation (all of our bug bashes)

Highlight (orange) - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 35 · Location 819

software , they often treat each other as if they’re working on a contract . In many companies , they will explicitly discuss SLAs ( service - level agreements ) between programming teams , between testers and developers , and between teams and their users . This may reduce the risk of getting in trouble with the boss ( because it makes it easier to point a finger and blame another team for failing to deliver software ) , but it is highly counterproductive if the goal is to get working software out the door for the users .

Highlight (pink) - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 36 · Location 829

Responding to Change Over Following a Plan There’s an old project management saying : “ plan the work , work the plan . ” Unfortunately , if you work the wrong plan , you’ll build the wrong product . That’s why teams need to constantly look for changes , and to make sure that they respond appropriately when there’s a change in what the users need , or in how the software needs to be built . If the circumstances change , the project needs a new plan .

Note - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 36 · Location 833

Designers and Product Owners should be in the standup meetings to keep tap on what the product changes

Highlight (orange) - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 36 · Location 837

This makes for a smoother project , but , if the change is really needed , it will be much harder to make it later on , after the code is more complete .

Highlight (yellow) - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 37 · Location 839

Agile teams often use task boards to show tasks and track progress . They’ll write tasks or user stories on index cards , and move them across the board as they progress . Many teams also draw charts on their task boards to help them track progress .

Highlight (yellow) - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 38 · Location 856

agile practices to help attain the goal of building working software that customers value through interaction , collaboration , and responding to change will get more out of their projects than the team that simply adopts better planning , programming , and documentation practices .

Highlight (blue) - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 38 · Location 865

Agile Manifesto contains common values and ideas that lead to effective teams .

Note - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 38 · Location 865

So the idea is that if a team is on the same page on the Values of Agile, they would go faster than just implemeting (I learned this on the hard way on my first engnieering job)

Highlight (pink) - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 38 · Location 869

Working software means software that delivers value to the company .

Highlight (pink) - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 38 · Location 869

“ Customer collaboration over contract negotiation ” means treating everyone like they’re on the same team .

Note - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 38 · Location 870

Sales, Desginers, PMs, Eng, Eng Managers, and Principles

Highlight (pink) - The Agile Manifesto Helps Teams See the Purpose Behind Each Practice > Page 38 · Location 870

Many effective agile teams treat the product owner as a member of the project team to collaborate with , rather than a client or customer to negotiate with .

Highlight (yellow) - Understanding the Elephant > Page 39 · Location 883

metaphor that can help us get a better handle on what it means to have a fractured perspective ,

Highlight (pink) - Understanding the Elephant > Page 41 · Location 915

A team whose members only see the practices and don’t think about the principles will miss out on the important interactions between people . Their perspective stays fractured ;

Note - Understanding the Elephant > Page 41 · Location 916

Status Updatres are a Key thing for improving Estiamtes Planning Developing velocity Changing things Adhawks PM and Designers should join the meetings and stakeholders of the meetings

Highlight (pink) - Understanding the Elephant > Page 41 · Location 919

Individuals and interactions over processes and tools

Highlight (blue) - Understanding the Elephant > Page 42 · Location 933

agile methodology is a collection of practices combined with ideas , advice , and often a body of knowledge and wealth of experience among agile practitioners .

Highlight (pink) - Understanding the Elephant > Page 42 · Location 943

Scrum can be summarized

Highlight (blue) - Understanding the Elephant > Page 42 · Location 944

The team and the project sponsors create a prioritized list of all the things the team needs to do . This can be a list of tasks or a list of features . This is known as the product backlog .

Highlight (blue) - Understanding the Elephant > Page 42 · Location 945

Each month , the team pulls off the top section of the list , which they estimate to be one month’s worth of work . They expand it to a detailed task list , called the sprint backlog . The team promises to demo or deliver the results to the sponsors at the end of the month .

Highlight (blue) - Understanding the Elephant > Page 42 · Location 947

Each day , the team meets face - to - face for five to ten minutes to update each other on their status and on any roadblocks that are slowing them down . This is called the daily standup meeting .

Highlight (blue) - Understanding the Elephant > Page 42 · Location 949

One particular person is designated the Scrum Master .

Highlight (blue) - Understanding the Elephant > Page 43 · Location 954

The product owner creates and maintains a product backlog ,

Highlight (pink) - Understanding the Elephant > Page 43 · Location 959

The team meets for a daily standup meeting in which everyone talks through the work they did the day before , the work they plan to do today , and any obstacles in their way .

Highlight (blue) - Understanding the Elephant > Page 43 · Location 960

The Scrum Master acts as leader , coach , and shepherd to guide the team through the project .

Highlight (pink) - Understanding the Elephant > Page 43 · Location 974

But XP goes beyond that , using those practices to help the team build simple , flexible software designs that are easy for the team to maintain and extend .

Highlight (pink) - Understanding the Elephant > Page 44 · Location 978

Scrum and XP have many things in common , including the fact that they are both iterative .

Highlight (blue) - Understanding the Elephant > Page 44 · Location 981

timeboxing ,

Highlight (pink) - Understanding the Elephant > Page 44 · Location 987

Methodologies are constructed around the agile values and principles , so this change in attitude is generally toward collaboration and

3. The Agile Principles

Highlight (pink) - Page 51 · Location 1118

3 . The Agile Principles

Highlight (yellow) - Page 51 · Location 1118

If I had asked people what they wanted , they would have said faster horses . Henry Ford1

Highlight (blue) - The 12 Principles of Agile Software > Page 52 · Location 1140

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software .

Highlight (blue) - The 12 Principles of Agile Software > Page 52 · Location 1142

Welcome changing requirements , even late in development .

Highlight (blue) - The 12 Principles of Agile Software > Page 52 · Location 1143

Deliver working software frequently , from a couple of weeks to a couple of months , with a preference to the shorter timescale .

Highlight (blue) - The 12 Principles of Agile Software > Page 52 · Location 1144

The most efficient and effective method of conveying information to and within a development team is face - to - face conversation .

Highlight (blue) - The 12 Principles of Agile Software > Page 52 · Location 1145

Businesspeople and developers must work together daily throughout the project .

Highlight (blue) - The 12 Principles of Agile Software > Page 52 · Location 1145

Build projects around motivated individuals . Give them the environment and support they need , and trust them to get the job done .

Highlight (blue) - The 12 Principles of Agile Software > Page 52 · Location 1146

Working software is the primary measure of progress .

Highlight (blue) - The 12 Principles of Agile Software > Page 52 · Location 1147

Agile processes promote sustainable development . The sponsors , developers , and users should be able to maintain a constant pace indefinitely .

Highlight (blue) - The 12 Principles of Agile Software > Page 52 · Location 1148

Continuous attention to technical excellence and good design enhances agility .

Highlight (blue) - The 12 Principles of Agile Software > Page 52 · Location 1149

Simplicity — the art of maximizing the amount of work not done — is essential .

Highlight (blue) - The 12 Principles of Agile Software > Page 52 · Location 1149

The best architectures , requirements , and designs emerge from self - organizing teams .

Highlight (blue) - The 12 Principles of Agile Software > Page 52 · Location 1150

At regular intervals , the team reflects on how to become more effective , then tunes and adjusts its behavior accordingly . 3

Highlight (blue) - The Customer Is Always Right...Right? > Page 53 · Location 1154

He’s talking about giving people what they actually need , and not just what they ask for . The customer has a need , and if you’re building software to meet that need , then you have to understand it — whether or not he can communicate it to you . How do you work with a customer who can’t necessarily tell you at the beginning of a project that he needs a car , and not just faster horses ?

Highlight (pink) - The Customer Is Always Right...Right? > Page 53 · Location 1158

deliver value . But that word , “ value , ” is a little bit tricky , because everyone sees different value in the software : different people need different things from it .

Note - The Customer Is Always Right...Right? > Page 53 · Location 1160

value is the sasme shit as impact

Highlight (pink) - The Customer Is Always Right...Right? > Page 53 · Location 1171

Every one of these things represents value that’s delivered to a stakeholder .

Note - The Customer Is Always Right...Right? > Page 53 · Location 1171

TLDLR I dont know the value of the thing UNTIL people start usign the actual product. Meaning that I could ship XYZ and the impact is NON But we should see what stakeholders use it for. So for example for Passkeys - This could mean For Secuyrity Admings: 123 Tenants are able to do phish resisntant better For Developers: Passkey code is easy to extend and work with the SDK For Eng Managers: Reduce the amount of COGSS But everyone thinks about IMPACT/VALUE different and its EASYLY VIEW AFTER thie PROYECT IS FINISHED.

Highlight (pink) - The Customer Is Always Right...Right? > Page 54 · Location 1174

It’s much harder to see that value at the start of the project .

Highlight (blue) - Delivering the Project > Page 55 · Location 1210

By putting frequent delivery of value first , by looking at each change as a good thing for the project , and by delivering software frequently , the team and the customers can work together to make adjustments along the way . The software that the team builds might not be what they set out to build , but that’s a good thing — because they end up building the software that the customers need most .

Highlight (orange) - Delivering the Project > Page 55 · Location 1215

This first principle includes three distinct and important ideas : releasing software early , delivering value continuously , and satisfying the customer .

Highlight (pink) - Delivering the Project > Page 56 · Location 1225

through early delivery :

Highlight (pink) - Delivering the Project > Page 56 · Location 1231

The downside to delivering early is that the software that’s first delivered to the customers is far from complete . This can be really hard for some users and stakeholders to deal with ; while some users are used to the idea that they’ll see software early , others are much less so . Many people have a hard time when they are handed software that’s not perfect . In fact , in a lot of companies ( especially larger companies where people have spent years working with software teams ) , the software team has to literally negotiate the terms under which they’ll provide software to their stakeholders . When there’s not a great partnership between the team and the people they build software for , if the team delivers incomplete software , the users and stakeholders may judge it very harshly and even panic if a feature they expect to see is missing .

Note - Delivering the Project > Page 56 · Location 1237

This is something that you have to EDUCATE the client. Meaning that the client has to understand the Agile Methodiligies, and they have to see value from being in Private Preview. On my current job is SECEURITY, my last JOB is PRIVACY. Privacy is harder becouse of the US consitution they are monetary consequences. Meaning that each data record could lead to 200$ fine from the US gov. nevertheless we shipped regularly.

Highlight (pink) - Delivering the Project > Page 57 · Location 1252

especially for a developer who knows that his boss will hold him to the old deadline , no

Highlight (pink) - Delivering the Project > Page 57 · Location 1265

Very often , someone is telling you to change course after explicitly setting you on that course . If that person told you to build one thing , and you went ahead and built half of it , it’s very frustrating for that same person to then come back to you and say , “ Actually , now that I think about it , can we

Highlight (pink) - Delivering the Project > Page 57 · Location 1267

in . Now you have to go back and make changes to things you thought were done . It’s hard not to get defensive about that ! And it gets even worse if you’re the one who’s held responsible for not reading your customer’s mind and , as a result , blowing your deadline .

Note - Delivering the Project > Page 57 · Location 1269

I live this PR hahaha :')

Highlight (pink) - Delivering the Project > Page 57 · Location 1270

The first step toward welcoming changing requirements is to try to see things from the customer’s perspective . This is not always easy , but it’s enlightening .

Highlight (blue) - Delivering the Project > Page 58 · Location 1275

Your deadline is going to be blown , but so is his .

Highlight (pink) - Delivering the Project > Page 58 · Location 1281

Nobody gets in “ trouble ” when there’s a change . We acknowledge — and our bosses acknowledge — that we’re human and fallible , and that it’s better for the company to allow us to make mistakes and correct them frequently , rather than expect us to do things perfectly the first time .

Highlight (pink) - Delivering the Project > Page 58 · Location 1287

We stop thinking of changes as mistakes . We did our best with the information we had at the time , and it only became clear that we were wrong because the decisions we made along the way gave us the perspective to recognize the changes that we have to make today .

Highlight (pink) - Delivering the Project > Page 59 · Location 1301

The term “ command - and - control ” is borrowed from the military . In our 2010 book , Beautiful Teams , we interviewed Northrop Grumman chief engineer Neil Siegel ,

Highlight (pink) - Delivering the Project > Page 61 · Location 1320

The key to welcoming changes without introducing chaos lies in delivering working software frequently .

Highlight (yellow) - Delivering the Project > Page 61 · Location 1330

The project manager’s role starts to shift away from command - and - control , where she gave the team a daily battle plan and constantly adjusted to keep them on track . Instead , now she’s working with the team to make sure that each person is constantly looking at the big picture and working toward the same goals .

Highlight (blue) - Communicating and Working Together > Page 65 · Location 1389

So back to that question that teams have struggled with : how much documentation should they create ? The answer , for an agile team , is just enough to build the project . Exactly how much that is depends on the team , how well they communicate , and the problem that they’re solving . Think about all of the other kinds of documentation that software teams build : capturing all of the decisions made in every meeting by taking copious meeting notes ; creating cross - reference documents that describe every aspect of every data source or store ; complex matrices of detailed roles , responsibilities , and rules that each person needs to follow . A case can be made for all sorts of documentation . If it doesn’t actually help the team build the software , and if it’s not required for some other reason ( like for a regulator , investor , senior manager , or other stakeholder ) , an agile team doesn’t build it . But if , for example , a team finds that it really helps them to write a functional requirements document , then they can do it and still be agile . It all depends on what works best for the team , and that’s one of the freedoms that agile gives you .

Highlight (pink) - Communicating and Working Together > Page 66 · Location 1418

Principle # 4 : The Most Efficient and Effective Method of Conveying Information To and Within a Development Team Is Face - To - Face Conversation . Agile practitioners recognize that documentation is just another form of communication . 4 When I write a document and hand it to you , the goal is not to write documentation .

Highlight (pink) - Communicating and Working Together > Page 67 · Location 1435

Software engineers are notoriously practical . When they see how much work is involved in building up that comprehensive documentation , they end up having those face - to - face conversations anyway .

Note - Communicating and Working Together > Page 67 · Location 1436

Lived this!

Highlight (pink) - Communicating and Working Together > Page 68 · Location 1454

To build software well , teams need to have a lot of face - to - face discussion with businesspeople , because they need to tap into their knowledge of the company’s problems that are going to be solved with software .

Highlight (blue) - Communicating and Working Together > Page 68 · Location 1460

The longer they have to wait to get their questions answered , the slower their projects progress .

Highlight (pink) - Communicating and Working Together > Page 68 · Location 1463

The finished software is worth money to the company . If that value is more than the cost to build the software , it’s worth it for the company to invest in its development .

Highlight (pink) - Communicating and Working Together > Page 70 · Location 1492

Some common “ incentives ” that work against agile teams include : Giving programmers poor performance reviews when code reviews routinely turn up bugs , and rewarding them for “ clean ” code reviews . ( This just leads programmers to stop finding bugs in code reviews . )

Note - Communicating and Working Together > Page 70 · Location 1494

ehhh this is ??! weird!?!? but true I find this a a conflict of insterest

Highlight (pink) - Communicating and Working Together > Page 70 · Location 1494

Rewarding testers for the number of bugs that they report . ( This encourages nitpicking and poor reporting , and discourages them from partnering with the programmers , because it sets up an antagonistic relationship between them . )

Note - Communicating and Working Together > Page 70 · Location 1495

:( NO PLS THIS IS HORRIBLE THEN!!!

Highlight (pink) - Communicating and Working Together > Page 71 · Location 1496

Basing business analysts ’ performance reviews on the amount of documentation they produce ( rather than the amount of knowledge they’ve shared with the team ) .

Highlight (blue) - Communicating and Working Together > Page 71 · Location 1497

Ultimately , everyone’s performance should be based on what the team delivers , rather than the specific role that they played in it .

Note - Communicating and Working Together > Page 71 · Location 1498

Output - 20PR out with 3 demos Amount of demos

Highlight (pink) - Communicating and Working Together > Page 71 · Location 1503

Comprehensive documentation and traceability matrices are a particularly insidious source of problems with a team’s environment and support . Instead of encouraging an environment of trust , they encourage a “ cover your ass ” ( CYA ) attitude in which teams move toward a “ contract negotiation ” approach ,

Note - Communicating and Working Together > Page 71 · Location 1506

This is TRUE

Highlight (pink) - Communicating and Working Together > Page 71 · Location 1518

The opposite of CYA is trust . A company that develops only the minimal documentation needed for the project has an environment where the team is trusted to do the right thing when a change happens . An agile team with a “ we’re all in this together ” attitude , where if the project fails everyone shares the blame , doesn’t need to CYA .

Highlight (pink) - Communicating and Working Together > Page 72 · Location 1523

— even if it causes the project to take longer .

Highlight (pink) - Project Execution—Moving the Project Along > Page 74 · Location 1558

Working Software Is the Primary Measure of Progress .

Highlight (pink) - Project Execution—Moving the Project Along > Page 75 · Location 1576

Figure 3 - 6 . Working software is better than progress reports for giving everyone the latest update on the project’s status , because it’s the most effective way for the team to communicate what they’ve accomplished .

Highlight (blue) - Project Execution—Moving the Project Along > Page 76 · Location 1583

Principle # 8 : Agile Processes Promote Sustainable Development . The Sponsors , Developers , and Users Should Be Able to Maintain a Constant Pace Indefinitely .

Highlight (pink) - Project Execution—Moving the Project Along > Page 76 · Location 1601

Principle # 9 : Continuous Attention to Technical Excellence and Good Design Enhances Agility . Poor estimates aren’t the only cause of late nights and weekends . Most developers recognize that sinking , pit - of - the - stomach feeling that comes with the realization that a seemingly simple bit of coding turned out to be a nightmare to design . There go the next three weekends , which will now be spent tracking down bugs and patching up code .

Highlight (pink) - Project Execution—Moving the Project Along > Page 77 · Location 1610

The last two decades or so have brought us a revolution in software design . Object - oriented design and analysis , design patterns , decoupled and service - oriented architecture , and other innovations have given developers patterns and tools to bring technical excellence to every project . But this doesn’t mean that agile teams spend a lot of time creating large - scale designs at the start of every software project . Agile developers build up great coding habits that help them create well - designed code . They’re constantly on the lookout for design and code problems , and take the time to fix those problems as soon as they’re discovered . By taking a little extra time during the project to write solid code and fix problems today , they create a codebase that’s easy to maintain tomorrow .

Note - Project Execution—Moving the Project Along > Page 77 · Location 1616

Good Design = Good Estimates where you can write CLEAN CODE --- BROTHER READ THE GOD THAM BOOK (clean architecture)

Highlight (pink) - Constantly Improving the Project and the Team > Page 78 · Location 1646

Principle # 10 : Simplicity — the Art of Maximizing the Amount of Work Not Done — Is Essential .

Highlight (pink) - Constantly Improving the Project and the Team > Page 79 · Location 1657

otherwise the team will write code today that they’ll need remove tomorrow when the design changes .

Highlight (pink) - Constantly Improving the Project and the Team > Page 79 · Location 1664

The most destructive thing you can do to your project is to build new code , and then build more code that depends on it , and then still more code that depends on that , leading to that painfully familiar domino effect of cascading changes . . . and eventually leaving you with an unmaintainable mess of spaghetti code .

Highlight (pink) - Constantly Improving the Project and the Team > Page 79 · Location 1666

by building systems that don’t have a lot of dependencies and unnecessary code .

Highlight (pink) - Constantly Improving the Project and the Team > Page 79 · Location 1670

If a feature is not valuable , it’s often cheaper for the company in the long run to not build it at all , because the cost of maintaining the additional code is actually higher than the value it delivers to the company .

Highlight (orange) - Constantly Improving the Project and the Team > Page 79 · Location 1675

Principle # 11 : The Best Architectures , Requirements , and Designs Emerge from Self - Organizing Teams .

Highlight (pink) - Constantly Improving the Project and the Team > Page 80 · Location 1686

A self - organizing team , on the other hand , does not have an explicit requirements or design phase . When a team is self - organizing , it means that they work together to plan the project ( instead of relying on a single person who “ owns ” the plan ) , and they continually come together as a team to revise that plan . A team that works like this typically breaks the project down into user stories or other small chunks , and starts working on the ones that deliver the most value to the company first . Only then do they start thinking about detailed requirements , design , and architecture .

Highlight (pink) - Constantly Improving the Project and the Team > Page 80 · Location 1696

interesting ) . Instead of creating one big design at the beginning of the project that covers all of the requirements , agile architects use incremental design , which involves techniques that allow them to design a system that is not just complete , but also easy for the team to modify as the project changes .

Note - Constantly Improving the Project and the Team > Page 80 · Location 1698

No detail design doc, more just an overview and a general plan. And people can tap into it

Highlight (pink) - Constantly Improving the Project and the Team > Page 80 · Location 1700

Principle # 12 : At Regular Intervals , the Team Reflects on How to Become More Effective , Then Tunes and Adjusts Its Behavior Accordingly .

Highlight (pink) - Constantly Improving the Project and the Team > Page 80 · Location 1708

You need to be comfortable being brutally honest with yourself and your teammates about what’s working and what isn’t .

Highlight (pink) - Constantly Improving the Project and the Team > Page 81 · Location 1711

This makes sense , and almost everyone agrees that it’s a good thing to do .

4. Scrum and Self-Organizing Teams

Highlight (pink) - Page 89 · Location 1882

the team becomes capable of self - organization and can quickly cut through complexity and produce actionable plans . The goal of this chapter is to help you “ get Scrum ” by building on the ideas from Chapters 2 and 3 to teach you the practices and patterns of Scrum .

Highlight (pink) - The Rules of Scrum > Page 89 · Location 1895

Each sprint starts with sprint planning done by the Scrum Master , Product Owner , and the rest of the team , consisting of a meeting divided into two parts , each timeboxed to four hours . The Product Owner’s homework prior to sprint planning is to come up with a prioritized backlog for the product that consists of a set of items that the users and stakeholders have bought into .

Highlight (pink) - The Rules of Scrum > Page 90 · Location 1907

The team holds a Daily Scrum meeting every day . All team members ( including the Scrum Master and Product Owner ) must attend , 2 and interested stakeholders may attend as well ( but must remain silent observers ) . The meeting is timeboxed to 15 minutes , so all team members must show up on time .

Highlight (pink) - The Rules of Scrum > Page 90 · Location 1912

Each sprint is timeboxed to a specific length decided during sprint planning : many teams use 30 calendar days , but this length can vary — some teams choose two - week sprints , some choose one month ( and again , the planning timebox should vary accordingly ) . During the sprint , the team builds the items in the sprint backlog into working software . They can get help from people who are not on the team , but people who are not on the team cannot tell the team how to do their jobs , and must trust the team to deliver .

Highlight (yellow) - The Rules of Scrum > Page 90 · Location 1916

If anyone on the team discovers partway through the sprint that they overcommitted or that they can add extra items , they need to make sure the Product Owner knows as soon as they realize the sprint is in danger .

Highlight (blue) - The Rules of Scrum > Page 90 · Location 1921

Product Owner can terminate the sprint early and initiate new sprint planning if the team discovers that they cannot deliver working software

Highlight (blue) - The Rules of Scrum > Page 90 · Location 1924

At the end of the sprint , the team holds a sprint review meeting where they demonstrate working software to users and stakeholders . The demo may only include items that are actually done done3

Highlight (pink) - The Rules of Scrum > Page 91 · Location 1934

After the sprint , the team holds a sprint retrospective meeting to find specific ways to improve how they work . The team and Scrum Master ( and optionally the Product Owner ) attend . Each person answers two questions : What went well during the sprint ? What can improve in the future ? The Scrum Master takes note of any improvements , and specific items

Highlight (blue) - The Whole Team Uses the Daily Scrum > Page 111 · Location 2316

The project manager needs to scope out the work , often in some sort of business requirements or scope and objectives document . Managers need to sign off on the scope . A business analyst needs to review the scope , then talk to the users and other stakeholders to understand their jobs . The business analyst comes up with use cases , functional requirements , etc . The programmer takes the requirements and generates an estimate . The project manager takes the requirements and estimates , builds out a schedule , and reviews it with stakeholders and managers .

Highlight (pink) - The Whole Team Uses the Daily Scrum > Page 115 · Location 2412

How to Hold an Effective Daily Scrum Act like a “ pig ” During this meeting , every team member is accountable to his or her teammates , and should explain what happened if a commitment that he or she made in the previous meeting wasn’t met . Imagine yourself on a self - organizing team , where you truly feel accountable for the project .

Highlight (pink) - The Whole Team Uses the Daily Scrum > Page 116 · Location 2420

column and choose the one that makes the most sense for you and for the project . If it’s not the right choice , someone else who’s also acting like a genuinely committed “ pig ” will speak up .

Highlight (blue) - The Whole Team Uses the Daily Scrum > Page 116 · Location 2422

Take detailed conversations offline The goal of the Daily Scrum is to identify problems , not solve them . If a problem hasn’t been resolved after a minute or two of discussion ,

Highlight (pink) - The Whole Team Uses the Daily Scrum > Page 116 · Location 2427

Take turns going first There’s no single person who’s the “ keeper ” of the schedule , and there’s no single person who’s more important to the project than anyone else . Obviously , some developers have more expertise than others . But good ideas can come from anyone , and if a junior person on the team has a good idea ,

Note - The Whole Team Uses the Daily Scrum > Page 116 · Location 2431

My current boss has a script that runs and chooses a random person

Highlight (pink) - The Whole Team Uses the Daily Scrum > Page 117 · Location 2442

Everyone participates This includes testers , business analysts , and anyone else on the team — and the Product Owner , too . They’re all genuinely committed . The Product Owner has an especially important job to do because he or she keeps everyone up to date on what tasks in the backlog are most valuable to the users and the company .

Highlight (blue) - The Whole Team Uses the Daily Scrum > Page 117 · Location 2451

Don’t treat it like a status meeting A typical status meeting is a great example of a “ ritual ” that we have to go through every week .

Highlight (yellow) - The Whole Team Uses the Daily Scrum > Page 117 · Location 2456

person in the Daily Scrum is really listening . ( This means not checking email or cell phones , or doing work ! )

Note - The Whole Team Uses the Daily Scrum > Page 117 · Location 2457

How do you make this work? camara.

Highlight (pink) - The Whole Team Uses the Daily Scrum > Page 117 · Location 2459

Inspect every task When you’re looking for roadblocks , don’t just look at what you’re currently doing . Look several moves ahead by examining every item in the “ to do ” column to figure out if any of those items could have an impact . If there’s a potential problem , it’s better to bring it up with the team now and have it dismissed than to keep quiet and get burned

Highlight (pink) - The Whole Team Uses the Daily Scrum > Page 117 · Location 2466

Change the plan if it needs to be changed This is the “ adapting ” part of the visibility - inspection - adaptation cycle , and it’s what puts the teeth in self - organization . Let’s say the team identifies a roadblock during the Daily Scrum ,

Highlight (pink) - The Whole Team Uses the Daily Scrum > Page 118 · Location 2473

Just remember , no matter how badly people will react to the change when they find out about it today , they’ll react even worse if you don’t tell them now , and they find out later .

Highlight (pink) - Sprints, Planning, and Retrospectives > Page 124 · Location 2600

Visibility and Value Think about what motivates you when you’re working . How often has something like this gone through your head at work : “ Working with this technology will look great on my résumé ” ( if you’re a developer ) “ If I prove myself on this project , I’ll get to grow my team ” ( if you’re a team lead ) “ Meeting this big deadline will get me that promotion ” ( if you’re a project manager ) “ If I land that big client , I’ll get a huge bonus ” ( if you’re an account manager , Product Owner , stakeholder , etc . )

Highlight (pink) - Sprints, Planning, and Retrospectives > Page 124 · Location 2609

Here’s a good example of how self - interest can damage a project : let’s say there’s a team member who can dump his uninteresting or irritating tasks on someone else , usually a more junior member of the team .

Highlight (pink) - Sprints, Planning, and Retrospectives > Page 124 · Location 2611

For example , senior developers are often so busy building new software that they put off fixing bugs .

Highlight (pink) - Sprints, Planning, and Retrospectives > Page 125 · Location 2626

Any team ( even non - agile ones ) can try to capture this productivity by setting up rules preventing senior team members from dumping “ boring ” maintenance tasks on junior team members .

Note - Sprints, Planning, and Retrospectives > Page 125 · Location 2627

To be effective Engieers need to fix the bugs that they create otherwise we become less effective. Lets say we have something like Authenticaton Module... Develop by X... Who needs to fix bugs? Jenior to take hours 10+ hours to figure out and then implement NO. Senior who would take 5min to do.

Highlight (pink) - Sprints, Planning, and Retrospectives > Page 125 · Location 2635

On an effective Scrum team , everyone feels a true sense of ownership , not just of the code they build , but of the backlog , and of the work that everyone is doing to deliver working software .

Highlight (pink) - Sprints, Planning, and Retrospectives > Page 126 · Location 2643

Elevating goals motivate everyone on the team Have you ever done volunteer work ? Contributed to an open source project ? Joined a club , or amateur sports team , or rock band , or church choir ? Think about the last time you joined a group outside of your work or your family . Why did you do it ?

Highlight (pink) - Sprints, Planning, and Retrospectives > Page 126 · Location 2665

If you’re out digging ditches , that’s not very elevating or inspiring . But if you’re digging ditches to protect your town that’s about to be attacked by an enemy , well , that’s more inspiring , even though it’s the same activity . And so the leader’s job , really , is to try to determine or frame the activity in such a way that people can understand what the value is . Almost all software is built by teams , not individuals . For a team to work effectively , they need to be motivated together , not just as individuals . Teams are motivated best by elevating goals , which bring them together for a higher purpose that they all care about .

Highlight (orange) - Sprints, Planning, and Retrospectives > Page 127 · Location 2669

Delivering value can be a very effective elevating goal , one that can motivate the whole team . When a team has an elevating goal that they truly believe in , and they’re given the room to decide for themselves how to accomplish it ( and the freedom to take risks ) they will work hard to use the tools they have available to solve any problem standing in the way of that goal .

Highlight (pink) - Sprints, Planning, and Retrospectives > Page 127 · Location 2672

an agile team , value has a very real and specific meaning : software is valuable if it makes your users ’ lives better . What happens if a senior vice president comes down to the team and says this : “ Because of all your hard work over the last few months , we added 0.024 % to our third quarter revenues . Great job , team ! ” That’s not particularly motivating for most developers , not even ones who are paid with stock options .

Highlight (blue) - Sprints, Planning, and Retrospectives > Page 127 · Location 2676

“ Wow , I used to spend three hours every day just sorting through these numbers . Your software is so easy to use and works so well that I can do it all in 10 minutes . Thank you ! ” That’s much more motivating to most developers . Developers — and by “ developers ” we mean all members of an agile team , even ones who don’t necessarily write code — are highly motivated by pride of workmanship .

Highlight (pink) - Sprints, Planning, and Retrospectives > Page 127 · Location 2686

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software .

Highlight (pink) - Sprints, Planning, and Retrospectives > Page 128 · Location 2710

Get everyone talking about value Effective Scrum teams tend to be full of people who understand what their users actually need , and what’s valuable to them . The only way this can happen is if every person on the team understands what it will do for people who use it . How does it make their lives easier ? What does it let them do that they couldn’t do before ? How much time and effort will it save them ? These things really matter to agile developers . The more that you talk about them and make sure that they matter ,

8. Lean, Eliminating Waste, and Seeing the Whole

Highlight (pink) - Gain a Deeper Understanding of the Product > Page 288 · Location 5909

Gain a Deeper Understanding of the Product Perceived integrity means that the totality of the product achieves a balance of function , usability , reliability , and economy that delights customers . Conceptual integrity means that the system’s central concepts work together as a smooth , cohesive whole . Mary and Tom Poppendieck , Lean Software Development : An Agile Toolkit

Highlight (pink) - Deliver As Fast As Possible > Page 295 · Location 6065

Deliver As Fast As Possible There’s one more Lean value : deliver as fast as possible . When you read that , what comes to mind ? Do you think of a pushy boss or project manager prodding the team to work late and get code out the door ? Does “ deliver as fast as possible ” mean cutting out tests , low - priority features , and anything else that is deemed “ extraneous ” or low - priority ? Maybe it makes you think of a heroic developer working late nights and weekends or putting in quick - and - dirty hacks to get an important feature out the door . This is where most managers ’ minds go when they hear the phrase , “ deliver as fast as possible , ” and many developers , testers , and other software engineers think the same thing .

Highlight (pink) - Deliver As Fast As Possible > Page 295 · Location 6079

The purpose of queuing theory is to make sure that people are not overloaded with work , so that they have time to do things the right way . A queue is a list of tasks , features , or to - do items for a team or for an individual developer .

Highlight (pink) - Deliver As Fast As Possible > Page 304 · Location 6158

Keep in mind that plenty of healthy teams usually have many tasks due at the same time but don’t call it “ multitasking ” ; people typically use the term “ multitasking ” in order to mask the fact that the team is simply overloaded . Splitting the work up and telling the team to multitask often keeps you from recognizing that you simply have more work than time , especially when you consider the extra time and cognitive effort required to switch between tasks . For example , a team that already has 100 % of their time already devoted to development work may have a boss with magical thinking who asks them to “ multitask ” and spend several hours a week that they don’t have

Highlight (pink) - Deliver As Fast As Possible > Page 304 · Location 6168

Pull Systems Help Teams Eliminate Constraints And I have a philosophy that I live by . Everybody that works with me knows this ; it’s on the wall : “ If stupid enters the room , you have a moral duty to shoot it , no matter who’s escorting it . ” Keoki Andrus , Beautiful Teams ( Chapter 6 )

Highlight (pink) - Deliver As Fast As Possible > Page 304 · Location 6171

A pull system is a way of running a project or a process that uses queues or buffers to eliminate constraints . This is another concept that originated with Japanese auto manufacturing , but has since found its place in software development .

Note - Deliver As Fast As Possible > Page 304 · Location 6173

best example is : I am building XYZ componenet but I need ethis library - I can pull the library IN

Highlight (pink) - Deliver As Fast As Possible > Page 305 · Location 6182

At the heart of TPS is the idea that there are three types of waste that create constraints in the workflow and must be removed : Muda ( 無駄 ) , which means “ futility ; uselessness ; idleness ; superfluity ; waste ; wastage ; wastefulness ” Mura ( 斑 ) , which means “ unevenness ; irregularity ; lack of uniformity ; nonuniformity ; inequality ” Muri ( 無理 ) , which means “ unreasonableness ; impossible ; beyond one’s power ; too difficult ; by force ; perforce ; forcibly ; compulsorily ; excessiveness ; immoderation ”

Highlight (pink) - Deliver As Fast As Possible > Page 305 · Location 6190

Do any of these things feel familiar ? It takes a very long time to get everyone to sign off on a specification , and in the meantime developers are sitting around waiting for the project to start . Once it does start , they’re already late . It takes management forever to secure the budget . By the time the project is given the green light , it’s already late . Halfway through development , the team recognizes that an important part of the software design or architecture needs to be changed , but that will cause very large problems because so many other things depend on it . The QA team doesn’t start testing the software until every feature is complete . They find a major bug or a serious performance problem , and the team has to scramble to fix it . The analysis and design take so long that by the time coding begins , everyone needs to work nights and weekends to meet the deadline . A software architect designs a large , beautiful , complex system that’s impractical to implement . Even the smallest change to a specification , a document , or a plan needs to go through a burdensome change control process . People find ways to work around the process by putting even sweeping , large - scale changes into a ticketing or bug tracking system instead . The project is running late , so the boss adds extra people to the team for the last few weeks . Instead of making the project go faster , this move creates confusion and chaos .

Highlight (pink) - Deliver As Fast As Possible > Page 308 · Location 6230

Figure 8 - 10 . This value stream map shows the waste that happens when the team is waiting for a large specification to be created and approved .

Highlight (pink) - Deliver As Fast As Possible > Page 309 · Location 6246

Key Points A minimal marketable feature ( MMF ) is the smallest “ chunk ” of value or functionality that the team can deliver , such as a story or a user request — something that might end up on a Product Owner’s backlog ) .

Note - Deliver As Fast As Possible > Page 309 · Location 6248

High Level Design Docs or Doing BIG chunks results in HUGE del\eveloir waiting time. So its better to do a MMF or MVP or whatever you want to call it. and start the high level desing doc as it goes.