Clean Agile – book summary

This post’s just my takeaways after reading Clean Agile by By Robert C. Martin I’m sure if you will read the book you will have a different point of view so I would recommend reading the book after reading my summary.
Who Should Read It? I would say that every IT professional should read Clean Agile by By Robert C. Martin at any point when it’s interacting with AGILE or wanna expand his knowledge so let’s give a start.

Chapter 1 Introduction to Agile

• Big things don’t get done by big teams; big things get done by the collaboration of many small teams doing many small things.
• The idea of choosing small intermediate goals and measuring the progress after each is just too intuitive and too human, to be considered any kind of a revolution.
• Agile development is first and foremost a feedback-driven approach.

Top values

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

Good, fast, cheap, done.

The reality is that a good project manager understands that these four attributes have coefficients. A good manager drives a project to be good enough, fast enough, cheap enough, and done as much as necessary.

1. Team’s velocity chart
2. Burn-down chart

We should be sizing the project and doing basic feasibility and human resources projections. We should be ensuring that the schedule is achievable.

Analysis and design are not binary deliverables. They do not have unambiguous completion criteria. There’s no real way to know that you are done with them. So we might as well be done on time, but implementation actually has to be done.

The thing about the Waterfall idea is that it just makes so much sense. First, we analyze the problem, then we design the solution, and then we implement the design.

An Agile project begins with analysis, but it’s an analysis that never ends.

Sprint is the term used in Scrum. I dislike the term because it implies running as fast as possible. A software project is a marathon, and you don’t want to sprint in a marathon.

The first iteration, sometimes known as Iteration Zero, is used to generate a short list of features, called stories.

In an Agile project, we are always analyzing and designing.

Iteration one begins with an estimate of how many stories will be completed. At the end of the iteration, some fraction of the stories that we had planned to finish will be done. This gives us our first measurement of how much can be completed in an iteration. This is real data.

Hope is the project killer. Hope is what makes a software team mislead managers about their true progress.

The only way to go fast, is to go well.

• The Planning Game practice plays the central role of this ring. It tells us how to break down a project into features, stories, and tasks. It provides guidance for the estimation, prioritization, and scheduling of those features, stories, and tasks.
• Small Releases guides the team to work in bite-sized chunks.
• Acceptance Tests provide the definition of “done” for features, stories, and tasks. It shows the team how to lay down unambiguous completion criteria.
• Whole Team conveys the notion that a software development team is composed of many different functions, including programmers, testers, and managers, who all work together toward the same goal.

The middle ring of the Circle of Life presents the team-facing practices. These practices provide the framework and principles by which the development team communicates with, and manages, itself.

• Sustainable Pace is the practice that keeps a development team from burning their resources too quickly and running out of steam before the finish line.
• Collective Ownership ensures that the team does not divide the project into a set of knowledge silos.
• Continuous Integration keeps the team focused on closing the feedback loop frequently enough to know where they are at all times.
• Metaphor is the practice that creates and promulgates the vocabulary and language that the team and the business use to communicate about the system.

The innermost ring of the Circle of Life represents the technical practices that guide and constrain the programmers to ensure the highest technical quality.

• Pairing is the practice that keeps the technical team sharing knowledge, reviewing, and collaborating at a level that drives innovation and accuracy.
• Simple Design is the practice that guides the team to prevent wasted effort.
• Refactoring encourages continual improvement and refinement of all work products.
• Test Driven Development is the safety line that the technical team uses to go quickly while maintaining the highest quality.

These practices align very closely with the goals of the Agile Manifesto in at least the following ways:

• Individuals and interactions, over processes and tools: Whole Team, Metaphor, Collective Ownership, Pairing, Sustainable Pace
• Working software over comprehensive documentation: Acceptance Tests, Test Driven Development, Simple Design, Refactoring, Continuous Integration
• Customer collaboration over contract negotiation: Small Releases, Planning Game, Acceptance Tests, Metaphor
• Responding to change over following a plan: Small Releases, Planning Game, Sustainable Pace, Test Driven Development, Refactoring, Acceptance Tests

The Reasons for Agile

Software is a compound word. The word “ware” means “product.” The word “soft” means easy to change. Therefore, the software is a product that is easy to change.

Agile development is important for much deeper philosophical and ethical reasons. Those reasons have to do with professionalism and the reasonable expectations of our customers.

• Professionalism
• Software Is Everywhere
• We Rule the World
• We Will Not Ship Shyt!
• Continuous Technical Readiness
• Stable Productivity
• Inexpensive Adaptability
• Continuous Improvement
• Fearless Competence
• QA Should Find Nothing
• Test Automation
• We Cover for Each Other
• Honest Estimates
• You Need to Say “No”
• Continuous Aggressive Learning
• Mentoring

I think it’s fair to say that any system that requires its users to think like programmers in order to enter data in the expected format is crap.

Note that Agile’s emphasis on Testing, Refactoring, Simple Design, and customer feedback is the obvious remedy for shipping bad code.

The cause of such delays is often the attempt to build all features simultaneously instead of the most important features first. So long as there are features that are half done, or half tested, or half documented, the system cannot be deployed.

So every test that can feasibly be automated must be automated.

Customer Bill of Rights

The customer bill of rights includes the following:

• You have the right to an overall plan and to know what can be accomplished when and at what cost.
• You have the right to get the most possible value out of every iteration.
• You have the right to see progress in a running system, proven to work by passing repeatable tests that you specify.
• You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs.
• You have the right to be informed of schedule and estimate changes, in time to choose how to reduce the scope to meet a required date. You can cancel at any time and be left with a useful working system reflecting investment to date.

Developer Bill of Rights

The developer’s bill of rights includes the following:

• You have the right to know what is needed with clear declarations of priority.
• You have the right to produce high-quality work at all times.
• You have the right to ask for and receive help from peers, managers, and customers.
• You have the right to make and update your own estimates.
• You have the right to accept your responsibilities instead of having them assigned to you.

So this right only applies within the context of an iteration. Outside of an iteration, requirements and priorities will shift and change. But within an iteration the developers have the right to consider them immutable.

Business Practices

Planning

An estimate is a guess; we want some idea of how long the project will take without actually building the project. We want the cost of estimation to be low. Therefore an estimate is, by definition, imprecise. The imprecision allows us to shorten the time necessary to create the estimate. The more imprecision, the less time the estimate will take.

One technique that works quite well for large tasks is trivariate estimation. Such estimates are composed of three numbers: best-case, nominal-case, and worst-case. These numbers are confidence estimates. The worst-case number is the amount of time within which you feel 95% confident that the task will be completed. The nominal-case has only 50% confidence, and the best-case only 5%.

For example, I am 95% sure that the task will be completed within three weeks. I am only 50% sure that it will be completed in two weeks. And I am only 5% sure that it will be completed within one week.

Another way to think about this is that, given 100 similar tasks, five of them will be done within one week, 50 will be done within two weeks, and 95 of them will be done within three weeks.

https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique

At this point, you may be wondering what these points are really measuring. Perhaps you think they are hours, days, weeks, or some other unit of time. They are not. Rather, they are a unit of estimated effort, not real time. They are not even estimated time—they are estimated effort.

https://en.wikipedia.org/wiki/Law_of_large_numbers

Iteration Planning Meeting (IPM). This meeting should be scheduled to be one-twentieth the duration of the iteration. The IPM for a two-week iteration should require about a half a day.

Now the stakeholders play the four-quadrant game

This is a return on investment (ROI) calculation. It’s not made formally, and no math is necessary. The stakeholders simply look at the card and make a judgement based on its value and its estimated cost. The stakeholders scan the deck of stories for those that have the highest bang for buck, the highest ROI. When they find enough to add up to 30 points, they stop. That’s the plan for the iteration.

So, let’s call the midpoint review meeting. It’s Monday morning, the first day of the second week of the iteration. The team gathers with the stakeholders, and they look at the progress.

Uh oh, the completed stories only add up to 10 points. With only a week left, it’s not likely that they are going to get 20 more points done. So the stakeholders remove enough stories from the plan to reduce the remaining points to 10.

On Monday, when the next iteration begins, how many points should the stakeholders plan for? Eighteen, of course. This is called yesterday’s weather. The best predictor of today’s weather is yesterday’s weather. The best predictor of the progress of an iteration is the previous iteration.

The project is not over when all the stories are implemented. The project is over when there are no more stories in the deck worth implementing.

Refactoring is never a story. Architecture is never a story. Code cleanup is never a story. A story is always something that the business values. Think of a story as a thin vertical slice through the horizontal layers of the system.

Stories

Stories follow a simple set of guidelines that we remember with the acronym INVEST.

• I: Independent. User stories are independent of each other. This means that they do not need to be implemented in any particular order. Login does not need to be implemented before Logout.
• N: Negotiable. This is another reason why we don’t write down all the details. We want those details to be negotiable between the developers and the business.
• V: Valuable. The story must have clear and quantifiable value to the business.
• E: Estimable. A user story must be concrete enough to allow the developers to estimate it.
• S: Small. A user story should not be larger than one or two developers can implement in a single iteration.
• T: Testable. The business should be able to articulate tests that will prove that the story has been completed.

https://en.wikipedia.org/wiki/Wideband_delphi

• Story Estimation Flying Fingers. Shirt Sizes Planning Poker Zero means, “Too trivial to estimate.” Be careful with those! You may wish to merge a few of them into a bigger story. Infinity (∞) represents too big to estimate, and therefore the story should be split. And (?) means you simply don’t know, meaning that you’ll need a spike.

Splitting stories is a bit more interesting because you need to maintain INVEST. As a simple example of splitting a story, consider Login. If we wanted to split it into smaller stories, we could create Login with No Password, Login with Single Password Attempt, Allow Multiple Password Attempts, and Forgot Password.

A spike is a meta-story, or rather, a story for estimating a story. It is called a spike because it often requires us to develop a long but very thin slice through all the layers of the system.

It is far better to get 80% of the stories done than it is to get each story 80% done. Focus on driving the stories to completion.

If QA continues to miss the midpoint deadline, one iteration after another, then the ratio of QA engineers to developers is likely wrong.

So, the only thing we ever want to report on our velocity chart is stories that have passed their acceptance tests.

The lesson here is that velocity is a measurement not an objective. It’s control theory 101: don’t put pressure on the thing you are measuring.

As velocity falls, pressure on the team builds. This causes the points to inflate. That inflation can hide the falling velocity.

Remember that Login was our original Golden Story, and it was estimated as 3. If a new story such as Fix Spelling Error in Menu Item has an estimate of 10, you know that some inflationary force is at work.

If you are releasing every six months, try every three months, then try every month, then try every week. Keep shortening the release cycle in an asymptotic approach to zero.

This is the practice of Acceptance Tests. The practice says that, to the degree practicable, the requirements of the system should be written as automated tests.

A story is not specified until its acceptance test is written. A story is not complete until its acceptance test passes.

Who else can benefit from defects? There’s a saying among older programmers: “I can meet any deadline you set for me, as long as the software doesn’t have to work properly.” So who else benefits from defects? Developers who need to meet schedule deadlines.

QA writes the acceptance tests for the stories in an iteration. But QA does not run those tests. It’s not QA’s job to verify that the system passes the tests. Whose job is it? The programmers’, of course!

In Scrum, the customer is called the Product Owner. This is the person (or group) who chooses stories, sets priorities, and provides immediate feedback.

Team Practices

The practices we will discuss are Metaphor, Sustainable Pace, Collective Ownership, and Continuous Integration.

A metaphor can provide a vocabulary that allows the team to communicate efficiently. On the other hand, some metaphors are silly to the point of being offensive to the customer.

Ubiquitous Language, which is the name that should have been given to the Metaphor practice. What the team needs is a model of the problem domain, which is described by a vocabulary that everyone agrees on. And I mean everyone—the programmers, QA, managers, customers, users…everyone.

That was the moment that I learned that a software project is a marathon, not a sprint, not a sequence of sprints. In order to win, you must pace yourself. If you leap out of the blocks and run at full speed, you’ll run out of energy long before you cross the finish line.

The most precious ingredient in the life of a programmer is sufficient sleep.

No one owns the code in an Agile project. The code is owned by the team as a whole. Any member of the team can check out and improve any module in the project at any time. The team owns the code collectively.

Collective Ownership does not mean that you cannot specialize. As systems grow in complexity, specialization becomes an absolute necessity.

When a team practices Collective Ownership, knowledge becomes distributed across the team. Each team member gains a better understanding of the boundaries between modules and of the overall way that the system works. This drastically improves the ability of the team to communicate and make decisions.

The point is that Continuous Integration only works if you integrate continuously.

The continuous build should never break. That’s because, in order to avoid wearing Mike Two’s dirty shirt, each programmer runs all acceptance tests and all unit tests before they check in their code.

A broken build is a Big Effing Deal. I want all the programmers to stop what they are doing and rally around the build to get it passing again. The mantra of the team must be The Build Never Breaks.

The following is true of the Standup Meeting:

1. This meeting is optional. Many teams get by just fine without one.
2. It can be less often than daily. Pick the schedule that makes sense to you.
3. It should take ∼10 minutes, even for large teams.
4. This meeting follows a simple formula.

The basic idea is that the team members stand**9** in a circle and answer three questions:

1. What did I do since the last meeting?
2. What will I do until the next meeting?
3. What is in my way?

The gist is that only developers should speak at the standup. Managers and other folks may listen in but should not interject.

One modification that I have enjoyed is to add an optional fourth question:

Whom do you want to thank?

Technical Practices

Without TDD, Refactoring, Simple Design, and yes, even Pair Programming, Agile becomes an ineffective flaccid shell of what it was intended to be.

Test-Driven Development is the corresponding practice for programmers. Every required behavior is entered twice: once as a test, and then again as production code that makes the test pass. The two entries are complementary, just as assets are complementary to liabilities and equities. When executed together, the two entries produce a zero result: Zero tests failed.

TDD can be described with three simple rules.

1. Do not write any production code until you have first written a test that fails due to the lack of that code.
2. Do not write more of a test than is sufficient to fail—and failing to compile counts as a failure.
3. Do not write more production code than is sufficient to pass the currently failing test.

The tests are a form of documentation that describe the system being tested. This documentation is written in a language that the programmers know fluently.

When you write the tests first according to the Three Rules, it’s fun. Every new test is a challenge. Every time you make a test pass, it’s a small success. Your work, as you follow the Three Rules, is a chain of those small challenges and successes. It doesn’t feel like busy work—it feels like getting stuff working.

Inevitably, you will come to a test that’s hard to write. It’s hard to write because when you wrote the code you weren’t thinking about testability, and you did not design it to be testable.

That’s the goal. We want to create a suite of automated tests that tells us that it is safe to deploy the system.

Test coverage is a team metric, not a management metric. Managers are unlikely to know what the metric actually means. Managers should not use this metric as a goal or a target. The team should use it solely to inform their testing strategy.

Do not fail the build based on insufficient coverage. If you do this, then the programmers will be forced to remove enough assertions from their tests in order to get the coverage numbers high enough. Code coverage is a complex topic that can only be understood in the context of a deep knowledge of the code and tests. Don’t let it become a management metric.

You cannot write a function that is hard to test. Since you are writing the test first, you will naturally design the function you are testing to be easy to test. How do you keep functions easy to test? You decouple them. Indeed, testability is just a synonym for decoupling.

It is for this reason that TDD is often called a design technique. The Three Rules force you into a much higher degree of decoupling.

So far, we’ve seen that following the Three Rules provides a number of powerful benefits: less debugging, good low-level documentation, fun, completeness, and decoupling.

When you have a complete test suite, you lose your fear of changing the code. You lose your fear of cleaning the code. So, you will clean the code. You will keep the system neat and orderly.

That is why we practice TDD. We practice it because it gives us the courage to keep the code clean and orderly. It gives us the courage to act like professionals.

Refactoring is the practice of improving the structure of the code without altering the behavior, as defined by the tests. In other words, we make changes to the names, the classes, the functions, and the expressions without breaking any of the tests. We improve the structure of the system, without affecting the behavior.

The word Refactoring should never appear on a schedule. Refactoring is not the kind of activity that appears on a plan. We do not reserve time for refactoring. Refactoring is simply part of our minute-by-minute, hour-by-hour approach to writing software.

1. First, we create a test that fails.
2. Then we make the test pass.
3. Then we clean up the code.
4. Return to step 1.

Bigger Refactorings such changes are made within the Red/Green/Refactor cycle. We do not create a project specifically to change the design. We do not reserve time in the schedule for such large refactorings.

Kent Beck’s rules of Simple Design are as follows:

1. Pass all the tests.
2. Reveal the intent.
3. Remove duplication.
4. Decrease elements.

Design Patterns: Template Method, Strategy, Decorator, or Visitor.

Another role option is for one programmer to write a test, and the other to make it pass and write the next test for the first programmer to pass. This is sometimes called Ping-Pong.

The goal of paring programming is to spread and exchange knowledge, not concentrate on it.

Various studies have indicated that the direct cost might be about 15%. In other words, it would require 115 pairing programmers to do the same work of 100 individuals (without code reviews).

The technical practices of Agile are the most essential ingredient of any Agile effort. Any attempt to employ Agile practices without the technical practices is doomed to fail. The reason for this is simply that Agile is an efficient mechanism for making a big mess in a big hurry.

Becoming Agile

Agile values: courage, communication, feedback, and simplicity.

It also requires courage to maintain high code quality and maintain high-quality disciplines. However, it is reckless to deploy code that you are not highly confident in or that has an unsustainable design. It is reckless to conform to a schedule by sacrificing quality.

The belief that quality and discipline increase speed is a courageous belief because it will constantly be challenged by powerful but naive folks who are in a hurry.

Planning Game, Refactoring, Test Driven Development, Continuous Integration, Small Releases, Collective Ownership, Whole Team, etc. maximize the frequency and quantity of feedback.

The next Agile value is simplicity—in other words,being direct. It has often been said that every problem in software can be solved by adding another layer of indirection.

Simplicity is directness—directness in the code, and directness in communication and behavior.

The strongest advice I can give you, however, is to adopt the full Circle of Life, including, and most especially, the technical practices.

Martin Fowler has labeled “Flaccid Scrum.”1 The symptoms of this disease are a slow decline from high productivity in the early days of a project to very low productivity as the project wears on. The reason for this loss of productivity is the corruption and degradation of the code itself.

The transition from non-Agile to Agile is a transition in values. The values of Agile development include risk-taking, rapid-feedback, intense, high-bandwidth communication between people that ignores barriers and command structures.

Every member of an Agile team needs to understand the values and techniques of Agile. Therefore, if one member of the team is trained, all members of the team should be trained.

The bottom line here is that Agile is about software. In particular, it is about small software teams. I am always frustrated when people ask me how to apply Agile to hardware, construction, or some other task. My answer has always been that I don’t know, because Agile is about software.

Software developers must master a number of core tools:

• At least one programming language, and often more
• An integrated development environment or programmer’s editor (vim, Emacs, etc.)
• Various data formats (JSON, XML, YAML, etc.) and markup languages (including HTML)
• Command-line and script-based interaction with the operating system
• Source repository tools (Git. Is there another choice?)
• Continuous integration/build tools (Jenkins, TeamCity, GoCD, etc.)
• Deployment/server management tools (Docker, Kubernetes, Ansible, Chef, Puppet, etc.)
• Communication tools: email, Slack, the English language (!)
• Testing tools (unit testing frameworks, Cucumber, Selenium, etc.)

These categories of tools are essential to building software. Without them, it is impossible to deliver anything in today’s world. In a sense, they represent the programmer’s toolbox of “hand tools.”

Great tools do the following:

• Help people accomplish their objectives
• Can be learned “well enough” quickly
• Become transparent to users
• Allow adaptation and exaptation
• Are affordable

We hold up Git here as an example of a great tool…as of 2019. You may be reading this in some future year, so remember that the landscape changes.

As Agile grew, so grew an interest in automated software tools. Some legitimate reasons for this are as follows:

• Software tools provide a good way to help ensure data is captured in a consistent form.
• With consistently captured data, you can readily derive professional-looking reports, charts, and graphs.
• Providing history and safe storage is easy.
• You can instantly share the information with everyone no matter where they reside.
• With tools like online spreadsheets, you can even have a completely distributed team collaborate in real-time.

Agile Lifecycle Management (ALM) systems, ranging from open source to polished and expensive “shrink-wrapped” products, allow you to collect Agile team data, manage long lists of features (backlogs), produce sophisticated graphs, provide cross-team summary views, and do some numerical processing.

If you only need to manage a card wall and must use software, adopt a general-purpose tool like Trello. It’s easy, immediate, cheap, extensible, and won’t make you queasy.

There is a growing body of coaching tools. Many of them can be found at tastycupcakes.org, retromat.org, and liberatingstructures.com.

There are six main areas of expertise that Agile coaches draw from: Agile frameworks, Agile transformation, Agile product management, Agile technical practices, facilitation, and coaching. Each coach will have her own mix of skills. Most organizations start by looking for an Agile coach that has Agile framework experience. As companies progress in their journey, they come to appreciate the value of each area of Agile expertise.

There are many more Agile practices out there—consider this a starting place. For instance, rather than adopting Scrum, Kanban, XP, or one of the scaling frameworks, consider which single practice from the list below is most relevant to a current need for a defined group or team, and adopt that. Try it for a while, then repeat.

• The practices of Kanban—Kanban practices include making the work visible (via a card wall), limiting work in progress, and pulling work through the system.
• The practices of Scrum and XP—These two methodologies are grouped together because they are very similar apart from the technical practices in XP. In SAFe, for instance, they are referred to collectively as ScrumXP. Between the two of them, they include a wide variety of practices such as short daily team meetings, a product owner, a process facilitator (aka Scrum Master), retrospectives, a cross-functional team, user stories, small releases, refactoring, writing tests first, and pair programming.
• Align team events—When the team events across multiple teams, such as standups and retrospectives, are aligned in time, it is possible to then roll up daily and systemic impediments via an escalation tree. This involves aligning iteration start and stop times as well as iteration length. Teams that don’t use iterations and are able to release on demand can align with any other cadence.
• Escalation trees—If it makes sense to always work on items that produce the highest value, then it makes sense to escalate impediments immediately via a well-defined escalation path. This applies to the commonly used practice of “Scrum of Scrums” and the less well-known “retrospective of retrospectives.” One pattern for this is Scrum@Scale’s fractal pattern of scaling via Scrum and Scrum of Scrums backstopped with an Executive Action Team.
• Regular interteam interaction—This practice involves regular interaction between the Scrum Masters, Product Owners, and team members who are working together toward a common deliverable. One method for this is to run regular open-space events.
• Portfolio Kanban—Traditional portfolio management practices tend to allocate people to multiple teams, which leads to rampant multitasking. Multitasking creates friction, increases complexity, and reduces throughput. Portfolio Kanban sets work in progress limits at the initiative level in order to ensure that the organization is focused on the highest-value work at all times. Having fewer projects in progress at a time also vastly simplifies (or even eliminates) multiteam coordination. Portfolio Kanban works best when paired with Minimum Viable Increments.
• Minimum Viable Increments—There are many variants of this idea, but they all boil down to thinking about what is the shortest path to producing the highest value in the shortest time. A growing number of organizations are taking this to the extreme by implementing Continuous Delivery: releasing small updates on a frequent basis, sometimes as frequently as multiple times per day.

Here are some of the practices that are generally associated with team-level Agile that do double duty as enablers of multiteam coordination.

• The SOLID principles—Although these principles are valuable at any scale, they are especially useful for simplifying multiteam coordination by dramatically reducing dependencies.
• Small, valuable user stories—Small, individually releasable stories limit the scope of dependencies, which simplifies multiteam coordination.
• Small, frequent releases—Whether these releases are delivered to the customer or not, the practice of having a releasable product across all of the teams involved helps to surface coordination and architectural issues so that the root cause can be found and addressed. Some Scrum teams forget this, but Scrum says, “The increment must be in useable condition regardless of whether the Product Owner decides to release it.” That means it must be integrated with the work of any other teams that it depends on.
• Continuous Integration—XP takes an even stronger stand on integration, calling for integration across the entire product after every check-in.
• Simple Design—This practice, also known as Emergent Design, is one of the hardest practices to learn and apply because it is one of the most counter-intuitive practices. Teams struggle with this even when they don’t need to coordinate with other teams. When coordinating the work of multiple teams, monolithic, centralized, preplanned architectures create massive dependencies between teams that tend to force them to work in lockstep, thus defeating much of the promise of Agile. Simple Design, especially when used with practices such as microservices architecture, enables Agility in the large.

Craftsmanship

While Agile coaches try to guide managers and delivery teams through the Agile processes, there is no one helping developers learn Agile technical practices and engineering. The assumption that fixing the collaboration among people would improve engineering could not be more wrong.

Good collaboration removes some of the blocks people have to do their jobs but does not necessarily make them more skilled.

Most modern Agile coaches do not have enough (if any) technical skills to coach developers on technical practices, and they rarely talk about engineering. Over the years, developers started seeing Agile coaches as another layer of management: people telling them what to do instead of helping them to get better at what they do.

Are developers moving away from Agile, or is Agile moving away from developers?

Developers still need to negotiate hard with the business to make the necessary technical improvements to keep developing and maintaining the system.

Companies are still not mature enough to understand that technical problems are in fact business problems.

As aspiring Software Craftsmen, we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

• Not only working software, but also well-crafted software
• Not only responding to change, but also steadily adding value
• Not only individuals and interactions, but also a community of professionals
• Not only customer collaboration, but also productive partnerships

Well-crafted software means code that is well designed and well tested. It is code that we are not scared to change and code that enables business to react fast. It is code that is both flexible and robust.

Steadily adding value means that no matter what we do, we should always be committed to continuously provide increasing value to our clients and employers.

A community of professionals means that we are expected to share and learn with each other, raising the bar of our industry. We are responsible for preparing the next generation of developers.

Productive partnerships means we will have a professional relationship with our clients and employers. We will always behave ethically and respectfully, advising and working with our clients and employers in the best way possible. We will expect a relationship of mutual respect and professionalism even if we need to take the initiative and lead by example.

We will look at our work not as something we need to do as part of a job but as a professional service we provide. We will take ownership of our own careers, investing our own time and money to get better at what we do. These values are not only professional values—they are personal values. Craftspeople strive to do the best job they can, not because someone is paying, but based on a desire to do things well.

The main goal of Agile is to provide business agility and customer satisfaction, and that is achieved via close collaboration, iterative development, short feedback loops, and technical excellence. Methodologies like Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), Crystal Methods, Feature-Driven Development (FDD), and other Agile methodologies are all means to the same end.

Software Craftsmanship community considers XP the best set of Agile development practices currently available. TDD, Refactoring, Simple Design, Continuous Integration, and Pair Programming are heavily advocated by the Software Craftsmanship community—but they are XP practices, not Craftsmanship practices. And they are not the only practices. Craftsmanship also promotes Clean Code and SOLID principles. It promotes small commits, small releases, and Continuous Delivery. It promotes modularity in software design and any type of automation that removes manual and repetitive work. And it promotes any practices that improve productivity, reduce risk, and help to produce valuable, robust, and flexible software.

“How do I convince my manager/colleague/team to do TDD?” That is the wrong question. The problem here is that we are offering a solution before agreeing on the problem. People will not change the way they work if they do not see the value.

Instead of pushing TDD, maybe we could start agreeing on the value of reducing the time it takes to test our entire system. How long does it take today? Two hours? Two days? Two weeks? How many people are involved? What if we could reduce it to 20 minutes? Two minutes? Maybe even 2 seconds? And what if we could do that at any time just by pressing a button? Would that give us a good return on investment? Would that make our lives easier? Would we be able to release reliable software faster?

Agreeing first on the goals to be achieved is essential when discussing practices. The only thing that should not be acceptable is to reject a practice without providing a better alternative.

What developers should not do is to let other people decide how they work. Conversations between developers and business should be about why, what, and when—not how.

A profession, on the other hand, is part of who we are. When asked, “What do you do?”, a person with a job would normally say something like “I work for company X,” or “I work as a software developer.”But a person with a profession would generally say, “I am a software developer.” A profession is something we invest in. It’s something we want to get better at. We want to gain more skills and have a long-lasting and fulfilling career.

Developers organize internal sessions where they code together, practice TDD, and improve their software design skills. They become interested in learning new technologies and modernizing the systems they work on. They discuss better ways to improve the codebase and eliminate technical debit. Software Craftsmanship promotes a culture of learning, making companies more innovative and responsive.

Craftsmanship and Agile want to deliver high-quality, valuable work, and both want professionalism. In order to achieve business agility, companies need not only collaborative and iterative processes, but also good engineering skills. Combining Agile and Craftsmanship is the perfect way to achieve that.

Conclusions

That’s are all my notes from the book, I’m sharing these notes with everyone and would recommend coming to them at any moment when you are facing issues understanding AGILE values. Agile topic it’s very complex and depends on the situation and only practice can improve your knowledge in the domain.
I would live here more useful links:
https://agilemanifesto.org/principles.html
https://rajasegar.medium.com/software-craftsmanship-what-do-you-need-to-know-741cca6a92ddhttps://en.wikipedia.org/wiki/Scaled_agile_framework
https://www.scrum.org/resources/scaling-scrum
https://less.works/