Read and take notes

preface

This book is for programmers and non-programmers alike. It’s not technical. There’s no code. It is intended to provide an overview of the original intent of Agile software development without getting into any deep technical details of programming, testing, and management.

This is a small book. That’s because it’s not a big topic. Agile is a small idea about a small problem with a small programming team doing small things. Agile is not a big idea about a big problem with a big programming team doing big things. Big things don’t get done by big teams, they get done by many small teams.

Over the past few years, the simple, small message of Agile has become blurred. It’s a blend of lean, Kanban, LeSS, SAFe, Modern, Skilled, and so on. These are good ideas, but they were not the original agile message. It’s time to remember what agile really is.

You will find nothing particularly new in this book, nothing startling, nothing revolutionary breaking the mould. You’ll find it a restatement of Agile, as it was told in 2000. We’ve learned a few things over the last 20 years, and I’m going to include them. But overall, the message of the book is that of 2001 and 1950.

It’s an old message. This is a true message. It gives us a small solution, a small problem for small software teams doing small things.

What is Agile

In February 2001, a panel of 17 software experts in Snowbird, Utah, discussed the dismal state of software development. At the time, most software was built using inefficient, burdensome, high-protocol processes such as Waterfall and the Rational Unified Process (RUP). The goal of the 17 experts was to create a manifesto for a more effective, lightweight approach.

This will not be easy. These 17 people have different experiences and strongly different opinions. It is impossible to expect such a group to reach consensus. Yet, against all odds, a consensus was reached, the Agile Manifesto was written, and one of the most influential and enduring movements in software was born.

Such movements in the software industry follow predictable paths. You start with a small group of enthusiastic supporters, another group of enthusiastic opponents, and the vast majority of people who don’t care. Many sports end at that stage, or at least never do. Think section-oriented programming, logical programming, or CRC cards. Some, however, have crossed the divide to become extraordinarily popular and controversial. Some even manage to leave the controversy behind and simply become part of the mainstream. Object orientation is an example of the latter. The same is true of Agile.

Unfortunately, once a movement becomes popular, its name is clouded by misunderstanding and usurpation. Products and methods unrelated to the actual movement borrow names and cash in on their popularity and importance. The same is true of Agile.

Written nearly 20 years after the Snowbird conference, the book aims to set the record straight. This book describes Agile in as pragmatic a way as possible, with no nonsense, no uncertain statements, and no uncertain terms.

This book introduces the basics of Agile. Many people embellish and expand on these ideas, and there’s nothing wrong with that. However, these extensions and refinements are not agile. They are agile plus something else. You will read here about what Agile is, what agile was, and what agile will inevitably always be.

Agile history

Winston Royce wrote a paper in 1970 in which he described his ideas on how to manage large-scale software development projects. The paper includes the following diagram.

This technique became known by the name “waterfall” because of its resemblance to the waterfall.

The waterfall model of software development is derived from scientific management, which implements software development through analysis, making detailed plans and executing plans. Winston Royce did not recommend the Waterfall software development model, people took the concept of the waterfall software development model from his paper, and the waterfall software development model dominated software development for the next 30 years.

Due to the particularity of software development, it is almost impossible to do a good job of software requirements analysis and software architecture design at the beginning, because the requirements are changing all the time.

In 1994, I met Kent Beck for the first time, and in 1999 I met Kent Beck again, after which I learned about Extreme programming and became fascinated by it. The idea in Extreme programming is quite subversive. I introduced extreme programming bootcamps at my own company. In the summer of 2000 Kent Beck invited the EXTREME programming community and the design Pattern community to organize a meeting called XP Leadership to discuss what extreme programming should be like next. One idea was to create a nonprofit organization around extreme programming. I agree with this idea, but others don’t quite agree with it. I left the meeting frustrated, and Martin Fowler followed and suggested that we meet again later in Chicago. I agreed.

In the fall of 2000, Martin and I met and decided to organize a Light Weight Process Summit, and we decided to invite a lot of people. One of our invitees, Alistair Cockburn, told me that he was planning to organise a similar conference and that he had combined his invitees with our invitees. He would do the legwork for the meeting if we agreed to do it at Snowbird. So the meeting was held in Snowbird.

Snowbird

In 2001, 17 software developers got together to find a better way to develop software. They discussed the agile software development method and came up with the following Agile manifesto:

• Individuality and interaction over processes and tools. (Individuals and interactions over Processes and tools)
• Working software trumps detailed documentation. (Working software over comprehensive documentation)
• Customer cooperation trumps contract negotiation. (Customer collaboration over contract negotiation)
• Response changes are higher than compliance plans. Responding to change over following a plan

An overview of Agile software development

Project management iron Cross principle

Any project can only be selected from three of four aspects: good, fast, cheap and complete.

Reality, good project managers know this four aspects can have different coefficient, the good manager led project in enough, fast enough, cheap enough and complete only must function of direction, they will not take the four sorts of coefficients are set to 100%, which is agile software development to implementation management methods.

Agile software development is one such framework to help developers and managers implement practical project management.

Agile software development provides the data that managers need to make decisions

Team rate chart

The team rate graph represents the number of user story points completed by the team per iteration

Burnout figure

The burnout chart represents the change in the user story points of the project

Traditional Software development

The boss set a deadline for the project. Meeting to determine the time required for the analysis phase, the design phase, and the implementation phase.

The analysis stage is a very relaxed and happy stage. We surf the Internet and chat with customers. When the planned time is over, we finish the analysis and “magically” finish the analysis stage.

In the design phase, we divide the project into modules and design the interfaces between them. Unpredictable things can happen, of course, new requirements are added, the demand of the old is removed or modified, we would like to analysis these changes, but because time is short, we can only change the hack into the design, when the end of the time, we finished design, the design phase and magic is done.

The implementation phase has clear criteria, and there is no way to pretend that we are done with the implementation phase. In the implementation phase, requirements are constantly changing as new requirements are added and old requirements are removed or modified. We’d love to go back and re-analyze and re-engineer the changes, but we’re running out of time to hack them into code one by one. When we looked back at the code and compared it to the design, we realized that our code and design were far from what we had envisioned, but we didn’t have time to worry about that anymore. Two weeks before the planned delivery date, we told stakeholders (managers, product owners, customers, etc.) that we would not be able to deliver the software on time. You can imagine how the stakeholders would react.

We end up under a lot of pressure to finish what we didn’t finish, a Phase known as The Death March Phase. We told ourselves that we would never do a project like this again, that next time we would do more analysis, more design. The result is the same, because we did it the wrong way.

Waterfall development won’t destroy every project, but it’s still a disastrous way to develop software projects.

Agile software development

The project starts with analysis, but the analysis never stops. We divide time into normal incremental segments as iterations or sprints. On the right side is the deadline. Iterations are usually one or two weeks long.

The first iteration, often referred to as iteration 0, is used to produce a list of requirements, called a user story. Iteration 0 was also used to set up the development environment, evaluate the user stories, and develop a preliminary plan that simply assigned the stories to the first few iterations. Finally, Iteration 0 is used by developers and architects to conceive the initial tentative design of the system from the tentative story list, write user stories, evaluate user stories, plan user stories, and architectural design that never stops. At any time in each iteration, there is some analysis, design, and implementation that we do all the time in agile software development. Iteration is not a waterfall.

Iteration 1 begins with an assessment of how many stories are planned for this iteration, and then the team gets to work to complete the stories. At the end of the iteration, we had completed part of the user story, which was our first measurement of how much could be done in an iteration. This was real data, and if we assumed that each iteration was similar, then we could adjust our original project plan and recalculate a new project completion date. This may be significantly more than the deadline we had planned, but at least it’s real, but don’t take it too seriously, because this is just the first iteration, and as the iteration progresses, the number of points the team completes may change, and our adjustments may continue until it’s very stable.

Depriving them of hope is a major goal of Agile software development, and we adopt Agile to destroy hope before it kills the project, because hope can lead teams to mislead managers from seeing the true progress of the project. Agile software development leads the project to the best possible outcome, which may not be the desired outcome, but it is the best possible outcome.

Manage the iron Cross principle

Project managers need to decide how good, fast, cheap, and functional a project should be. Often managers can adjust scope, timing, staffing, and quality.

Change the time, but sometimes the time cannot be changed for business reasons.

Add people. There’s some data that shows that adding people doesn’t increase productivity in the first few weeks, it actually decreases productivity, and then it gradually increases. You can only hope that the lost productivity will be replaced later, and that more people will be added, usually to the budget.

Reduce quality. We all know we can speed things up by stopping writing tests, stopping code reviews, stopping refactoring, and just writing production code. But that’s not the case. Not doing these seemingly useless things will slow you down rather than speed you up. If you want to go faster, you should go better. If you want to reduce project time, the only option is to improve quality.

Vary the scope, and some requirements may not need to be met by the deadline.

Business value priority

We ask the stakeholders what requirements we should implement next, and we only do what the stakeholders ask us to do

This is just the outline of agile software development, but it is the gist of agile. The output of each iteration is measurable, used to continuously assess the schedule, requirements are implemented in order of business value, quality is maintained as high as possible, and schedules are adjusted primarily by changing the scope of requirements, which is agile.

Circle of Life

XP (Extreme Programming) is called Extreme Programming. It best meets the requirements of agile software development. Ron Jeffries summarized XP’s practice chart, affectionately known as the “Circle of Life.”

The outer ring is a business-oriented practice, essentially equivalent to Scrum. It provides a framework for software developers to communicate with business people, and it also provides principles for software developers and business people to manage projects.

The ring in the middle is team-oriented practices that provide the principles and framework for communication and self-management within the development team.

The inner rings represent technical practices that guide and constrain programmers to ensure the highest possible technical quality.

conclusion

Agile is about helping small teams manage small projects with small disciplines.

Why Agile

Before we dive into the details of Agile development, I want to explain what’s at stake. Agile development is important not only for software development, but also for our industry, society, and ultimately civilization.

Developers and managers are often attracted to Agile development for temporary reasons. They may try it because they just feel it’s the right thing to do, or they may believe in the promise of speed and quality. These reasons are intangible, vague, and easily frustrated. Many people abandon Agile development simply because they do not immediately experience what they think agile promises.

These fleeting reasons are not why Agile development matters. Agile development is important for deeper philosophical and ethical reasons. These reasons relate to the reasonable expectations of our profession and our clients.

professionalism

Software has been in every aspect of our lives, we rule the world, our software errors can bring disaster to others, we should be more professional.

Reasonable expectation

• We do not make substandard software.
• Software is always in a state of technical readiness, ready for release.
• Stable software production efficiency, we develop software at a stable rate.
• Cheap adaptability, software should be easy to modify.
• Continuous improvement. Software should be continuous improvement.
• The ability to be fearless, we need mechanisms that give us confidence when we modify code.
• QA should not find any bugs, and when QA checks the software, the development team should make QA not find any bugs.
• Tests should be automated.
• Work should be exchanged between developers so that everyone’s work can be handed over to others to prevent unexpected situations.
• Honest assessment of user story time.
• To say no when necessary, we are professionals, and we should say no where it is not reasonable.
• Keep learning actively.
• Mentor others and learn from each other with others.

The power bill

Customer bill of Rights

• You have the right to have a comprehensive plan and know what can be done when and at what cost.
• You are entitled to get the maximum possible value out of each iteration.
• You have the right to see the progress of a running system and verify its effectiveness with specified repeatable tests.
• You have the power to change your mind, replace features, and change priorities without overpaying.
• You have the right to be informed of the schedule and evaluate changes, and to choose in a timely manner how to narrow it down to meet the required dates. You can always cancel the project and leave behind a useful working system that reflects the investment in software so far.

Developer bill of Rights

• You have the right to know what needs are needed, with clear descriptions and priorities.
• You have the right to produce quality work at all times, and the business can’t force you to lower quality.
• You have the right to ask and receive help from colleagues, managers and clients.
• You have the right to make and update your estimates. You can change your estimates as you discover new factors. Estimates are not promises.
• You have the right to accept your responsibilities, not be assigned to you, and you have the right to refuse.

conclusion

Agile is a disciplinary framework that supports professional software development. Agile is not a process, it is not a fad, it is not just a collection of rules. Agility is a set of rights, expectations, and disciplines that form the basis of the work ethic.

Business practices

To be successful, development must follow a number of business-oriented practices. These include planning, small releases, acceptance testing, and teamwork.

plan

Project time assessment

If you want an accurate and accurate estimate of project time, you need to break the project down into as small as possible, even into individual implementation lines of code. The time you take to do this is the exact estimated time of the project, because all you’re doing is developing and implementing a piece of software.

Estimation is a guess, and we want to guess how long the project will take without actually developing the software, so it’s definitely not accurate, and to be more accurate, you have to spend more time on estimation, which is our choice.

We can learn about the three-variable assessment and PERT assessment methods.

User stories and points

User stories are short descriptions of system features from the user’s point of view, for example: As a car driver, I press the gas pedal harder in order to increase my speed. (As the driver of a car, in order to increase my velocity, I will press my foot harder on the accelerator pedal)

Often, we write stories on index cards without necessarily using software tools.

ATM user story example

A user story

• Withdrawal of money
• Deposit money
• Transfer
• Login
• Logout

In iteration 0, our team wrote the above 5 user stories. We also discussed the details of these user stories, such as users using passwords to log in, but we did not believe these details, we did not write them on the story card, we only wrote the above short words on the story card.

User story evaluation

Now have a user story, development, testing, project management, or other stakeholders meeting together for the evaluation of user story, such a meeting will be a lot of, every time a new user stories or user story has a new understanding of before, we will open a user story assessment of the related conference, the meeting is formal, for every iteration.

Because this is the first time a user story evaluation, we choose a we think complexity to evaluate the average user story to start, we choose the logged in user stories, we require review before discussing the details of the stakeholders, so that we can understand the context, then we choose a number 3 for this user story, why is 3? The login user story is an average story, so we give it an average number, and if we choose 1 to 6 to evaluate the user story, then 3 is that average number.

The login Story is now our Golden Story, and then all the user stories will be compared to it for evaluation, so we have the following evaluation, logout 1, withdraw money 6, Deposit 5, transfer 3, and we write the user Story evaluation on the user Story card.

The number for estimating a user story does not represent any other unit of time, such as weeks, days, hours, etc. It is a relative number, just a unit of effort, and has nothing to do with the actual time. Some people need one day, some people need two days.

Plan Iteration 1

An Iteration begins with an Iteration Planning Meeting (IPM), which should take approximately 1/20 of the Iteration and is attended by all team members, including stakeholders, programmers, testers, and project managers. Stakeholders view user stories and rank them by business value.

Stakeholder’s main job is to select the programmers and testers in the iteration will complete a user story, therefore, they need to know how much they can finish the programmers think, this number is the rate, because this is the first iteration, we don’t know the rate, so we just guess a number, such as: 30.

It’s important to note that speed is not a promise, they’re not even trying to get to 30, it’s just a guess.

Return on investment

ROI (Return on Investment) and user story prioritization.

Point to check

At the midpoint of the iteration, we realized that we had only completed 10 points, so the stakeholders needed to remove 10 points of user stories from the iteration.

Only 18 points may have been accomplished by the end of the iteration, but this does not mean that the iteration failed. The purpose of an iteration is to produce data for managers.

Yesterday’s weather

Now that we know we can accomplish 18 points in one iteration, we should plan for 18 points in the next iteration.

The best forecast of today’s weather is yesterday’s weather, and the best predictor of iteration progress is the previous iteration.

At the IPM meeting, the stakeholders chose 18 points of user stories, and this time maybe something strange happened. In this iteration, the midpoint check found that 12 points had already been completed, so the stakeholders added 6 points of user stories, 24 points of the total plan, and maybe as a result we completed 22 points. So the next iteration is set to 22 points.

End of the project

As the iteration continues, the rate is continuously added to the rate graph, and everyone knows how fast we are.

There may come a point where not all of the stories are implemented, but the project ends because, according to ROI principles, there are no more stories worth implementing, and the importance of the first stories written may have long since disappeared.

A user story

User stories should follow the INVEST principle:

• I: Independent, user stories should be Independent of each other, which means they do not need to be implemented in a particular order, and logout cannot require login to be implemented first.
• N: It’s Negotiable. The developer can negotiate the details with the seller.
• V: Valuable, user stories must have clear and quantifiable value to the business.
• E: Estimable, user stories must be specific to developers that can be evaluated.
• S: Small is Small enough that user stories should not be large enough to require one or two openers to be implemented in a single iteration.
• T: Testable and the business should be able to clearly write tests to prove the story is complete.

User story evaluation

Method 1: Flying Fingers

Developers sitting around the table sat, reading stories and discussions with stakeholders (if required), then the developer behind the finger number, then all developers her finger at the same time, someone statistics all the developers say points, if the differences are small and have an obvious average, record the assessment of user story, if not unity, to discuss again, Score again.

• Thumb down is 0
• Thumb up for infinity
• Open palm expression?

Method 2: Planning Poker

Fibonacci numbers are usually used,? , 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞.

• 0 means that it is too trivial to evaluate, and several user stories can be combined.
• Infinity means that the user story is too big to evaluate and should be split.
• ? Means you don’t know, you need a spike.

Spike

A spike is a meta-story, or rather, a story used to estimate a story. You need to understand the technology before you can evaluate the current story. For example, you can write a user story and print a PDF for the evaluation.

Management of iteration

The goal of each iteration is to generate data by completing the user story, and the team should focus on the user story, not the tasks in the story. It is much better to complete 80% of the user story than to complete 80% of every user story.

Instead of assigning user stories, managers should let them negotiate and select the stories themselves.

Acceptance tests should be written as early as possible, and all acceptance test code should be completed by the midpoint of the iteration, and QA should work closely with the programmer.

True completion is acceptance test pass.

Minor release

Take small steps to run faster. Separate release from deployment. Release means software is ready for deployment, deployment is just a business decision.

The acceptance test

Acceptance testing is the least understood, least used, and most confusing agile practice. The basic idea is simple: requirements should be specified by the business.

An acceptance test is a specification that is also a test, for example: when a user enters a valid username and password and clicks login, the welcome page is displayed.

Tools and Methods

• FitNesse, JBehave, SpecFlow, Cucumber
• BDD(Behavior-Driven Development)

practice

Acceptance tests are written by business analysts and QA prior to the midpoint of the iteration. Developers integrate these tests into continuous builds. These tests are the definition of user story completion, and only passing these tests is considered user story completion.

The business analyst specifies the normal business path, QA writes the abnormal business path, and the developer works with the business analyst and QA to ensure that these tests make sense from a technical perspective.

QA is no longer involved in quality assurance at the end of each iteration, they are involved with the development team at the beginning of each iteration to prevent errors and omissions, and at the end they decide whether the software can be deployed.

The job of running the tests should be done by the programmers, and their user stories are complete only if the tests pass, although the programmers can automate the testing process by continuing to build.

Team collaboration

• All team members should sit together and work.
• Make sure the team can meet face to face at all times.
• Telecommuting is fine, as long as you can communicate face-to-face in real time.

conclusion

Agile wants to break down the divide between business and development teams so that business and development can work together better, and business-oriented practices play an important role in meeting this goal. By following these practices, business and development have a simple and unambiguous way to communicate. This communication breeds trust.

The team practice

Ron Jeffries’ Circle of Life middle section consists of Agile team practices. These practices govern the relationships between team members and the products they create. The practices we will discuss include metaphors, sustainable speed, collective ownership, and continuous integration.

Then, we’ll briefly discuss what are called Standup Meetings.

metaphor

Look for words that are figurative of the project or the module components of the project, and the team will use them to communicate. Domain-driven Design uses a Ubiquitous Language to facilitate team communication.

Sustainable rate

• It is important that the development team develop at a sustainable pace.
• Working overtime to speed up development is unsustainable and can lead to bad decisions and bad code being written, which can backfire in the end.
• Software development is a marathon process, and we don’t want to use our energy too fast early on, we want to maintain a sustainable pace.
• Development work is not manual labor, and working overtime does not mean you are working hard and professionally.
• Make sure you get enough sleep.
• It’s ok to work overtime occasionally, but it can’t be the norm.

Collective ownership

The code is collectively owned and can be viewed and accessed by anyone at any time.

Continuous integration

• Integrate code early, find bugs early, and fix bugs early.
• The ultimate in continuous integration is integrating every code commit.
• When continuous integration fails, no one can commit code until continuous integration is fixed.
• When continuous integration fails, you can send an alarm email, and even set the alarm light and alarm sound.

Daily station will

Guiding principles

• Meetings are optional.
• You don’t have to do it every day, you have to do it when it makes sense.
• Meetings should be 10 minutes small, even for large groups.

Speaking rules

• What have I done since the last meeting?
• What WILL I do before the next meeting?
• I ran into some difficulty.

No discussion, no further explanation is allowed at the meeting. Everyone can speak, including the manager, so long as they follow the rules. You can also thank other people for helping you in meetings.

conclusion

Agile is a set of principles, practices, and disciplines that help small teams build small software projects, and the practices in this chapter help small teams behave like a real team. Help the team build their language of communication and expectations about how team members treat each other and the project they are building.

Technology practice

The practices described in this chapter are very different from the way most programmers have behaved over the past 70 years. They enforce a set of deep, minute-by-minute, second-by-second behaviors that most programmers would initially consider absurdly ritualistic. As a result, many programmers try to achieve agility without these practices. However, they failed because these practices are at the heart of Agile. Without TDD, refactoring, simple design, or even pair programming, Agile becomes a loose shell of inefficiency.

Test-driven Development

Write the test code first, then write the production code to make the test pass, and then refactor to improve the code.

When using TDD, each required behavior is entered twice, once as a test and once as production code to make the test pass. They complement each other, producing zero results and zero test failures when executed together.

TDD three principles

• Do not write any production code until you have written failed test code.
• Do not write test code when there are test failures. Compile failures are also failed tests.
• Write just enough production code to make the test pass.

Programmers who have not practiced TDD for months may find these principles strange or even unacceptable.

Programmers who use TDD seldom Debugging because new code was introduced a few minutes ago, so errors are introduced in this period of time, and it is easy to find the wrong code.

If you follow TDD principles, the tests you write are probably the best documentation for your software, with multiple uses of the software or library.

Every new test is a challenge, and every time you write code to get the test passed, you’ve completed a challenge, and all the way down the line it doesn’t feel like busy work, it feels like getting things to work.

Following the three principles will give you a complete test suite, but it is not 100% complete. It is not necessary to achieve 100% code coverage to deploy software. 90% coverage is good enough.

Because you write tests first, you need to make your code easier to test, and because loosely coupled code is easier to test, you need to decouple your code so that your code design is better.

Because tests are complete, when you see code that needs to be improved, you can change it with confidence, because you have test code to verify that your changes have affected the previous functionality.

Refactoring

Improve the internal design of the code without changing the external behavior of the software.

Refactoring is closely related to TDD, and in order not to be afraid to refactor code, we need full testing to give us a very high degree of confidence that our changes won’t break previous functionality.

Red, green, refactoring

• First, we create a failed test.
• Then, we write code to make the test pass.
• Then, we refactor to make the code clean.
• Go back to the beginning.

Instead of allowing time for major refactorings, we migrate the code one small step at a time while continuing to add new features, which can take days, weeks, or even months as the system passes testing and can be deployed to production.

Simple Design

Kent Beck’s simple design principles

• Pass all tests: Complete all features.
• Express intent: Then consider refactoring the code to express the programmer’s intent, making it easy to read and self-describing.
• Remove duplication: Then consider refactoring to remove duplicate code, possibly using design patterns, etc.
• Reduce elements: Finally, consider reducing code elements, such as classes, functions, variables, and so on.

Design weight

The more complex the design, the greater the cognitive burden on the programmer, and the more difficult it is for the programmer to understand and operate the system, which is the weight of the design. Programmers constantly refactor the system to balance requirements with simple design for maximum productivity.

Pair Programming

Two people working on the same programming problem might share a screen, keyboard, and mouse as long as they look at and manipulate the same piece of code. Pair programming sometimes uses different roles.

• One is the driver, one is the navigator, the driver has a keyboard and a mouse, and the navigator takes a longer view and gives advice.
• One programmer writes the test code, another programmer writes the production code to get the test passed, then switches roles and continues.
• Most often, there are no characters at all. Programmers are just authors who share the mouse and keyboard in a collaborative way.

Pair programming is not scheduled, and programmers decide on their own preferences. Pair programming is short-term, lasting up to a day at a time, but usually no more than an hour or two.

User stories are not assigned to pair programming; user stories are assigned to individual developers.

Over the course of a week, each programmer would spend about half of his pairing time working on his own task and enlist the help of several others. The other half of the pairing time will be spent helping others complete tasks.

Senior programmers should take care to pair program with junior programmers, not other senior programmers. Low-level programmers should ask more senior programmers for help.

Programmers with professional skills should spend a significant amount of pair time working with programmers outside their field. The purpose is to spread and exchange knowledge, to prevent the formation of knowledge silos, knowledge islands.

Pair programming is the best way to share knowledge among team members and prevent knowledge islands from forming.

Pair programming reduces errors and improves design quality.

Pair programming is another form of code review.

Pair programming may take 15% more coding time, and a simple calculation shows that a team that pairs 50% of the time reduces its productivity by less than 8%. On the other hand, if the practice of pairing takes the place of code review, productivity is probably not reduced at all.

Pair programming doesn’t have to be two people.

Managers leave pair programming alone and trust the programmers. Programmers should never ask managers for time for pairing, testing, and refactoring. You are the expert and should decide for yourself.

conclusion

Agile technical practices are the most important component of any agile effort. Any attempt at agile practices without technical practices is doomed to failure. The reason is simple, agile is an efficient mechanism that can mess things up in a very short period of time. Without technical practices to maintain high technical quality, team productivity will quickly decline and begin an inevitable death spiral.

The implementation of agile

When I first learned XP, I thought, what could be easier than this? Just follow a few simple principles and practices. That’s all.

However, it must be very, very difficult to be agile based on the number of organizations that have tried agile and failed. Perhaps the reason for all these failures is that many organizations have misconceived agile, thinking it is different from what agile originally thought.

Agile values

The courage to

It takes courage to deploy a minimal feature set, as well as courage to maintain high code quality and high quality discipline. The belief that quality and discipline can improve speed is a brave one, for it will be constantly challenged by the powerful but naive.

communication

Team members can have more convenient face-to-face, informal, interpersonal conversations. A team that sits together and communicates frequently can work wonders.

feedback

Agile principles are all about providing quick feedback to those who need to make important decisions. They enable us to tell early when something is wrong so we can correct it in time. Agile teams thrive on feedback. Feedback is what makes teams work effectively and what drives projects to achieve beneficial results.

simple

Simplicity refers to the directness of code, as well as the directness of communication and behavior. In code, a certain amount of indirection is necessary. Indirection is the mechanism by which we reduce the complexity of interdependence. In teams, less indirection is necessary. Most of the time, you want to be as direct as possible. Keep the code simple, keep the team simple.

Monster Museum

The sheer number of agile methods can be overwhelming, and whichever one you choose, you will eventually adapt it to meet the needs of your team. The most powerful piece of advice I can give you is to embrace Circle of Life, especially technology practices. Choose a method, or not. Make sure you fully embrace Circle of Life. Get the team to agree. Then get started, remember courage, communication, feedback and simplicity, and adjust the rules and behavior regularly. Don’t ask permission. Don’t stress getting things done. Just solve problems as they arise and continue to push the project toward the best possible results.

The transformation of

Agile values are diametrically opposed to the responsibilities of middle management, and executives are often driven by Agile values of risk taking, directness, and communication. That’s one of the reasons they’re trying to transform. The obstacle is the middle management. These people are hired to take no risks, avoid directness, and follow and execute the chain of command with minimal communication. That’s the dilemma of the organization. The top and bottom of the organization value agile thinking, but the middle opposes it.

Can agile teams exist in an organization with a strong anti-Agile middle management? I’ve seen this happen before. Some software development teams quietly use Agile values to drive their development, while also adhering to the strict requirements imposed by middle management. As long as middle management is satisfied with the processes and standards they follow, they can leave the development team to its own devices. The team performs agile behind the scenes while providing everything that satisfies middle management. Rather than fighting a futile battle with middle management, these teams add a layer on top of Agile, making it seem safer and more responsive to the needs of middle management.

Agile transformations are more likely to succeed in small organizations.

The coach

Agile trainers teach teams how to manage themselves in an agile manner, often from outside the organization or from outside the team. Their tenure should be short. Each team of a dozen developers should only need one or two weeks of training. Everything else they need to learn is self-taught, no matter what the Agile trainer says or does.

An Agile coach is not a trainer. They are members of the team and their role is to maintain the process within the team. During peak development periods, developers may not follow agile processes. Maybe they inadvertently stopped pairings, stopped refactoring, or ignored failures in successive builds. The coach’s job is to see that and point it out. The coach acts as the conscience of the team, always reminding the team of their commitment to themselves and the values they agree to hold.

In the early stages of a team transition, a trainer may temporarily fill in the coaching role, but this is a temporary situation. This role should be chosen as soon as possible on the team, and usually rotates from one team member to the next on an informal schedule as needed. A mature team makes steady progress without a coach. On the other hand, a team under some kind of pressure, whether it’s scheduling, business, or relationships, may decide to have someone fill the role temporarily.

A coach is not a manager. Coaches are not responsible for budgets or schedules. The coach does not direct the team or represent its interests to management. The coach is not the liaison between the client and the developer. The coach’s role is within the team. Neither the manager nor the client knows who the coach is, or even if there is one now.

certification

The existing Agile certification is a complete joke and completely ridiculous. Don’t take certification seriously. The training that accompanies a certification program is often worthwhile. However, training should not focus on a specific role, it should be appropriate for everyone on the team.

What would a true Agile certification program look like? This will be a one-semester course that includes agile training and supervised development of a small Agile project. The course will be graded and the students will be strict. Certification personnel will ensure that students understand the value of Agile and demonstrate proficiency in implementing agile procedures.

Large agile

Agile teams are just one of many that need to be coordinated on large projects. The integration of different teams is a problem that has been solved. I don’t see any evidence that the uniqueness of the software team is overly affecting their integration with larger teams.

There is no such thing as agile on a large scale. Agile is a necessary innovation for organizing small software teams. But once organized, these teams adapt to structures that large organizations have used for thousands of years.

Agile tools

Knowing the tool well makes it useful, and using the wrong tool can even harm the project and its operators.

A good tool should have the following features:

• Help people achieve their goals.
• Can learn well quickly.
• Transparent to the user.
• Allows adaptation and extension.
• Affordable.

Physical Agility tools. Agile users are known for visually managing their work using whiteboards, tape, index cards, markers, and sticky notes of various sizes (small and page-turning). These simple hand tools have all the qualities of great tools:

• They help make the work in progress visible and manageable.
• They are intuitive and do not require training.
• They require negligible cognitive overhead. You can easily use them while focusing on other tasks.
• They are not exclusive. None of these tools are designed specifically for managing software development.
• They are adaptable. You can tape or putty them, clip pictures or ICONS to them, stick other indicators to them, and add nuance to meaning with innovative custom colors and ICONS.
• They’re cheap and easy to get.

Pressure to use automated tools:

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

Given the current state of most ALM (Agile Lifecycle Management) tools, it may be safer and wiser to start with physical tools. After that, you can consider using the ALM tool. Make sure learning is fast, daily use is transparent, easy to adapt, and within your ability to get and run. Most importantly, make sure it supports the way your team works and provides a positive return on your investment.

Coach (another view)

Agile coaches lead teams to Agile.

conclusion

In many ways, this chapter is more about what not to do than what to do. Maybe it’s because I’ve seen too many examples of not being agile. But STILL, I think, as I thought 20 years ago, what could be easier? Just follow a few simple principles and practices. That’s all.

craftsmanship

Excited. This is how many developers feel when they first hear about Agile. For most of us developers who come from the software factory and waterfall mindset, agile is the promise of liberation. We want to work in a collaborative environment where our opinions are heard and respected. We will have better workflows and practices. We will work in small iterations and short feedback loops. We will release the application to production on a regular basis. We interact with our users and get their feedback. We will constantly review and adjust.

At first, we thought Agile was too good to be true. We didn’t think our company would ever embrace agile thinking, let alone agile practices. But most of them did, and we were very surprised by that. Suddenly, everything changed. We have product backlogs and user stories, not requirements documents. We have physical kanban and burnout charts, not Gantt charts. We have post-it notes and we move them every morning based on progress. These post-it notes have a powerful power to trigger a deep psychological addiction. They represent our agility. The more notes we put on the wall, the more agile we feel. We became a Scrum team, not a build team. We don’t have a project manager anymore. We were told that we didn’t need to manage, that our managers would be product owners and that we would manage ourselves. We were told that product owners and developers would work closely together as a separate team. From now on, as a Scrum team, we are empowered not only to make technical decisions, but also project-related decisions. That’s what we think.

Agile took the software industry by storm. But, as in the Whisper game in China, the original agile ideas were distorted and simplified in what the company saw as a promise of a faster software delivery process. This is music to the ears of companies and managers who use waterfall or RUP. Managers and stakeholders are excited. At the end of the day, who doesn’t want to be agile? Who doesn’t want to deliver software faster? Even skeptics can’t resist agile. If your competitors advertise that they are agile and you are not, where does that leave you? What do your prospects think of you? Companies can’t afford not to be agile. In the years since the Agile Summit, companies around the world have begun their Agile transformation. The age of agile transformation has begun.

A quick hangover

The agile transition process is not easy, companies need external help, agile coach positions are in high demand, and there are many agile certifications, most of which are easy to obtain.

It’s easy to sell agile processes to middle managers who want faster software delivery. Engineering is the easy part, managers are told, and if we fix the process, engineering will be fixed. It’s always about people. Then the managers believed it.

Managers who want to push developers to work faster are using the full transparency of the process to micromanage them. An Agile coach with neither business nor technical experience guides the manager and tells the development team what to do. Roadmap and milestones are defined by the manager and force the development team that developers can evaluate the work, but it is difficult for them to incorporate their own estimates into the imposed milestones. Over the next 6 to 12 months, it is common to see all iterations of the project and their respective user scenarios defined by management. Failing to deliver all the story points in the sprint meant that the developers had to work harder in the next sprint to make up for the delay. Daily stand-up meetings became meetings where developers had to report progress to the product owner and Agile coach, detailing what they were doing and when it would be done. If the product owner thinks developers are spending too much time on things like automated testing, refactoring, or pairing, they’ll just tell the team to stop doing it. Strategic technical work has no place in their agile process. No architecture or design is required. The order is simply to focus on the highest-priority items on your to-do list, and then work through one highest-priority item after another as quickly as possible. This approach resulted in a long series of iterations of tactical work and the accumulation of technical debt. Fragile software, well-known singletons (or distributed singletons for teams trying microservices) become the norm. Bugs and operational issues are popular topics of discussion at daily stand-up meetings and retrospectives. Releases to production are not as frequent as the business might expect. The manual testing cycle still takes days, if not weeks, to complete. Hopes that adopting Agile could avoid all these problems have been dashed. Managers blame developers for not moving fast enough. Developers blame management for not allowing them to do the technical and strategic work they need. The product owner doesn’t see himself as part of the team and doesn’t take responsibility when things go wrong. An “us versus them” culture dominates. This is what we call an agile hangover. After years of investing in agile transformation, companies realize that they still encounter many of the problems of the past. Of course, Agile is also blamed for this.

Expectation mismatch

A purely process-focused agile transformation is a partial transformation. While agile coaches try to guide managers and delivery teams through agile processes, no one helps developers learn Agile technical practices and engineering. Correcting the assumption that collaboration among people will improve engineering is a mistake.

Agile adoption brings with it a big expectation that development teams should deliver production-ready software by the time a feature is completed, or at least at the end of each iteration. This is an important change for most development teams. They can’t do this without changing the way they work, which means learning and mastering new practices. But there are some problems. During agile transitions, there is little budget for improving developer skills. The business does not expect developers to slow down when adopting Agile. Most people don’t even know that developers have to learn new practices. They were told that if they worked in a more collaborative way, developers would work faster.

It is unrealistic to think that teams can develop these skills simply by creating a more collaborative environment. Teams need support in acquiring these technical skills. This support can be achieved through a combination of mentoring, training, experimentation and self-study. Business agility is directly related to the speed at which companies develop software, which means the development of their engineering skills and technical practices.

Stay away from

For some companies that adopt Agile management, the divide between agile process and engineering is still hurting them, even though the company is better off than before. Most modern Agile coaches do not have sufficient (if any) technical skills to guide developers in technical practices, and they rarely talk about engineering. Over the years, developers have come to see Agile coaches as just another layer of management: people telling them what to do, rather than helping them do their jobs better.

With less focus on technical skills, can Agile significantly improve software projects? Is Agile still focused on discovering better software development methods by developing and helping others, as stated in the Agile manifesto? I’m not sure.

Software craftsmanship

To raise the bar for professional software development and re-establish some of the original Agile goals, a group of developers met in Chicago in November 2008 to create a new movement: Software Craftsmanship. At that meeting, as at the Agile Summit in 2001, they agreed on a set of core values and produced a new manifesto.

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.
• That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

As aspiring software craftsmen, we have been raising the bar for professional software development and helping others learn the craft. Through this work, we have established the following values:

• It’s not just about making the software work, it’s about making it work.
• Not only respond to change, but steadily add value.
• Not only should there be individuals and interactions, but also a community of professionals should be formed.
• Not only to work with customers, but also to build fruitful partnerships.
• In other words, while the left is worth pursuing, the right is equally indispensable.

Well-written software means well-designed and tested code. We are not afraid to change the code that enables the business to react quickly. It is both flexible and robust code.

Steady value-added means that whatever we do, we should be committed to continuously providing value-added services to our customers and employers.

A community of professionals means we need to share and learn from each other to raise the bar in our industry. We are responsible for developing the next generation of developers.

Productive partnerships mean professional relationships with clients and employers. We will always maintain an ethical and respectful attitude to advise and work with our clients and employers in the best possible way. We look forward to a respectful and professional relationship, even if we need to take the initiative and lead by example.

Ideas and Methods

Ideology is a system of ideas and ideals. Methodology is a system of methods and practices. Ideology defines the ideal of the goal. One or more means can be used to achieve these ideals, they are means to an end. When we look at the Agile Manifesto and the 12 Principles, we can clearly see the ideology behind them.

The primary goal of Agile is to provide business agility and customer satisfaction through close collaboration, iterative development, short feedback loops, and technical excellence. Methods such as Scrum, Extreme Programming (XP), Dynamic Systems Development Methods (DSDM), Adaptive Software Development (ASD), Crystal methods, Functional Driven Development (FDD), and other agile methods all serve the same purpose.

Methods and practices are like training wheels, they move people easily. Like children learning to ride a bicycle, training wheels enable them to use them in a safe and controlled manner. Once they are more confident, we raise the training wheels slightly so they can work on their balance. Then, we take one of the training wheels off. And then another one. At this point, the child is ready to walk alone. However, if we focus too much on the importance of training wheels and keep them on for too long, the child will become too dependent on them and not want them removed. An excessive focus on a methodology or set of practices diverts teams and organizations from their actual goals. The goal is to teach children to ride bikes without training wheels.

Does software craftsmanship have practice

The software craftsman community considers XP to be the best set of agile development practices available today. TDD, refactoring, simple design, continuous integration, and pair programming are strongly promoted in the software artisan community – but they are XP practices, not artisan practices. They are not the only ones. Artisan also advocates cleaning practices and SOLID principles. It promotes small commits, small releases, and continuous delivery. It promotes modularity in software design and any type of automation, thereby eliminating manual and repetitive work. Moreover, it advocates any practice that increases productivity, reduces risk, and contributes to the production of valuable, powerful, and flexible software.

Craftsmanship involves more than technical practice, engineering and self-improvement. It is also about professionalism and enabling clients to achieve their business goals. This is an area where agile, lean and craft converge. All three objectives have similar objectives, but address problems from different but equally important and complementary perspectives.

Focus on values, not practices

A common mistake in the Agile and software craftsmanship community is to promote practices rather than the value they provide. Let’s take TDD as an example. One of the most common questions in the software craftsmanship community is “How do I convince my manager/colleagues/team to do TDD?” This is the wrong question. The problem here is that we offer solutions before we agree on them. If people don’t see value, people won’t change the way they work.

When discussing practices, it is crucial to first agree on the goals to be achieved. The only thing that should not be accepted is to refuse to practice without offering a better alternative.

To discuss the practice

Discussions about practices should take place at the appropriate level and with the appropriate personnel. If we want to adopt practices that improve collaboration between business and technology, we should involve both business and technology people. If developers are talking about practices that enable them to build systems in a better way, there is no reason to involve business people. Business personnel should be involved only if there is a significant impact on project cost or project duration.

Developers should not ask for authorization to write tests. They should not have a separate responsibility for unit testing or refactoring. These technical activities should be incorporated into the development of any functionality. They are not optional. Managers and developers should only discuss what will be delivered and when, not how. Every time developers volunteer detailed information about how they work, they invite managers to micromanage them.

Are we saying developers should hide how they work? Not at all. Developers should be able to clearly describe how they work and the advantages of working this way to anyone who is interested. What developers shouldn’t do is let other people decide how they work. Conversations between developers and the enterprise should be about why, what, and when, not how.

The impact of craftsmanship on individuals

People often separate their own lives from their professional lives. Phrases such as “I don’t want to talk about work when I leave the office” or “I have different interests in life” are expressed in ways that make work seem like a household chore, a bad thing or something you have to do rather than something you want to do. The problem with splitting our lives into multiple lives is that they clash all the time. There is always a feeling that whatever life we choose, we must sacrifice another.

Craftsmanship can promote software development as a career. There’s a difference between a job and a career. Work is something we do, but not a part of ourselves. Professionalism is part of who we are. Majors are what we invest in. We want to get better. We want to acquire more skills and have a long and fulfilling career.

That doesn’t mean we won’t be with our families or have other interests in our lives. Rather, it means finding a way to balance all commitments and interests. Sometimes, we want to focus more on our family, our career or hobbies we may have. That’s all right. We have different needs at different times. However, when we have majors, going to work should not be a tedious thing. It should be something that brings us joy and makes us individuals. Majors give meaning to our lives.

Artisan’s influence on the industry

Since 2008, more and more software craft communities and conferences have been organized worldwide, attracting thousands of developers. The Agile community focuses on the people and process aspects of software projects, while the artisan community focuses more on the technical aspects. They are key to spreading XP and many other technology practices to many developers and companies around the world. Through the software artisan community, many developers are learning about TDD, continuous integration, pair programming, simple design, SOLID principles, clean code, and refactoring. They also learn how to build systems using microservices, automate their deployment pipelines, and migrate their systems to the cloud. They are learning different programming languages and paradigms. They are learning new technologies and different ways to test and maintain their applications. Artisan community developers are creating safe and friendly Spaces where they can meet like-minded people and talk about their careers.

The software artisan community is extremely inclusive. From the beginning, one of the main goals of software craftsmanship was to bring software developers from all backgrounds together so that they could learn from each other and improve professional software development. The Artisan community has nothing to do with technology and all developers, regardless of their level of experience, are welcome to attend the conference. The community is dedicated to developing the next generation of professionals, hosting events where people joining our industry can learn the basics of building useful software.

The impact of craftsmanship on the company

The adoption of software craftsmanship is growing. Many companies that adopt agile are now looking to artisans to improve their engineering capabilities. But software craftsmanship has a different business appeal than agile. XP is still something many managers don’t understand or get excited about. Managers understand Scrum, iteration, presentation, retrospectives, collaboration, and rapid feedback loops. But they are not so interested in programming-related technology. For most people, XP is about programming, not agile software development.

The idea of software craftsmanship is the inspiration for many developers. It gives them a sense of purpose, a sense of pride and an innate willingness to get things done. In general, most developers are passionate about learning and doing well, they just need support and an environment where they can thrive. Companies that embrace software craftsmanship often see an internal community of practice flourish. Developers organize internal meetings where they code together, practice TDD, and improve their software design skills. They are interested in learning new technologies and modernizing the systems in which they work. They discussed better ways to improve the code base and eliminate technical debits. Software craftsmanship promotes a culture of learning that makes companies more innovative and responsive.

Craftsman and dexterity

Some of the triggers for creating software craftsmanship have to do with the frustration many developers feel with agile development. As a result, some people see software craftsmanship and agile as contradictory. Software craftsman activists who have been involved in the Agile movement have criticized agile for focusing too much on process and not enough on engineering. People in the Agile movement have criticized software craftsmanship for its narrow focus or lack of focus on practical business and people issues.

While there are legitimate concerns on both sides, most of the differences have more to do with tribalism than actual fundamental disagreements. In essence, both movements hope to achieve very similar goals. They both want customers to be happy, they both want to work closely together, and they both value short feedback loops. Both want to provide quality, valuable work, and both want to be professional. To achieve business agility, companies need not only collaborative and iterative processes, but also good engineering skills. Combining agility with software craftsmanship is the perfect way to achieve this goal.

conclusion

At the Snowbird conference in 2001, Kent Beck said agile is about bridging the gap between development and business. Unfortunately, when project managers flood the Agile community, the developers who created it in the first place are deprived of value and undervalued. So they left to join the software craftsman movement. So the old mistrust continues. However, the value of agility is highly consistent with the value of software craftsmanship. The two actions should not be separated. Hopefully, one day, they can get together again.

conclusion

Agile is perhaps the most important and enduring revolution in software processes and methods that we have ever seen. The importance and persistence of this spirit attest to the 17 men who went to Snowbird, Utah, in February 2001 to start a snowballing movement down a long hill. It was a real pleasure for me to ride snowballs and watch them roll bigger and faster and hit rocks and trees.

I wrote this book because I thought it was time for someone to stand up and speak out for what Agile is and should be. I think it’s time to remember the basics.

These basic things were, are, and always will be Ron Jeffries’ Circle of Life. These foundations are the values, principles, and disciplines of Extreme programming described by Kent Beck. These foundations are Martin Fowler’s reconstruction of motivation, technique, and discipline. These foundations were developed by Booch, DeMarco, Yourdon, Constantine, Page-Jones, and Lister.

These basic principles are old, tried and true. No matter how much new fluff is added to the edges, these foundations are still there, still relevant, and still at the heart of agile software development.