Transparency

Transparency, or even transparent communication, creates a mutual understanding of standards, a common language so that the process can be shared and understood, and most important, a transparent understanding of the definition of done. As you go forward through many of the various aspects of Agile project management, you will see a common theme of openness and communication about value, processes, techniques, and even how to manage risks and issues. The entire focus is based on the understanding that everyone knows what everyone else is doing and how they are doing it. If someone makes a mistake, they own it and work as a team to fix it. Transparent and clear communication across all aspects of the Scrum framework sets the stage for effective production of “done” increments and a team atmosphere of unity.

Inspection

As with many Agile methodologies, frequent inspection of the increments is a highly important aspect of producing to spec and being “done.” In the Scrum framework, frequent inspection also allows progress toward the overarching Scrum goal and allows for identification of variances that would keep the result from being accepted. While frequent inspection is a crucial aspect of Scrum theory, performing inspections too frequently will do the opposite and actually can hinder progress. Too frequent inspections will disrupt the work rather than promote effective execution of it. It is usually a promising idea to have a skilled inspector review the results and work with the team to improve them, but not all organizations have inspectors on hand to do so. Therefore, continuous improvement in those practices would need to be the focus. It makes sense if you are creating something, or if you are the customer, to inspect the results to make sure that you are doing things right and building the right thing.

Adaptation

The final pillar in Scrum theory is adaptation. Think of the word agile or agility, which describes the ability to adapt and change directions as needed. In Scrum, if inspection shows a result that is not acceptable or that is undesirable, this then points to a problem in the process and the execution of the process. If the process is deemed to be not working and affecting the result or increment, the process itself must be adjusted.

This does not mean that you switch from Scrum to something else like XP. It simply means that the process is not being effectively executed, and it’s necessary for the team to adapt or revisit best practices of Scrum and constantly check to make sure the process is working. Adaptation also points to the way the process is being used and whether the customer is getting the value they expected. The further you go without adapting, the worse it can get. You open yourself to risks and issues and deviate further from the value that you were supposed to create. This doesn’t mean that you don’t have creative license in software design, because it is very much both a science and an art form. The bottom line, however, is if the process isn’t working, it’s time to adapt. Much like the definition of insanity is doing things the same way and expecting a different result, the adaptation pillar is there to make sure that you can adjust your direction and provide a better process to produce the result. Always Practice Agility!

Scrum Values

Even though Scrum is a lightweight framework, there are very specific events that are used for inspection and adaptation. If they are not done correctly, it could lead to the need to review the execution of the framework and to determine if changes are necessary.

The Product Owner

You’ll start with the product owner, whose main job is to maximize the value of the product and the value of the work of the development team.

The product backlog contains all of the possible items that could go into a result or increment requested by the customer. Because the product owner is the sole party responsible for managing the product backlog, it is their job to express clearly what items are in the backlog and, at the same time, reorganize and reorder work items in the best way to achieve the goals and mission of the project while balancing the requirements set by the customer. The main reason for this is to optimize value so that whatever the development team is working on will produce a valuable, usable increment.

That doesn’t mean that the development team and Scrum Master have no idea what’s in the backlog. The backlog is transparent and visible, so it is clear to all involved what work is next on the list. Because the product owner is accountable for the product backlog, they are also accountable for making sure that the development team understands the items in the backlog to whatever level is necessary to accomplish the work. This means that the product owner is constantly in contact with the customer, other stakeholders, the development team, and the Scrum Master.

The Development Team

Once the product owner decides which items in the backlog are the most valuable, the development team will do the work of producing a potentially releasable increment at the end of each 30-day sprint, which is a typical length of a Scrum sprint. We will discuss sprints in depth later in this chapter. The development team itself is designed to be small enough to adapt quickly to changes and risks, and to be Agile but also large enough as well to complete the work. In a perfect world, the Scrum team would be somewhere between seven and nine members. This is so that the team is structured correctly and empowered to organize and manage its own work.

What is interesting about a Scrum development team is there are no distinct titles other than “developer,” regardless of the work being done—no exceptions. That may be very different for your organization, where there are some team members, such as testers or business analysts, outside of the development team. On a Scrum development team, they are all developers with different skill levels and different knowledge, but the entire team is accountable for the work they do.

Scrum Master

That brings us to the Scrum Master, who is described as a servant leader. A Scrum Master is responsible for making sure Scrum is understood, making sure the Scrum team adheres to the Scrum framework’s practices and rules, and keeping the ball rolling in general. You might think, isn’t that just describing a project manager? In its truest generic sense, you could call a Scrum Master an Agile project manager.

Because organizations tend to try to implement Scrum without seeing the value of a Scrum Master, often Scrum is blamed for not working. Notice that the Scrum Master is described as a servant first and a leader second, not a manager, nor a business analyst, and not a senior stakeholder.

The goal of the Scrum Master is to maximize value in all interactions with the product owner, the development team, and the entire organization. Their role in the organization is to make sure that Scrum is effectively implemented from the top down and from the bottom up.

Let’s look at some of the interactions that the Scrum Master might have on a regular basis and why those interactions are important for effective implementation of Scrum as well as for effectively answering exam questions.

The Product Backlog

The product backlog is a list of all features, functions, requirements, enhancements, and fixes. The backlog is dynamic, and it is constantly changing as value is recognized and new decisions are made by the product owner. It encompasses descriptions, the order in which work will be accomplished, and the items that are of most value to produce in the moment. Because all Agile methodologies are based around the ability to adapt, the backlog will evolve as the product evolves. Also, the environment in which the product will be used is evolving as well. That is the dynamic nature of providing value and how it can change on a regular basis. In that respect, a product backlog is never complete.

Another key element of Agile methodologies, including Scrum, is that the customer doesn’t necessarily need to know every single thing that they want and need in the increment or finished product right at the beginning of the project, or even halfway through it. The customer may only know what they want the end result to do.

The Sprint Backlog

Because the product backlog is constantly changing and being updated, it is necessary to set goals and to forecast what the increment might look like at the end of an iteration called the sprint. That is why there is a sprint backlog. Basically, a sprint backlog is just an itemized version of the overarching product backlog, but it is based on the backlog items that have been selected to be accomplished right now.

It is also important to put together a plan for delivering the product increment as well as realizing the goal of the sprint itself. This is not done in a vacuum, however. It’s done with transparent communication between what the product owner discovers is valuable today and by the development team forecasting the work that is needed and that can be accomplished. This is necessary in order to deliver the chosen functionality into an increment that can be called “done” at the end of the sprint. It is also important to know that the sprint backlog provides visibility into all of the work that the development team identifies as necessary to meet the sprint goal. The Scrum Master perpetuates the vision on a regular basis.

INVEST

The INVEST acronym applies to having superior quality in the actual product backlog and serves as a way to check ourselves and not to produce defects or waste in the process flow. A good-quality backlog equals good-quality user stories, which in turn produce good-quality increments. It is a way of replacing or adapting the SMART acronym (specific, measurable, accurate, realistic, and time based) to be more specific to software development. INVEST can be used in Scrum, Kanban, Lean, and XP. As you will see in Figure 2.1, using the acronym as a guide can help define what success looks like and help the team create a product backlog that is efficient and well understood.

This definitely doesn’t mean that after the very first sprint the customer happily walks away with brand-new software that does everything that they want. What it does mean is that something usable will be created, which can be reviewed by the customer and adapted as needed. This would lead to updates in the product backlog, backlog grooming, and a refocus at the start of the next sprint.

This is where Scrum events or activities/ceremonies begin.

Sprint Planning

There is a seemingly false assumption that Agile projects don’t have any planning at all. In fact, you may see questions on your exam relating to a misunderstanding by key stakeholders that planning is nonexistent on an Agile project. While unnecessary documentation is considered a waste, that doesn’t mean that planning does not occur. In fact, frequent planning replaces front-end planning, which could prevent massive amounts of surprise changes, scope creep, other risks, and sunken costs.

Sprint planning is an integral part of producing value. The actual sprint planning meeting is timeboxed. The simplest way to describe a timebox would be a set a time frame in which certain Scrum events occur. Much as you might say, “We will have a one-hour status meeting,” in Scrum you would say we are having a timeboxed status meeting of one hour. Different events in Scrum are timeboxed to benefit the sprint and make the time spent during those events as valuable as they can be. A single timebox for sprint planning falls somewhere between eight hours for a one-month sprint and shorter time frames for shorter sprints. Part of the Scrum Master’s job is to ensure that the sprint planning event takes place and that everybody understands its purpose and, most important, keeps it within the timebox. Crucial planning questions will include what can be delivered in the increment at the end of the sprint and how the required deliveries will be achieved.

The entire Scrum team is helping to achieve the correct results of each sprint, but each facet is contributing in its own way. The development team’s job is to forecast what functionality is to be developed during the sprint. The product owner keeps the team focused on the objectives that the sprint should achieve and the backlog priority items that are necessary to achieve it. The Scrum Master makes sure the event happens within its assigned timebox. The Scrum Master also maintains the vision and provides coaching as needed.

Eight hours may seem like a very long meeting to most, but spending eight hours to accomplish a done increment effectively at the end of 30 days takes some planning. There are key collaborations among the Scrum team so that everyone understands the work that needs to be done and exactly what the definition of done is. Consensus by the team is necessary so that everyone is aware of the goal and agrees to it.

Other aspects of sprint planning are reviewing the product backlog, product increments that may have been produced prior to this planning meeting, projected capacity of the development team during the sprint, and a focus on continuous improvements by looking at past performance.

It is the development team’s job to take the advice of the product owner and the backlog information, but the bottom line is that there are several items to accomplish in the sprint. It is totally up to the development team to identify those items. Remember that the team is self-directed and self-managed, so the assumption is that they know the capacity that they can achieve and will select accordingly.

During the wrap of the meeting, the development team forecasts the product backlog items that it will deliver in the sprint. The team will then create their sprint goal.

In a perfect world everything will go smoothly, but there may be trade-offs or conversations and even negotiations during the sprint planning meeting. The big question is how will it all get done? The development team will decide how to build out the functionality into something that could be considered done at the end of the sprint. It is up to the development team to design a system that will work for them to produce a working product increment. You know from working on projects yourself that all work comes in a variety of sizes and levels of effort. The team will plan the first couple days of the sprint by taking bulky items and decomposing them down to the task level. If they determine that they have taken on too much or too little work, there may be a renegotiation of the selected product backlog items with the product owner.

It’s important to know that, even though the development team is cross functional, they may not have all of the answers up front, especially if it is something brand-new and totally unique. They may invite other people to attend the sprint planning meeting to learn and gather information as well as technical or other types of advice.

By the end of the sprint planning meeting, the development team should be able to explain to the product owner and the Scrum Master how they intend to accomplish the result and produce the anticipated increment. This then becomes the sprint goal.

The Sprint

When you think of the word sprint, you might think of running very quickly but not very far. It’s the same concept for an actual sprint in Scrum. The sprint itself is timeboxed to one month or less in order to have consistent durations in place for development efforts.

When the sprint backlog is created, it is formed with the assumption that whatever’s been selected can be accomplished in that one-month time frame. The result will be a usable and potentially releasable product increment. That does not mean that the project is totally over and complete; in fact, a new sprint starts immediately after the previous sprint is over until such a time when it is determined that the project is “done-done,” or that the product has been deployed.

Remember that Scrum is a framework, and while there is a lot of flexibility on the team level and with changes or updates, there are very distinct rules that need to be followed in order to provide structure for better understanding on an organizational level.

It would be up to the Scrum Master and the rest of the team to make sure no changes are made in the middle of a sprint that could endanger the goal or negate the production of quality increments. This doesn’t mean that the scope would never be clarified and renegotiated between the product owner and development team because learning is constant and changes are always expected.

An uncomplicated way to think of a sprint is to think about it as its own small distinct project with no more than a one-month time span. Something usable by the customer will come out of it. This doesn’t mean that it has all of the features and functions the customer wants; it just means that the customer will walk away with something that they can currently test, review, and use at the end of each sprint.

If you think about how much risk could be prevented by not preplanning the unknowns, you’ll find another reason why sprints are limited to one calendar month. Under the Scrum framework, the scope of work is a bit more buffered from the impacts of risk, and it also protects the budget because only a certain amount has been executed and paid for in any one month time frame. Now the customer can change their mind about certain features, the product owner can shift the value in the backlog, and the team can go into another sprint, producing something valuable and usable at the end.

Scrum of Scrums

Any organizations that are heavily involved in Scrum have more than one Scrum team, Scrum Master, and product owner. Therefore, it might be necessary to hold something called a Scrum of Scrums. The Scrum of Scrums meeting allows for larger-scale interactions between multiple Scrum teams in an organization. Each Scrum team will meet for their daily Scrum, and at the end one member will be designated as the ambassador and will meet with other ambassadors from other teams. This will allow a specific focus on the challenges of coordination between the teams and an overarching resolution to some of the impediments that the teams are facing. The Scrum of Scrums allows for tracking of these items and impediments in a backlog of its own where each item is contributing to improvement between team coordination. This allows the organization to improve collaboration on Scrum best practices across many teams focused on different projects. This is similar to a biweekly all-hands meeting where better ways of doing daily work are discussed. The Scrum of Scrum meeting is only held once or twice a week; otherwise, there is a risk of those meetings doing the opposite of what they are designed to do by creating impediments for each individual team. The questions are similar in nature to a daily Scrum, except on a team level:

• What has your team done since the last meeting?
• What will your team do before the next meeting?
• Is anything getting in your team’s way?
• Are you about to put something in another team’s way?

Elements of the Sprint Review

Even though the sprint review is looked upon as a more casual informal meeting, there are still some best practices that are followed. The attendees include the entire Scrum team and key stakeholders, which could include the customer. The product owner invites participants to the review and is also in attendance. Because this is a key inspect and adapt meeting, it is the product owner’s job to explain which product backlog items have been done and which have not been done. Then the development team will discuss what went well during the sprint, what problems they ran into, and how those problems were solved. The development team’s job is also to demonstrate the work that has been done and to answer any questions that anyone has about the increment.

The important thing about reviews like this is that it gives the customer an opportunity to touch, use, and inspect the increment that was produced. The act of doing this may very well change the backlog going forward. The product owner will discuss the product backlog as it stands today and any likely completion dates based on progress in the current sprint and to date as needed.

Keep in mind that this is typically a four-hour time-boxed meeting, so there is plenty of time to collaborate on what to do next. This will then provide valuable input to sprint planning for the next sprint. A key factor of all Agile methodologies is to try to figure out the most valuable thing to do next. This can be totally dependent upon the marketplace, or simply what the potential use of the product is by the customer and how that might have changed before or during the review

Because you’re looking at a sprint as its own singular entity or project, each sprint will have its own timeline, budget, potential capabilities, and anticipated release of the result. Once the sprint review is over, the Scrum team will have a revised product backlog that will define what could probably be done in the next sprint, and they may even have additional items that have moved up in priority or that may provide more value to the customer.

The Purpose of the Sprint Retrospective

In a lot of project management methodologies, the big focus is on the quality and the scope of the result. In Scrum and other Agile methodologies, however, the team is also looking at how the last sprint went with regards to people, relationships, and team interactions as well as processes, tools, and performance results. Once that occurs and the team has identified these items and placed them in a semblance of an order, identifying the major ones that went well and those that went not so well, it is easier to work through solutions. They have checked these items themselves for potential improvements, so it’s time to put together a plan to improve the way the Scrum team does its work. It is important to note that this is a very open and honest meeting. The team is transparent about their feelings on what went well, what did not go well, and what changes they would like to see made. By the end of the sprint retrospective, the Scrum team will have identified improvements that it will implement in the next sprint.

In Figure 2.2 you will see a very simple version of Scrum events, including the length of time for each event.

As you can see, the Scrum framework has a well-rounded approach to time boxing or scheduling, transparent communication, and interactions. A large focus of the team is that it is self-managed and self-directed, and an Agile project manager/Scrum Master keeps the sprint running smoothly while promoting the reasons for it and the vision of the result. Finally, a product owner determines what is valuable to the customer today and helps the team see the vision by constantly communicating that value.

As you will come to see, there are many other Agile methodologies. Beginning with Scrum, however, really lets you see that as you move forward, practicing agility is represented in all methodologies and you can turn around and start using some of the best practices immediately. Scrum is easy to explain and difficult to implement, but the more organizations begin to embrace or improve upon Agile best practices, the better they will be.

Key Aspects Of XP

The key aspects of XP include the following:

• Frequent feature and functionality releases
• Short life cycles
• Test-first development

Because of this, XP is one of the most popular Agile approaches. Over time, XP has been adapted from more rigid formats into something that is more usable and flexible. XP’s metamorphosis from the 1990s to what has come to be known as XP today is an excellent representation of Agile. Try something courageous, learn from it, and implement better/best practices because of lessons learned. Many times, organizations will utilize some aspects of XP with a hybrid approach, including aspects of Scrum.

XP Core Values

Part of getting into the mindset of Agile methodologies is to understand that a lot of the values and best practices overlap. Nevertheless, the constant goal is that all of your focus be on producing valuable product features and functional releases.

XP has five core values, and what you’ll notice is their alignment to the Agile Manifesto and much of what you learned about Scrum. The number one value of simplicity is quite crucial to much of the practice of agility, so keep it simple! The aspects of communication, feedback, and respect are transparent across all methodologies, and the ability to be courageous and try new things, make mistakes, and express your opinions is core, not just to XP but also to many of the Agile methodologies if not all of them.

• Simplicity
• Communication
• Feedback
• Courage
• Respect

XP Core Values Simplified

The core values of XP are very aligned to the Agile Manifesto as well as other Agile frameworks. In order to absorb the values into your day to day, it’s important to understand the meaning behind them.

Simplicity: Keeping things simple is paramount to successful results. If things are too complicated, then miscommunication, scope creep, and risks occur. The simplest way to produce the increment is what you will do. Nothing more, nothing less. You know that if your job responsibilities become too confusing or overwhelming, the odds of you being successful are very slim indeed, and if in fact you do what you are supposed to, you know that you will make mistakes along the way. Making things too convoluted or confusing muddies the waters and opens the door for many U-turns and corrective actions.

Communication: Having a shared understanding of requirements, common metaphors/similes to describe the work, frequent feedback, and face-to-face communication is the crux of many Agile methodologies, XP included. If everyone on the team has a shared vision of what success looks like, then the probability is high that they will reach it. That vison could change throughout the iteration, but it would be communicated and understood so that a new shared vision would be the focus.

You will see many ways Agile teams communicate above and beyond face-to-face communication as you go forward through other chapters and domain tasks in the exam content outline. Don’t worry, it’s not like the 8,000 emails a day you may receive. It’s low-tech, high-touch information radiating that speaks louder than words.

Feedback: Giving and receiving feedback is a necessary component in fast moving Agile projects. When developing software, you are getting feedback through frequent testing of the programming and the system. The customer is giving feedback on what is working, what needs to change, and what they find valuable today. You and your team are constantly engaged in communication and feedback with each other to determine the best ways to accomplish your iteration and project goals.

Courage: The quality of courage comes up a lot in Agile practices. It is part of the fabric of risk-taking industries like software development and technology projects. Because XP is very focused on programming, a lot of courage comes in the form of code modifications, keeping the design relevant and practical, and refactoring code as needed. Imagine spending 30 hours writing strings of code only to find out that it just isn’t working or that someone decides that it is no longer necessary. It would be exceedingly difficult to look at the delete key and actually push it after all that effort. It takes courage to delete challenging work.

Respect: Keeping an elevated level of motivation on development teams is a big focus of everything you will go through. Is everyone going to be motivated and happy-go-lucky all of the time? Of course not! But I know that it’s a heck of a lot easier to swallow constructive feedback if it comes from a place of respect. If I feel underappreciated, ignored, and underdeveloped as a professional, I tend to start updating my resume. The same thing goes for an XP team or any other Agile-type team. Self-respect and team respect allows for courage, effective feedback, effective communication, and an easier definition of simplicity across the board.

XP Roles

There are roles and responsibilities for XP projects that are similar to those for Scrum projects. Even though the titles may be different, there is still some overlap in both methodologies, which is why a hybrid approach is far easier between Scrum and XP.

The 13 Core Practices of XP

Next we will review the 13 core practices of XP in depth. These 13 core practices are as follows:

• Whole team
• Planning games
• Small releases
• Customer tests
• Collective code ownership
• Code standards
• Sustainable pace
• Metaphor (similes)
• Continuous integration
• Test-driven development
• Refactoring
• Simple design
• Pair programming

The 13 Core Practices Simplified

The 13 core practices of XP help set the groundwork for faster iterations and continuous feedback. The main focus of XP is software development, but many of the best practices can be seen in other Agile frameworks.

Whole Team: The entire XP team is colocated in order to improve communication, learning, and structure of process.

Planning Games: During release and sprint planning estimation, it may be a bit different from the typical “How many days will it take to finish the project?” and “How much will it cost?” questions found on many Waterfall projects. XP iteration cycles are only two weeks long, and so planning is done a bit differently. In fact, in both Scrum and XP as well as other Agile methodologies, planning games are used as an effective way to determine how much work can be accomplished in the iteration. Things like planning poker, T-shirt sizing, and affinity estimating are used instead of specific duration estimations of days and weeks. Once you get further into the chapters that incorporate duration planning, you will review planning games in much greater depth, and you’ll see what a cool and unique way it is to estimate.

Small Releases: Frequent releases and testing are important core practices in XP and Scrum. But in XP, the frequency is twice as much. Small releases over the course of two-week iterations allow the team to produce the code, test the code, release the code, and gain feedback on it quickly.

Customer Tests: As you can see, XP is much more focused on software development than some of the other methodologies and frameworks. To make sure that the software that is being developed really works, customer tests are necessary. It’s not as you might think, though. It is not a matter of the customer physically testing the software—it is the team creating tests in advance that are automated in order to prove that the test criteria from customer requirements for working software is managed effectively. It would also be safe to say that the customer will inevitably test the finished increment as well.

Collective Code Ownership: Much as with Scrum, the entire XP development team owns their work. In XP, there is a collective code ownership that is shared, and it helps build out knowledge for everyone on the team. One of the greatest things about Agile methodologies is that you’re not going to see a lot of finger-pointing when mistakes are made because if one makes a mistake, the entire team owns it and helps overcome it.

Code Standards: Because the focus of XP is software development and the actual coding that the programmers do, there has to be a consistent approach to writing the code until a better approach is determined. This makes it very easy for one person to write the code and another person to review it and then switch places. Having very specific code standards means that anyone could work on the code at any given time and produce a similar result.

Sustainable Pace: Many of us work more than 40 hours a week, and I’m sure you’ve experienced the burnout that comes with that when trying to wrap up a project. The beauty of XP is the concept of sustainable pace. This means no more 40+ hour workweeks and absolutely no overtime (if possible). This then becomes a sustainable pace to infinity and beyond. There is no calling in sick just to get some rest or having a disgruntled team and the inevitable mistakes that occur when people are exhausted. Organizations and customers not having to pay for overtime also helps keep the budgets where they need to be.

Metaphor (Similes): Anytime there’s a difficult concept to grasp or understand, using a metaphor or a simile can help. It works by explaining the concepts in an understandable way through the use of an example that is relative to the individual’s experiences. The person who is attempting to understand can clearly grasp it quickly because they can relate to the metaphor/simile.

When you think of software code, it can be a bit overwhelming for the novice or for someone who doesn’t have that skill set. Metaphors or similes help to explain concepts in understandable ways to all.

Continuous Integration: Imagine how frustrating it would be to purchase a software program that has all of the features and functions that you want but nothing is integrated or works well together. Maybe you have purchased software that does word processing, offers spell checks, and prints documents, and you think that you have everything you need. However, when you go to use the software for word processing, you have to close and reopen it. Next, when you want to spell check your document, you have to close and reopen it again! Finally, when you want to print your document, you have to close and reopen it still yet again! This would certainly get tedious after a while.

Thus continuous integration is important in order to make sure the software works together the way that you would expect. That’s why continuous integration testing on a frequent basis is one of the core competencies of XP. Is the software working together, or is everything going its own direction?

I have a friend who is a professional dog walker, and watching her walk five dogs at once going in five different directions reminds me of how frustrating it is to not be continuously integrated. This is why running the tests often helps to find compatibility problems sooner rather than later. Discovering problems later in the iteration creates a lot of rework and furious coding up to the deadline.

Finally, everyone needs to be working on the most up-to-date version as well. You know this through communication. It doesn’t make sense to update something that is obsolete.

Test-Driven Development: Imagine that before you began to study for the Agile exam, or even read the study guide, I handed you all of the questions in a practice exam that you were going to see on your actual Agile exam. Chances are that you would fail the practice exam the first time out of the gate and maybe even the next five times. At the same time, you would learn what the result is supposed to look like, and even though you expected to fail the practice exam numerous times, as soon as you pass, you know that you’re ready for the real exam.

The same thing is true for test-driven development. The tests are written before the code. You know going in that if you do this, the initial code will fail, but as soon as it passes it is correct.

This is the opposite of many project management methodologies that produce first and test later. A lot of defect repair, scope creep, and replanning come with that mentality.

It makes sense when you are building a bridge or skyscraper to have a formal front-end plan. It’s tough to test a bridge by walking on it when it only has the footers built. Because XP iterations are so short, the team knows going in what they are trying to accomplish and what the behavior of the code should be. They can then build a test first, knowing that it will fail.

This is kind of a freeing notion, isn’t it? That is, I know I’m going to fail, and if at first I don’t succeed—try, try again until I pass. This is a change in the paradigm of today’s success-driven culture. Imagine that you’re successful if you fail because you have to fail to succeed.

Success consists of going from failure to failure without loss of enthusiasm.

Winston Churchill

Refactoring: You know in life and in software that there are many ways of accomplishing the same result. A large part of the process of refactoring is to improve the code design continuously without altering functionality. This means that a customer gets the same result, but maybe it works more fluidly based on the refactoring. Most of us who use software don’t really think about the factoring or design of computer code—you just want the external behavior that you’re looking for to work. Peeking into the matrix isn’t a typical day for many people, but everyone is an end user of software. People who write code for a living, however, may notice duplications or behaviors of code that are unnecessary, even though they don’t impact the final increment.

Refactoring is beneficial in a lot of ways because it is a lot easier for somebody to go back and fix a bug in the source code if it is easier to read. It is also easier to expand the capabilities of an actual application if they used recognizable patterns in the design.

It is unnecessary to truly understand the coding of software for your exam, but one of the topics that you will cover in upcoming chapters is tech debt. If the team fails to perform refactoring on a regular basis, an accumulation of tech debt can occur. If that happens, it will distract the team from the work at hand. It will also add up over time, and it must be dealt with eventually. In fact, many iterations or sprints may have to accommodate some tech debt on a regular basis so that it doesn’t spin out of control. Some of that tech debt could also be from prior iterations.

Simple Design: What is the simplest thing you can do that will still work? That is really the premise of simple design in XP. The goal at the end of each iteration is to produce a workable increment—the more complicated it gets, the longer it takes, and this can amp up the risk of failure.

This goes back to the philosophy of keeping things simple across all methodologies of Agile. If the customer wants a software program that word processes, spell checks, and prints documents, then what is the simplest way to get to that result? Certainly, you’re not going to spend a lot of time and energy adding additional scope and functionality. You want to keep the code as simple as possible and make sure the result was what the customer requested.

Simple design reduces the risk of failure, which can be very costly in the long run. This doesn’t mean that failure never happens, and it also doesn’t mean that risk events don’t occur. Keeping it simple, though, does minimize those risks and helps to keep them to a controllable level.

Pair Programming: One of the most discussed aspects of XP is the fact that pair programming is involved in the software design. It is exactly what it sounds like—a pair of programmers programming.

The way that it works is that one programmer will write the code while another basically looks over their shoulder and determines if the code is good quality or if it contains a mistake—basically if it is looking good to them. Then they switch.

When I first learned about this, it reminded me of highway road workers in the way that 1 person is always working while another 20 people stand around and watch. How could anything possibly get done? That misconception, as it applies to pair programming (not road work), is why a lot of organizations will push back against this philosophy. They believe that productivity is stilted by having two people work on one thing at the same time. Believe it or not, however, the opposite is true! More work is done faster, with better quality and transparent communication that leads to learning following this philosophy. It also keeps the coder accountable for a simple design, continuous integration, and test-driven development. It’s a lot like having a spell check on your computers that gives you a gentle reminder by underlining words that you have misspelled so that you can go back and correct them. I’m pretty sure my editor is thankful for that particular feature. Two heads are better than one.