Learning Agile: Understanding Scrum, XP, Lean, and Kanban - Andrew Stellman :: Andree Huk

My recommendation: 9/10

→ Read or listen on Scribd.com (2 months free with this link) or use a direct link! (without 2 free months)

Summary of notes and ideas

“When everyone on a team is in the habit of constantly refactoring, they build a codebase that is much easier to change. When the team members discover that they need to implement a new story, or more commonly, they discover that they misunderstood one of the stories and have to change the code, it’s much easier to make the change to the code. "

“This is also why XP teams use iterative development, and why they include the quarterly cycles and weekly cycles among their primary practices. They give themselves enough time in every weekly iteration to account for building unit tests and do refactoring. And each delivery of working software helps the team work with their users to improve their understanding of the problem being solved and refine the stories.”

“At its core, incremental design is about making code design decisions at the last responsible moment, avoiding one of the most common traps that developers—even advanced, highly skilled developers—fall into: trying to build everything at once.”

“If every team member is trusted to make coding decisions that will deliver the most value, then there’s little risk of individual programmers spending extra time building extra code that doesn’t accomplish the goal.”

“They integrate continuously, so when one pair injects a defect that affects a different part of the software it causes unit tests to fail fast. This lets the team fix code problems quickly and before those problems are buried under additional layers of code, which leads to a cleaner codebase. Continuous integration is made easier because they have a 10-minute build, which also makes it easier for the team to focus and have fewer interruptions.”

“When a system is designed so that its behavior seems to emerge from the interactions between the individual units working together, in a way that doesn’t seem to originate from one single unit, it’s called emergent design. Systems built using emergent design almost always consist of small, independent, decoupled units (like Unix tools, or ants). Those pieces are combined to perform complex tasks, and the behavior of the system comes as much from the interactions between those units as it does from the individual units themselves.”

“Teams that are good at XP have the tools to keep the codebase simple, and they work in a way that encourages them to continually monitor the code for complexity and refactor it out. This in turn lets them comfortably make changes, which allows more design to emerge. It’s a virtuous cycle that leads to simple, stable, very high quality code—and, as a result, teams find that it’s much faster to build and maintain software this way. When the system needs to be maintained (to fix a bug, or to make a change), there’s rarely a large, overarching modification that touches many different parts of the code.”

“It’s worth repeating the main idea here: bosses often have a tendency to demand commitment, and teams often have a tendency to overcommit”

“It shouldn’t take you more than half an hour to build a value stream map for your project. Here’s how to do it. Start with a small unit of value that the team has already built and delivered to the customers or users. Try to find the smallest unit possible—this is an example of a minimal marketable feature (MMF), or the smallest “chunk” of the product that the customers are willing to prioritize. Think back through all of the steps that the unit went through from inception to delivery. Draw a box for every one of these steps, using arrows to connect the boxes.”

“Next, estimate how much time it took to do the work for the first step, and how much time elapsed before the next step to start. Repeat this for each of the steps, and draw lines underneath the boxes to represent the work and wait times.”

“How would you work with the team to get them to respond to the most important requests more quickly? Let’s say that you try to confront the team, but they point to their positive status reports and tell you that the project is going just fine for them. How do you get them to see the problem? An objective measurement can help with this. Many teams will measure lead time for each feature. This is a measurement of the average time elapsed between when a feature is requested and when it’s delivered.”

“Lean takes this idea further by giving us three thinking tools to help teams deliver as fast as possible: pull systems, queuing theory, and the cost of delay.”

“One of the ideas behind the theory of constraints is that a particular constraint (like work piling up behind an overburdened team) limits the total amount of work that can get through the system. When the constraint is resolved, another constraint becomes the critical one. The theory of constraints tells us: every overloaded workflow has at least one constraint. When a constraint causes work to pile up at a specific point in a workflow, people will often call it a bottleneck. Removing one bottleneck from the system—maybe by changing the process or adding people—will cause work to flow more smoothly.”

“The chart will show us how many MMFs were in progress on any date, and how those MMFs broke down across the various value stream stages. The work in progress is a measurement of features, not tasks. In other words, it shows the number of features or parts of the product that are being worked on, not the specific tasks that the team does to produce them.”

“The cost of delay became important: if a part was in short supply, a delay in getting that part to the assembly line was very expensive; if the part was abundant, the cost of delay was low.”

“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”"

“Were there things you had to do that were futile, useless, or superfluous? This is muda—work you had to do that didn’t add value. What about times when you were sitting around idle, anxiously waiting for someone to get back to you so you could get your work done? This is mura—unevenness, or work that happens in fits and starts. Those times that you had to stay late or work weekends because you were expected to do more work than was humanly possible? That’s muri”

“Kanban is not a software development lifecycle methodology or an approach to project management. It requires that some process is already in place so that Kanban can be applied to incrementally change the underlying process. Kanban is a method for process improvement used by agile teams. Teams that use Kanban start by understanding the way that they currently build software, and make improvements to it over time”

“Kanban: “The Kanban Method introduces a complex adaptive system that is intended to catalyze a Lean outcome within an organization.” There are teams that apply Lean and lean thinking to software development without using Kanban, but Kanban is by far the most common—and, to many agile practitioners, the most effective—way to bring lean thinking into your organization. Kanban has a different focus from agile methodologies like Scrum and XP.”

“Kanban is about helping a team improve the way that they build software. A team that uses Kanban has a clear picture of what actions they use to build software, how they interact with the rest of the company, where they run into waste caused by inefficiency and unevenness, and how to improve over time by removing the root cause of that waste.”

“They have work items. A work item is a single, self-contained unit of work that can be tracked through the entire system. It’s typically larger than an MMF, requirement, user story, or other individual scope item. One difference between a task board and a kanban board is that while tasks flow across a task board, work items are not tasks. The tasks are what the people do to move the work items through the system. In other words, the tasks are the “cogs” of the machine that push the work item through. "

“The columns on the kanban board may seem similar to steps in a value stream; however, many Kanban practitioners distinguish value stream maps from kanban boards. They will map the state of work items in the workflow separately from the value stream, something that they call workflow mapping. The difference is that value stream mapping is a Lean thinking tool to help you understand the system that you work in; workflow mapping is how the Kanban method determines the actual steps that each work item goes through. "

“When a team wants to adopt Kanban, the first thing that they do is visualize the workflow by creating a kanban board. For example, one of the first kanban boards in David Anderson’s book, Kanban, has these columns: Input Queue, Analysis (In Prog), Analysis (Done), Dev Ready, Development (In Prog), Development (Done), Build Ready, Test, and Release”

“In general, you should never copy another kanban board; rather, you should develop your own by studying your own workflow and visualizing it. Copying an existing process definition out of context would be the antithesis of the Kanban Method’s evolutionary approach to change.”

There is no hard-and-fast rule that says how large the WIP limit should be; instead, teams will take an evolutionary approach to setting WIP limits” Added on 08/01/2020 | 8:30

“Key Points

Kanban is a method for process improvement, or a way to help teams improve the way they build software and work together as a team, that’s based on the Lean mindset.
Kanban teams start with what you do now by seeing the whole as it exists today, and pursue incremental, evolutionary change to improve the system gradually over time.
The Kanban practice improve collaboratively, evolve experimentally means taking measurements, making gradual improvements, and then confirming that they worked using those measurements.
Every team has a system for building software (whether or not they recognize it), and the Lean idea of systems thinking means helping the team understand that system.
A kanban board is a board way for Kanban teams to visualize their workflow.
The kanban board has columns that represent each”

“But how do you know that you’re actually increasing flow when you add WIP limits? Once again, we can go back to lean thinking, which tells us that we should take measurements—and an effective tool for measuring flow is a cumulative flow diagram, or CFD. A CFD is similar to a WIP area chart, with one important difference: instead of flowing off of the diagram, the work items accumulate in the final stripe or bar.”

“Setting WIP limits for every column on the kanban board helps the team maximize flow throughout the entire project.”

“Teams can also write down their policies by adding “definitions of done” or “exit criteria” bullets to the bottom of each column on a kanban board, so that the team members know exactly when to advance the work items through the workflow.”

“This is why Kanban looks at the entire system in aggregate. Instead of trying to micromanage every little activity, a team using Kanban uses systems thinking to understand, measure, and incrementally improve the system as a whole. They accept the fact that individual work items will vary, but the system as a whole acts predictably when unevenness, overburdening, and futility—muda, mura, and muri—are reduced.”

“Key Points

One goal of a Kanban team is to maximize the flow, or the rate at which work items move through the system.
The Kanban practice measure and manage flow means taking measurements of the flow and making adjustments to the process to reach maximum flow.
A cumulative flow diagram (or CFD) is a WIP area chart that also shows the number of work items added to the workflow every day (arrival rate), the total number of work items in the workflow (inventory), and the average amount of time each work item stays in the system (lead time).
When the arrival rate and inventory do not change over time, the system is stable; Kanban teams set WIP limits to stabilize the system.
When a system is stable, Little’s Law applies, which means that the average lead time is always equal to the long-term arrival rate times the long-term inventory.
If your team can stabilize the workflow with WIP limits, you can reduce the lead time for your users by”

“Limiting WIP and controlling queue sizes reduces variability. Highlighting sources of delay and techniques like blocker clustering (or root-cause analysis and improvements designed to reduce the likelihood and impact of blockers) reduces variability. Attacking sources of variability that adversely affect the economic outcome and the risk management of the system is a core technique in Kanban.74”

“So if you already have a mindset that’s compatible with the agile methodology you’re trying to adopt, you’re much more likely to have a successful adoption.”

“The job of coaching is to help teams to change, and change can cause an outsized—but entirely rational—emotional response from the people being asked to change. Why? Because work is how you pay for your life and feed your family.”

“The coach needs to give that person context for the change, so they understand why (and not just what). This helps the team actually change the way they work, rather than simply taking the name of something from an agile methodology and attaching it to a practice that they already do.”

“A martial arts student progresses through three stages of proficiency called Shu Ha Ri. Shu: Follow the rule. Ha: Break the rule. Ri: Be the rule. "

“There’s an old saying about teaching: meet them where they are, not where you want them to be. A good agile coach understands how people learn, and presents them with information, guidance, and examples to help them reach their next stage in learning. Coaches understand that people don’t change overnight.”

“In Agile Software Development: The Cooperative Game, Alistair Cockburn talks about a basic idea of learning called shuhari, and it’s a very valuable tool for a coach trying to figure out where the team is. Shuhari is adopted from martial arts, but it’s a good way to think about how people learn about almost anything.”

“Agile zealots tend to focus only on the rules that they’ve learned, and stop at the shu level. They believe every problem that they encounter can be solved with a rule that they already know and preach. Agile zealots do not make good coaches because they don’t take the time to understand where the people that they’re coaching are in their learning.”

“Scrum is full of shu-level rules (“meet every day and answer these three questions”); this is one reason that teams find a lot of success in adopting its practices. Values like openness and commitment, on the other hand, are ha-level ides: abstract concepts that govern how you employ rules in a system. Self-organization and collective commitment happen only when everyone on the team has really understood and internalized those values.”

“Let the team fail: Certainly, don’t stand idly by while the team goes careening off a cliff. But do use the dozens of opportunities that arise each sprint to let them fail. Teams that fail together and recover together are much stronger and faster than ones that are protected. And the team may surprise you. The thing you thought was going to harm them may actually work for them. Watch and wait.”

“One of the more difficult parts of an agile coach’s job is to figure out just how much of this to explain to the team, the boss, and the customers. A simple shu-level explanation of the rules of a methodology is enough to get the job done, but not enough to help the team get into the right mindset to get better-than-not-doing-it results.”

“Key Points

An agile coach is someone who helps a team adopt agile, and helps each individual person on the team learn a new mindset.
Effective agile coaches help teams get past their discomfort with new practices by focusing on the part of the practice that feels familiar.
Coaches recognize the warning signs that teams are uncomfortable with change.
People learn new systems or mindsets in three stages called shuhari.
Someone who encounters an idea for the first time is in the first stage, shu, where she’s still learning the rules—she often responds best to specific instructions.
The ha stage is where someone starts to recognize the larger system, and has adapted his mindset to match it.
In the ri stage, people are fluent with the ideas of”

“Agile, as a movement, is different from any approach to software development that came before it, because it started with ideas, values, and principles that embody a mindset”

“What people deliver will often vary based on what they’re focused on. The more people focus on their own goals, and not on the goals of the team, the less likely it’s going to be that what they deliver has real value for the company.”

“The 12 Principles of Agile Software

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Businesspeople and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity—the art of maximizing the amount of”

(Not all notes are shown here)

→ Read or listen on Scribd.com (2 months free with this link) or use a direct link! (without 2 free months)

Twitter Reddit LinkedIn Facebook