Learning agile (book by Stellman & Greene)

Learning Agile

Andrew Stellman & Jennifer Greene

Learning Agile

Agile working practices have become quite trendy over the last few years, but the application of the word agile to these practices dates back to 2001. A group of 17 people active in software development had a meeting and published what they called the “Agile Manifesto ”. This was a set of four values and 12 principles to guide software development. It is worth noting that agile practices were around much earlier than this. This creates some confusion about what is or is not agile, which sometimes misses the point.

The starting point for the authors is the Agile Manifesto because the values and principles describe the mindset behind the practices. A company can adopt some of the practices and get what they call “better-than-not-doing-it” results, but the full value of agile comes from combining practices with mindsets. There is apparently a lot of mixing-and-matching of practices within agile, and specific agile variants use variants of the main values and principles. The book focuses on four subjects: scrum, extreme programming, lean and Kanban. The authors clarify that Kanban is not an agile practice, but is so applicable to agile mindset that it needed inclusion. Equally, lean is not exactly an agile practice, but shares many common features and can also be used in an agile way – so it gets included. The manifesto creators were focused on software development, so it may require some thinking to reapply it to other work. This summary will stick with a focus on software development for the most part.

The foundational mindsets are based on the Agile Manifesto values, which are expanded through 12 principles. The values are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiations
• Responding to change over following a plan

There is an implicit comparison involved in these values. A contrast to agile is something called waterfall project management. Waterfall is a reference to the appearance of a Gantt chart which details every task and emphasizes a comprehensive plan created at the beginning. Waterfall is equivalent to conventional project management. There are many cases where waterfall is superior to agile – and the biggest distinction comes from certainty. Waterfall is a superior approach when the degree of certainty is high. A typical construction project has little uncertainty. A project to develop something for a customer (most design projects) often involves a lot of uncertainty and is better suited to agile.

This the first value says that individuals and there interactions is to be preferred over the processes and tools that might be used in a project. Working software is preferred over documentation (apparently there was/is a lot of written documentation created during waterfall software development that uses developer time and that documentation is mostly about planning).  Probably the biggest difference is the preference for responding to change over following the plan. The real world had shown that customer needs change over time and that customers often did not know what they needed until they saw something else. The ability to change direction as more is learned about what customers want is the source of the agility.

The twelve principles elaborate on these ideas and push them a bit towards operability. Agile is not intended to be a way to create quick and dirty solutions through highly stressful production intensity. Agile is intended to create conditions were teams can be sustainably productive with more time spent on what matters and less on management support.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timeline
4. Business people and developers must work together daily throughout the project
5. Build around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a team is face-to-face conversation.
7. Working software is the primary measure of progress
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility
10. Simplicity - the art of maximizing the amount of work not done - is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams
12. A regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

When learning agile, these values and principles are just as important as the various practices. In fact, some of the major types of agile work have values and/or principles specific to their area. Practitioners use these to help them decide how to adapt practices to their specific circumstances.

SCRUM

One of the major ways to enact agile is called scrum. Scrum is probably the best known agile sub-type and the most likely to be used beyond programming. In scrum a small team works on a set of tasks for a set amount of time. This is called a sprint. Unlike waterfall project management, a sprint has a fixed duration – called a timebox. In general, the duration of timeboxes is about one month, reflecting the desire for early and continuous delivery of usable product. At the beginning of a sprint, the team creates a list of possible tasks/features to be completed. These are called user stories and reflect the features or value that customers will realize from the completed work. When the team starts, the user stories are posted on a document called a sprint backlog. A backlog has three columns: to-do, in progress, and done. At the beginning of the sprint, the user stories/features/tasks go into the to-do column. The team chooses which tasks to move into the in-progress status and the basic approach is to focus on one feature at a time. Rather than move many features that get divided attention, the team picks a few items for focused attention. When an item is complete, it is moved to done and the team picks another feature to move to in-progress.

A scrum team has some specified roles. A Product Owner is a representative of the customer and their main role is to convert customer’s needs or Jobs into user stories and features. The Scrum Master facilitates the team’s activities; the scrum master is not a project manager in the conventional sense. Some team have scrum coaches (who advise on how to operate even better), but not all organizations have coaches. The remainder of the team consists of individual contributors. Scrum teams tend to be small, so large projects may be organized as scrums of scrums. A distinction between a scrum team and a conventional project team can be seen in a concept called chicken or pig. If you think about a breakfast of bacon and eggs, the pig is committed and the chicken is involved. One reason that a scrum team works is that it consists of pigs – not chickens. People who join a scrum team are all-in for the duration of the sprint – there should be no part-time participants. In an organization transitioning to scrum methodology, the role that can be most troublesome is the product owner because they often come from a commercial role and often want to continue to perform multiple organizational roles instead of dedicating to the scrum. 

A myth about agile is that there is no planning. There is probably more dedication to planning with agile than waterfall, but planning is different. First, there is no detailed full-project planning. There may be a vague outline of what an entire project would look like, but nothing more. No longer-term cost, time or task estimates would be created. Second, the whole team does the planning right at the beginning of the sprint, but only for the duration of the sprint. Planning is still not extremely detailed and is more devoted to making sure that people have a common understanding of the intent. The admonition against comprehensive documentation is that documentation may actually foster misunderstanding about the intent – a problem that is paradoxically smaller with less documentation and more team interaction with the product owner (principles 4 & 6). Third, every day starts (or ends) with a scrum meeting which is strictly timeboxed; often called a standup because it is informal and brief enough to complete while standing. This is when the team chooses which features to move from to-do to in-progress. This is a form of detailed planning to – just one that is grounded in the on-going learning of the team. Fourth, a scrum team creates a chart called the burn-down chart at the beginning of the sprint (described in next paragraph) which is updated as features are completed. This allows the team to determine how much more work they can complete before the end of the sprint. The team decides which features need to be pushed to a later sprint (principles 4, 10 and 11) while honoring usability (principle 4). Agile planning is very immediately focused and collaborative. There may be less documentation, and more planning.

A burndown chart takes the user stories and estimates the effort that execution will require for each. This is rarely estimated in terms of people-hours, but commonly uses “points”. Points are somewhat arbitrary, and there are many ways to determine points (see below in commentary). But the simplest way to think about points is in terms of small medium and large efforts. More complicated methods are sometimes used. However points are created, the chart begins with a marker that accounts for all of the points in the sprint. As tasks are completed, their points are subtracted from the total and new markers are added to the chart associated with the elapsed time. The idea is to track how much work remains compared to the time remaining. An example is shown below. The black line indicates the ideal consistent pace of progress – and a team that is on-track will approximately follow the line – a bit above and below from day to day. The dashed red line (Actual 3) shows the progress of a team that is having some trouble. The response of the team should be to begin to identify which stories they are going to push into a later sprint. The green line (Actual 2) shows the progress of a team that is having few problems; they can consider adding more tasks or retiring technical debt (this will be discussed later). Principle 2 says that changing requirements are to be welcomed, and here is an example of an unexpected requirement being added mid-sprint (Actual 1). This adds point back to the backlog, and means that the team will also need to identify items to push into a future sprint (or never do), but not because they are struggling.

A key scrum practice is to define ‘done” during creation of the sprint backlog. What this really means is that an item can’t enter the backlog until its completion criteria are defined. The practice is captured by the phrase “done-done”. If the code is written but not tested – it is not done-done. If the report is written but not filed, it is not done-done.

At the end of the sprint, the team holds a sprint review in which the output of the sprint is demonstrated for the customer – in the case of software a demo is run. This is the proof of being done-done. And then the team holds a sprint retrospective in which they discuss how they can improve for the next sprint. These are both critical activities because they are directed at principles 7 (working software) and 12 (becomes more effective).

To summarize the scrum practices (rules):

• Create a sprint plan as a team
• Focus on what creates value for the customer
• Meet briefly (timeboxed 15 min) daily
• Pay attention to progress
• Manage the work to fit the time
• Quality of work is shown by “working” product
• Review the sprint to drive improvement.

Everyone on a scrum team owns the project. In a conventional project, the project manager or sponsor owns the project. In scrum it is the team. In practice this means that I will do what the project needs even when it is not something that I am good at. If I have “extra” time, I ask who I can help – each person is focused on the team’s output. This is part of why having people on the sprint doing just the sprint is powerful. People are able to dedicate their effort.

This means that everyone owns planning and everyone owns a definition of working. Scrum works when team members are pigs – not chickens. Most stakeholders prefer to be chickens and many organizational practices reinforce chicken-like behavior.  This is a major barrier to successful scrum.

Scrum has five specific values that align with the Agile Manifesto’s, but are distinct.

Commitment – each person is committed to the project’s goals and takes responsibility for the output.

Respect - developing interpersonal respect builds trust and brings all viewpoints into play.

Focus – When a Scrum team member is working on a sprint, that’s his only job for the duration of the sprint. He is free to do whatever work is needed to complete the sprint backlog, and handle any changes that are made to that backlog during the sprint*. Switching between things wastes time and increases the chance of confusion. Not only should a scrum team work on a single project, they should do one task at a time from start to finish within the sprint.

Openness – Scrum teams are small. Everyone should know what everyone else is working on, how it is going, and if help is needed. Scrum artefacts are intended to make everything visible to the team. This also means that the scrum team’s work is visible outside the team – often posted on walls to everyone to see. The authors comment that this is often the hardest hurdle for scrum teams because organizational norms suppress openness. It helps to realize that openness removes an excuse for not knowing what is going on. You know that a teammate needs help. Managers know that stories are being dropped from the backlog. Openness means exposing your own weaknesses and mistakes. When we ask why organizations are not more open, we must consider the personal advantages that come from a less open culture. Scrum teams work best when they are open with each other, with customers and with their own organizations.

Courage – Very few organizations can be purely scrum oriented. There are numerous routine activities unsuited to sprints and this means there will always be tension between the organization and scrum teams. Teams and individuals must stand up to that pressure and carry on in the scrum way. It also requires a kind of courage to believe that a successful team means a successful individual and that that success will be recognized by the organization.

One of the big ideas that applies to scrum involves “the last responsible moment”. The idea is that the many unknowns in development means that early decisions may be wrong given what is subsequently learned. Teams seek to make any decisions at the last responsible moment. Not the last moment, because there needs to be time to enact the decision. This is clearly a judgment call. But this is a distinct contrast to conventional project management that seeks to make as many decisions as early as possible in the name of simplification. Scrum accepts the complexity this involves. The daily scrum allows the team to determine which tasks must be done sooner and which later, and this is done during the course of the sprint; detailed pre-planning is not required. The daily scrum meeting will be more effective if team members:

• Act like a pig
• Take detailed conversations offline
• Take turns going first
• Don’t treat it like a ritual
• All participate
• Don’t treat it like a status meeting
• Inspect every task
• Change the plan if it needs to change

The product owner is an important part of the daily scrum and the ultimate person to say when work is good enough. As a representative of the customer, they were central to creation of the stories and they are central to saying when the product creates value for the customer. In this sense, the product owner can make or break a sprint with their level of engagement. Absentee product owners will doom a sprint.

Not every company has a culture that is ready for scrum. Issues can arise in each of the value areas. Here I’ll list a few samples questions from the book. An organization that thinks these actions are OK is probably ready for agile.

Commitment. Trust the team to decide what gets delivered. Everyone on the team is willing to take responsibility for the outcomes; the blame can’t be assigned to someone else.

Respect Trust the team to manage itself, including self-assigning tasks. Accept that people are working hard so they do not need to be pushed to work harder/longer.

Focus Nobody is asked to do work that is not part of the current sprint during the current sprint. Not asking people on the team to do work that the team does not agree to.

Openness Actually thinking about what others say. Thinking about technical details, if that is not usually your regular role.

Courage The team takes responsibility for poor requirement recognition instead of passing the blame. Building something that isn’t perfect, because what the users need most is something that’s simply good enough.

Maybe a startup can be agile-ready on the first day, but an organization steeped in conventional command-and-control will struggle. Even with the best intentions, old habits will need to be overcome. And this is part of why the values of scrum are important. They refer as much to the process of learning and implementing scrum as to maintaining it in the longer run.

EXTREME PROGRAMMING

Extreme programming (XP) is another set of agile practices and values. XP set out to solve the problem that making changes in software creates flaws (bugs); the more software is changed, the more bugs are created.  Finding and fixing bugs becomes a major loss of time and slows work and completion. XP has 13 practices to cope with change and prevent future problems; some do seem unique to software development, but some seem adaptable to other work. Some of these practices include:

• Test-first programming – the idea is to create a test for the programming before writing the code so that it can be quickly/constantly tested. Tests not only insure that the code works properly, it uncovers dependencies on other code that may create issues. It prevents local success from hiding global failure.
• Pair programming – the idea is that programmers sit together and work on a single piece of code at the same time. One monitor, one keyboard and two people. One benefit is that coding logic is more likely to be clear if two people are looking at it. Another is that errors are caught immediately and corrected. A third is that two minds can come up with solutions to problems faster than one.
• 10-minute build – the idea is to make testing easy enough that it is done easily. When tests are hard or slow, people won’t do them.
• Continuous integration – this involves a practice when parts of code are tested in a copy of the whole code to insure the parts work together as a whole
• Weekly planning cycles – teams work out what they will do in a particular week, using user stories just like scrum.
• Quarterly planning cycles – where the team works out what they will do in the quarter, using user stories just like scrum.
• Slack – XP teams do NOT plan to use the entire time of an iteration developing major new features. They take less important stories, put them at the end of the iteration and insure that everything done at the end of an iteration is “done done”. If minor stories get pushed into the future, the major stories are done.
• Sit together – teams sit by each other so that they consult, communicate and collaborate with each other easily
• Informative workspace – work plans, burndown charts are displayed on walls where all can see them. Information is for the whole team – not just some members.
• Osmotic communication – meetings are held in the common space so that others hear the discussion and can offer their thoughts.

Like scrum, a central premise is that users don’t really know what they need, or they can’t really describe it yet. “They will know it when they see it” is the unfortunate truth. This means that there will probably be many changes and some will be fundamental changes. XP tries to build code in ways that make it easier to change. The real point of short iterations and working software is to enable frequent feedback. Teams do not get too far and too invested in a solution - which makes it easier to change. By sitting together, problems can be solved by the group. Frequent testing reveals problems quickly and helps prevent future problems. The system is set up to promote responsiveness to change.

Using XP practices can give better results, but the results tend to be small. Combining the practices with XP values makes them more effective. Like Agile or scrum, XP has a set of values.

• Communication – everyone knows what everyone is doing
• Simplicity – write as simply and directly as possible
• Feedback – constant testing and feedback insures quality product
• Courage – everyone focuses on the bets outcome for the project
• Respect – every team member is important

Values are more abstract and difficult to apply, but also make practices more effective. People are less likely to selectively use or “cheat” when they understand the values as much as the practices. XP has also adopted a set of principles that make the values more specific.

• Humanity – the work is being done by people
• Economics – someone is paying for all this – keep the budget in mind
• Mutual benefit – practices should benefit everyone involved (individual, team, organization, customer)
• Self-similarity – patterns of work are similar in monthly, weekly and daily scales
• Improvement – do the best work you can right now and try to get better
• Diversity - multiple perspectives make for better solutions
• Reflection – teams reflect on what is/isn’t working
• Flow – constant delivery means continuous flow of development work, not distinct phases.
• Opportunity – every problem is a chance to learn something
• Redundancy – redundancy increases quality – it is not always waste
• Failure – It’s OK to try things that do not work.
• Quality – You can’t deliver faster by accepting lower quality work
• Accepted responsibility – If someone is responsible for something, they need to have the authority to get it done
• Baby steps - don’t make big changes all at once, but take small steps in the right direction

Agile does not work by applying a checklist approach. You need both practices and a mindset for using them. The mindset helps guide people in making decisions about how to use the practices.

Scrum and XP have a number of overlapping elements. Both use backlogs, user stories, monthly/weekly/daily cycles, whole team commitment, openness, focus, respect and courage. While there are some different practices, both have similar values and principles.

A major point of emphasis in XP is building high quality code. The specifics of high quality coding are probably specific to software, but the bigger ideas are interesting. XP strives for simplicity in place of complexity – which tends to mean have one thing do one thing. When one thing tries to do many things – it becomes complex and unpredictable. A second thing is a search for anti-patterns. An anti-pattern is a pattern associated with bad code. If you see this sort of pattern appear, you can expect to have problems in the future.  A major example of an anti-pattern is a “framework”. A framework is a sort of overarching system that is supposed to make everything easier and more consistent – but actually takes up a lot of time and actually ultimately prevents work from actually getting done. This is worth mentioning because organizations often get stalled when somebody decides that there needs to be a framework some work. Everyone stops working waiting for the framework to be completed. This blocks continuous delivery and distracts the team from “working software”.

Prevention of problems is ideal, but in reality problems are not always obvious at the moment that they are being created. Teams can deliver working prototypes that contain excess complexity, latent faults, or incomplete elements. All of these form what is called “technical debt”. A small amount of debt is rarely an issue but as development continues, debt accumulates. Technical debt accumulates metaphorical interest making the debt larger as development continues. This debt becomes crushing. XP teams use slack time to reduce technical debt. While eliminating stories during an iteration ensure on-time completion, using the subsequent slack to find and eliminate technical debt means that future work is more likely to be easy to do (less time finding and fixed problems) and mean that overall completion rates will stay high rather than slow down.

Slack has the further purpose in creating time to think. The book quotes a prominent XP thinker (Kent Beck) who observes, “Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind.” XP iterations are intended to provide a combination of focus and relief that keeps people energized and open to creative problem solving. Many sorts of creative work are slow because it takes time to figure things out. High pressure deadline driven work is more likely to pile up technical debt than good problem solving.

LEAN

Lean describes a set of practices first developed in manufacturing, and specifically the Toyota Production System. The evolution of Toyota’s system occurred over decades and was at the center of what became the quality movement and significant transitions in manufacturing processes well beyond automobiles.

Lean is a mindset with a set of principles. There don’t seem to be specific practices in lean software development comparable to scrum or XP practices. Lean values:

• Eliminating waste
• Amplifying learning
• Deciding as late as possible
• Delivering as fast as possible
• Empowering the team
• Building integrity in
• Seeing the whole

Each value has a set of thinking tools to help act on the values, and each of these values can fairly easily be linked to values and principles in the Agile Manifesto. It is easy to see that Lean strongly influenced the agile creators.

Lean directly emphasizes some issues that differ from Scrum or XP, specifically a focus on waste elimination, seeing the whole, building integrity, and deliver as fast as possible.

Seeing waste is one of the thinking tools. Seven kinds of waste are discussed by the authors.

• Partially done work – until it is done-done, the work to that point has been a waste
• Extra process – the effort that goes into time tracking for status reports is wasted
• Extra features – adding things that nobody asked for is probably wasteful
• Task switching – going from a task to an unrelated task causes cognitive overload and increases the chances for mistakes and delay. Going from one project to another is even worse
• Waiting – time is a non-renewable resource
• Motion – Usually, nothing is happening when something is in motion. There may be a waste of energy or time when something moves from one place to another. The book points out that people who need to walk from one end of the building to the other to ask a question take time away from solving problems (from the perspective of getting out product, this is a waste. From the perspective of personal health and getting the blood moving, this is not a waste).
• Defects –“An ounce of prevention is worth a pound of cure”. Preventing defects saves a lot of effort that might be needed to repair them.

Value stream mapping is a thinking tool to identify waste. In essence, you examine each step of a process for waiting, motion, etc. Some wastes identified are truly one-time events, but recurring sources of waste should be targeted for elimination. Lean teams use measurements to make the subjective observation into objective data. It is much easier for people to take action when there is less doubt about the situation. This is why root cause analysis is a big part of lean; a focus on the real issue instead of the superficial symptom is part of seeing the whole system. A number of charts were developed to help understand how work flows through a value stream. The illustration below shows a three step process for developing a feature. The chart below shows an iteration where work is passing through this value stream. Work enters stage 1, moves to 2 then 3 and is delivered (top chart). The chart (bottom chart) shows the amount of work in each stage on each day across a whole sprint. The team starts on day 1 starting stage 1 on stories, then adds stories on following days as work moves from stage 1 to 2. If mismatches develop, effort can be shifted from one stage to another to keep the process flowing. Though shown as a “final” chart, you must imagine how this chart is built day after day so that team resources are deployed to bottlenecks as they emerge.

Lean’s origin in assembly line manufacturing helped identify three kinds of waste that hinder workflow’ In Japanese these are called muda, mura and muri. Muda relates to futility or idleness. A workflow that leave some people idle at times is wasteful. Mura relates to unevenness or irregularity. A task that swings from unused to being a bottleneck is an example of wasteful unevenness. Finally, muri relates to impossibility or excessiveness. Tasks that are made too difficult are a waste too because they use excess effort to possibly deliver a defective output. On an assembly line it is easy to understand that having workers waiting for work is wasting their potential. If the task these workers must do is very complex (and perhaps irregularly complex), then they will be slow to finish the work. This leads to irregularity in subsequent process steps – which leads to idleness. A process engineer will seek to simplify the complex task, so that the work is done with less effort and in a more timely way. This enables the process to even out and reduce waiting – keeping the system productive. In looking at the value stream above, the intervals between stages represent the potential for unevenness and idleness. In the software world, these might be sign-offs or quality checks. One of the practices from manufacturing that appears in XP is continuous testing because continuous testing removes a possible waste step – quality checking. This paradoxically makes finding flaws easier, removes delays, and keeps the overall flow of work even.

KANBAN

Kanban is a set of practices from lean manufacturing, and is not really an approach to organizing work or agile thinking. It can be applied to a value stream map (or other regular process-like flows) to identify and eliminate bottlenecks. Kanban is about helping a team improve the way they build software. Kanban has three foundational principles:

• Start with what you do now
• Agree to pursue incremental, evolutionary change
• Initially, respect current roles, responsibilities & job titles

Kanban also has a set of core practices

• Visualize
• Limit WIP
• Manage flow
• Make process policies explicit
• Implement feedback loops
• Improve collectively, evolve experimentally

Kanban recognizes that we are mostly ruled by habits. And that we may be unaware of those habits. So the first thing to do is to understand the current situation – and visualization is a powerful way to express the current situation. A value stream map is a visualization, but some processes might be visualized better with different diagrams. A Kanban board is a typical visualization (see below). It is important to map what really happens – not what is supposed to happen. We rarely actually do anything for the first time. We fit our work into established patterns, so there is almost always a process. This is why there is a practice for making practices explicit.  Most systems work fairly well, so it makes no sense to make big changes quickly. Instead, the team can do small experiments that lead to changes that accumulate over time. People are important components of the process and changes to roles and responsibilities should be introduced in the same incremental way. Kanban can result in quite radical change, but such a result arises from the accumulation of change – not a single big shift.

The practice of limiting WIP does not exactly exist in scrum or XP. WIP is work in progress. This practice is related to managing flow and making process policies explicit. A process policy is essentially a step in the work process. A team creates the visualization of the policies in the form of a Kanban board which is a board with a series of columns; one for each process step. In the illustration below, a seven step process has tasks at different stages of execution. There is clearly a bottleneck at step 5. The principle of limiting WIP would set up a rule that prevents work from piling up in step 5. For example, the rule might be that WIP at 5 can be 3 of less. The team, seeing that step 5 has 3 items already would not work on items in step 4, but would work on items in 1, 2 or 3. In many cases, the sort of bottleneck shown is at the boundary between functions, so it is not a situation where the team can shift their attention to items in 5 to clear them. But if the team could deal with these issues, the result would still be that they do not allow work to increase in step 5 until there is capacity in that step (2 or less would represent open capacity). By limiting WIP, the team creates evenness (a lean principle), manages flow (a Kanban practice) and makes a process policy explicit (Kanban).

The congestion visible in step 5 is a feedback loop when combined with a WIP limit. When the limit is reached, this is a signal to the team to work on items not in step 4 and a signal to the people tasked with step 5 to intensify their effort. A common example of step 5 bottleneck is manager review process to accept the work done. If the managers meet infrequently, then they will see that they need more frequent meetings to prevent the bottleneck. To be effective, a board like this needs to be visible to all involved.

One the purposes of Kanban is to even out flow, and some teams uses this evenness to establish a flow. Instead of working to a time-box, they work to a cadence. They do a release every 6 weeks for example. In order to even out flow even more, teams will install a step just for slack, which helps them eliminate technical debt and maintain their cadence. This kind of “always behind, always rushed” atmosphere leaves little or no room for creativity, and then stifles innovation at every turn. It also kills quality practices, because teams feel like they’re running behind will often cut out any activity that doesn’t directly produce code. This is why XP teams include slack in their primary practices. Smoothing out the work and including slack decreases the rushed feeling which combines with dedicated slack time to increase quality.

Over all of these agile and agile-adjacent approaches, one of the hardest things to introduce is the centricity of teams managing themselves. It is tempting for a product owner or scrum master to think they are “in charge” of the team. Teams in most organizations are used to being told what to do and it takes a while for them to adapt to self-management. People placed in roles like product owner, scrum master or coach need to resist the temptation of telling the team what to do.  

Comment and interpretation:

• Agile as a type of organization may date to 2001, but agile methods are much older. Arguably, the Empire State Building was built in 1931 using agile methods (https://blog.usejournal.com/agile-isnt-new-it-s-just-common-sense-rebranded-d4238a40c800). Construction took 13 months and was effectively built in modules. What the agile manifesto drafters did was to give these practices a framework.
• The book combines description, instruction, and “stories” to illustrate the concepts and application to improve learning. It is deliberately repetitive to improve retention. This is quite effective.
• The book notes that many companies have imported specific agile practices or a subset of the values and principles. Some have taken some of the jargon and applied it to existing practices. Numerous blogs describe the negative consequences when practices are applied without values – in particular when managers believe that agile inevitably leads to speed. The book repeatedly makes clear that speed in many senses is an illusion caused by a switch in emphasis from a final, perfect product to an immediate functional, imperfect product. Agile sounds good and executives can sound progressive by shifting towards agile methods. Like all such systems, misapplication can harm employees, customers and the company.
• Personally, I plan to eliminate the use of the word sprint from my agile vocabulary in favor of iteration.
• Over the last few decades, there has been an on-going contest between multitasking and focus. In general, multitasking has been “winning” this battle with more and more ways for others to break your focus. There is plenty of evidence to suggest that multitasking decreases effectiveness and efficiency (any possible gains from multitasking are illusions). The idea of being a “pig” going “all in” comes from the focus side of this argument.
• One consequence of the idea of lean organizations is that people are expected to wear many hats and switch them quickly. This seems agile, but clearly agile (or lean) does not refer to that. Agile may not apply to every person in an organization. Many roles deal with highly predictable work and agile brings no benefits to this work compared to conventional project management or conventional administrative management. But for some parts of the organization, agile works better and people need to switch to wearing one hat at a time. You are on an iteration (sprint) or you are not.
• The increased in distraction technology led to increased study of the cost of distraction. It is significant. Various studies suggest that a short distraction can prevent full attention from returning for 15-20 minutes. I can say from my life of lab work that it takes a day or two to adapt to the lab after a period of office work, and when you try to do two experiments at once, you will make mistakes in (at least) one of them. Multitasking creates the illusion of efficiency – as long as you do not account for the cost of rework.
• Years ago I worked on a pretty “tight” team. We made decisions together and accepted success and failure together. I was having an annual review and my boss at the time interrupted my explanation of results to ask me what I had done. I was saying we, we, we and not explaining what I had done. His job was not to judge the team’s contribution, but mine. In the sense that American business culture is REALLY individually oriented, scrum values are un-American.
• If a big project is using scrum, it is probably best to create a series of small scrum teams instead of one big one. Find a way to sensibly divide the work into smaller sprints. Each sprint team operates somewhat independently. They have a daily scrum meeting and the whole team has a scrum of scrums daily meeting that is also time boxed.
• Story points can be done in many ways and it takes some time to get calibrated. In the beginning most teams pick an “average” piece of work and give it an intermediate number of points. They then compare other tasks and assign points accordingly. Some teams use a linear (1, 2, 3…), some use geometric (1, 2, 4, 8 … or 1, 3, 9 …) and some use Fibonacci (1, 2, 3, 5, 8, 13 …) series to assign points. In other words, points are relative to an arbitrary value. Over time, these points can be standardized within a team and if some well know reference activities are use – across an organization. Then if point inflation is prevented, the team can measure “velocity” and determine if they are getting more effective over time. It takes a while to reach this level of consistency so don’t worry about velocity for some time.
• In a business where innovation projects seem to be late, there is an attraction to installing professional project managers who bring discipline and planning to bear on the work. This probably works best when the work is nearly routine and the team can be dedicated to the single task. It breaks down when the work is unpredictable, the team and project manager are spread across multiple projects. I think agile would diagnose this as a chicken-and-pigs issue. When the team is focused on one thing – conventional project management and managers work better too.
• Fun fact: One of the first programming teams that started using the daily meeting approach had many members who played rugby. Standing around in a circle talking about what to do reminded them of their favorite game and they called these meetings scrums. The whole sub-type took the name. There are many things in agile that are artifacts of history – not so-called logic. It is rather human in that way. It is easy to understand sprint in a rugby context too – you can’t sprint continuously or you won’t be capable as the game goes on. The idea of sprint-sprint-sprint leads to burnout, mistakes, and slow down. Rugby is a game of intervals, and sprints are one phase of working.
• I just realized that I have done some XP. Back when personal computers were new, I wrote a simple basic program for my children to practice arithmetic. They had to do a number of problems and if they got the correct answers, “good” music was played. If they fell short, “bad” music played. I used test-first programming in that I wrote the code for the music first and then the code for the problems. I could then test my software by trying a few questions to prove that the outcome matched the music. My children hated the “bad” music and we did not need to check on them to know they had finished their work.
• In almost any mindset/framework/method, an attitude develops over time about “The right way” to do things. This is certainly detectable on line. What most online complaints focus on is the failure of organizations to retain the values. What seems absent is complaints about blending of practices. Organizations and teams seem to mix and match practices – using practices mostly from one type of agile, but with a few practices from another type. There is a “subway” map that shows links between them. For me, the point is that there are a series of values to absorb and use, but with those in place – pick practices that help get the work done and keep the people strong.
• Technical debt appears in other contexts too. Here is an interesting post that describes the consequences of technical debt at Chernobyl. https://medium.com/better-programming/chernobyl-the-true-cost-of-technical-debt-8307e6f4d53c .
• It is probable that the aphorism “Necessity is the mother of invention” has been misunderstood. It is often framed as creating the urgency to act. But it is easily observed that people do foolish, stupid things under pressure or in chaotic situations. Training of many kinds of “responders” is focused on understanding the behavior of people in tense situations (burning house, drowning, etc.) and avoiding those behaviors while helping. An alternate perspective on the phrase is that it is the absolute requirements of the situation that lead to good problem solving – being focused on what is really needed. A user story should express what is really needed. This leads back to the question of focus and relaxation. A team will probably produce their best, high quality work quickly when they are focused on the problems and its constraints, and are not feeling pressure to perform quickly. Just because a few people seem to perform well under pressure does not mean that they perform best under pressure. Pressure does not create conditions for better work – it creates technical debt.
• In the book’s section on Kanban, the merits of very frequent reviews are discussed. There seems to be a problem with constant feedback that seems similar to too infrequent feedback. Too much and tool little feedback both inhibit progress. I think this has some interesting implications for ideas about co-development or rapid prototyping. Should the customer only see every 3^rd to 5^th prototype so that the team can advance further between feedback sessions? If the customer is part of the development team, does this problem disappear? In other words, is it external feedback that needs to find the right cadence?

*Text in italics is directly quoted from the book