Agile Project Management
Agile is also the most interesting and flexible approach to project management.
Agile is not a project management methodology in and of itself, but more of an overarching approach and philosophy to deliver value to customers, which is the goal of most projects. Despite not being a specific methodology, there are lots of frameworks and methods under the Agile umbrella.
The term Agile refers to being able to move quickly and easily. It also refers to flexibility and the willingness and ability to change and adapt. Projects that adopt Agile project management take an iterative approach, which means that project processes are repeated, often many times during the life cycle of the project.
In this case, the team operates within many shorter blocks of time called iterations. Individual iterations might get repeated depending on the feedback received. During each iteration, the team takes a subset of all the projects activities and does all the work required to complete that subset of activities. You can think of it as a lot of mini waterfalls for each activity. This iterative approach enables the project to move quickly, as well as making it much more adaptive to change.
So the term Agile means flexibility, repetition, and openness to change. But what do we mean by Agile project management? Agile project management is an approach to project and team management based on the Agile Manifesto. The manifesto is a collection of four values and 12 principles that define the mindset that all Agile teams should strive for.
Waterfall is a popular project management methodology that refers to the sequential or linear ordering of phases. You complete one phase at a time, not proceeding to the next until it is done. Then you move down the line, like a waterfall, starting at the top of a mountain and traveling to the bottom.
So in very basic terms, Waterfall is linear and sequential and does not encourage changing up the process once it is started. Agile on the other hand is iterative, flexible, and incorporates necessary changes throughout the process. Now, a bit of a history lesson, so you can have a better sense of how and why Agile has become such a popular approach to project management.
History of Agile Management
Agile methodologies emerged organically during the 1990s as the software industry was booming. Software startups like Google were blazing a trail to get more software products built in less time. Meanwhile, the tech giants of the time were experimenting with faster ways to build better software and stay competitive. And by the way, software isn't just the apps and websites that we all use every day. Software also includes the code behind innovations in agriculture, medical devices, manufacturing and more. So in this competitive growing environment, companies couldn't just create new innovative products. They also needed to innovate the very processes they were using to develop those new products.
In 2001, the thought leaders and creators of some of these new processes, also called methodologies, came together to find common ground between their methods and solve a problem. The problem they agreed was that companies were so focused on planning and documenting their project, that they lost sight of what really mattered; pleasing their customers. So these leaders came up with the Agile Manifesto to guide others on what they believed really matters when developing software, which is keeping the process flexible and focusing on people, both the team and the users over the end products or deliverables.
Now here's where Agile gets even more interesting. You can still use Agile, even if you're not planning to work on software projects. Agile has been so successful in the software industry that its values, principles, and frameworks have been applied to nearly every industry. In fact, the Agile methods that you're going to learn also draw heavenly on Lean manufacturing principles that originated in Toyota's car factories in the 1930s. You'll also find Agile methods being adopted in the aeronautical, healthcare, education, finance industries, and even more. Cool, right? Agile is everywhere.
Agile and Waterfall Project Management
Agile was created in response to the strict linear process of Waterfall. While Waterfall aims for predictability and tries to avoid change, Agile embraces the reality that the world, markets, and users are uncertain and unpredictable. For example, your customer might say they want feature A, but when the final result is delivered, they realize they actually wanted feature B. Agile aims to solve that problem by getting customer feedback more quickly, to make sure that the team is building what the customer really wants.
Part of working with an Agile mindset is always seeking out ways to work more efficiently. We do this by finding ways to streamline processes without reducing product quality or value. The key to streamlining is to reduce waste. For example, unnecessary documentation is a form of waste. Another form of waste is spending weeks or months working on a feature, only to find out that the customers, who could also be users or stakeholders, don't like the feature after all. You could reduce or eliminate both of these forms of waste by increasing team and stakeholder collaboration. More collaboration means less documentation and earlier feedback about the product.
Let's consider some more differences between Waterfall and Agile. Three important aspects of a project are: requirements, documentation, and deliverables.
Requirements
Requirements are conditions that must be met or tasks that must be finished to ensure the successful completion of the project. Think of these as the set of criteria that fall within the scope of your project or a list of specifications that must be met. In a Waterfall project, you'll probably need a product requirements document, which lists the scope and requirements of the project. You need to have several formally approved project plans, and you might have a team of people whose job it is just to write and approve these plans. You might also set up a change control board, a formal and rigorous process to manage any changes to requirements. All this is designed to protect the team from building something that the client or stakeholders don't want and aims to minimize any changes that could lead to scope creep.
Formally approved project plans work well when the desired end product is known and understood. An example of this might be leading a project that has clear requirements and goals based on mandated regulation. But if that's not the case, a waterfall team risks building out an entire deliverable, only to find out later that the customer doesn't like the final result. In Agile, requirements are treated as more dynamic and expected to change as the team receives feedback and new information. There is usually an initial set of requirements or feature ideas when the project kicks off, but that list of requirements and features is continuously growing and changing throughout the project. The team works with stakeholders to prioritize the requirements, always moving the most urgent or valuable items to the top of the list. Then the team goes down the list, working on the requirements in iterations. By going down the list, the team is able to get feedback on their work quickly and frequently. At the end of each iteration, the team gets feedback and can make necessary adjustments to the requirements before continuing on.
Documentation
The second aspect is documentation. All projects require documentation, project plans, stakeholder maps, schedules, charters, contracts. The list goes on and on. Waterfall projects use lots of documentation because there are lots of handoffs between phases and handoffs among different teams within the project. Also, because the work is done in bigger chunks, you'll need to leave behind more pieces of documentation at each stage in the project. But in Agile, there's an emphasis on real time, person-to-person conversations. This doesn't mean that there's zero documentation. It's just in a different form. Instead of big formal documents with a rigorous change management and approval process, there are shorter documents that have just enough detail to achieve their purpose. These documents are much more focused on what the reader needs to know to get the job done and are written only as needed.
Deliverables
A deliverable is a tangible outcome from a project. In Waterfall projects, you often don't release the deliverable until the very end. The final product release feels like a big event, major announcement, lots of hoopla, and is often super fun and exciting. Agile is just as exciting, but it has smaller, more frequent releases. So each release has a less formal celebration, but it builds up to be just as exciting. When there's lots of uncertainty in a project, such as in a new emerging industry or market, the steady release of project deliverables enables an Agile team to get feedback and learn as they go. Without regular feedback, the team could end up delivering something that the customer doesn't want.
So now you have a better idea of some key elements of Agile that distinguish it from Waterfall. Three differences between these two project management approaches are the way each one deals with requirements, documentation, and deliverables.
The Agile Manifesto
Being familiar with the Agile Manifesto will help you understand the core principles and values of Agile project management, so you can put them into practice on a project.
The Agile Manifesto was written in 2001 and brings together the collective wisdom of the people who developed it from their vast experience and thought leadership in the tech industry. If you'd like to find the manifesto, it's easy, just type in agilemanifesto.org in your search browser. We've made it available for you here in the course readings as well. Let's check it out.
The manifesto for Agile software development states: "We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more."
The manifesto is saying that it's helpful for every Agile team to think about both sides of each statement during the execution of a project, but should find ways to ensure that they're always placing more value and emphasis on the things on the left, over the things on the right. From the four values, a set of 12 principles were developed that reinforced the message of the manifesto. These values and principles inform the why, how, and what of Agile project management planning and processes.
Individuals and Interactions Over Processes and Tools
First, the manifesto emphasizes individuals and interactions over processes and tools. At its core, this value stresses people communicating with each other over using lots of processes and tools to force things to happen in a certain way. For example, have you ever emailed someone with a question and ended up in a long back and forth exchange due to simple follow-up questions or clarifications? Chances are that you could have gotten the same information in less time with a brief conversation. Agile wants to ensure that teams work together, collaborate, and help each other achieve the best outcomes they can. Agile also values individual perspectives and creativity. This does not mean that every team is chaotic. The value just means that processes and tools should be used to facilitate and drive good project management and improved collaboration within the team, and should never be used as a barrier to teams working well with each other.
Working Software Over Comprehensive Documentation
The second value emphasizes working software over comprehensive documentation, meaning the teams should prioritize spending time working on things that actually create value and avoid spending any more time than they really need on debating, writing, and reviewing documents.
Now, this value might seem like it only applies to software projects, but just replace the term working software with whatever your project is trying to deliver. Maybe the project is writing a legal brief, designing an office layout, or preparing a sales presentation. Whatever your project is trying to deliver, is the thing that creates value. In other words, it's more important to deliver the product the customer wants than to comprehensively document the process that you used.
Customer Collaboration Over Contract Negotiation
Onto the third value; customer collaboration over contract negotiation. In Agile projects, the customer satisfaction is considered the highest priority of building a high quality and valuable product.
After all, if it's not valuable to the customer, then there's little point spending time on it. When the manifesto discusses contracts, it refers to the official documents that require sign off and formal agreement with the customer, such as those huge requirement documents or formal change requests, Agile values having the freedom to collaborate with customers early and often. In doing so, teams can quickly react and adapt to what customers need rather than waiting out the process of negotiating contract terms. Just to make a few changes or request resources. There will still be contracts with Agile project management, but the focus is on identifying what's really needed and leaving space for collaborative customer-focused work. Agile teams are encouraged to seek out every opportunity to include the customer or stakeholder during project execution. This could be presenting early prototypes, asking questions, or bringing them in to do some initial product testing.
Responding to Change Over Following a Plan
And finally, we have the fourth value, responding to change over following a plan. This last value is crucial to an Agile project. As I explained in the history overview, Agile grew out of a world that was changing so fast that organizations couldn't adapt and struggle to survive. As a result, this value stresses that every Agile team needs to acknowledge that change is inevitable. The larger, longer, and more complex your project is, the more uncertainty there is. For many projects, finalizing a well-established plan at the beginning of the project will likely lead to an on-time delivery within budget, but may run the risk of not meeting customer needs or adding maximum value.
As a project manager, the key takeaway to remember here is that the most successful projects are the ones that are able to smoothly integrate change. Agile project managers still create and value their plans, but they can cope with and are able to adapt if the plans need revising at any time during the project.
So there you have it, the four Agile values: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan.
What's great about Agile is that it gives us these values and also lets us find the right balance between the two sides. You may have to fine tune your project style to meet industry needs, team dynamics, and organizational goals to find the healthy balance that works for you and your team.
The 12 principles can be put into four themes. These are different from the four values. The four themes of the Agile principles are:
- value delivery, or how do Agile teams deliver highly valuable products to their customers
- business collaboration, or how do Agile teams collaborate with their business partners and stakeholders to create business value to the organization and their users
- team culture, or how does a team create and maintain the right interpersonal and team dynamics to deliver value for the customers and the business;
- and retrospectives, or how does the project learn to continuously increase performance of an organization and business?
1) Value Delivery
The first theme is value delivery and includes five principles. Take a few seconds to review them. This theme is about delivering the work as quickly as possible. And remember why? So that we can get feedback and mitigate the risk that we spend too much time building the wrong thing. Also, no one gets any value from your work, including your company until you deliver it. So the longer you take to deliver, the longer you wait to get revenue, and maybe the more time the competition has to get ahead of you. These may look very software oriented, but if you replace the word software with deliverables or solutions, these can apply to almost any project.
The value theme is also about simplicity. How much time do you think it takes engineers to add all the buttons and features to products that ultimately end up confusing the user? Simplicity allows a team to focus and work on the things that matter the most. An example of this theme in action might be prioritizing getting feedback on a product prototype so you know which features really matter, or it might mean ensuring the team only works on approved features and doesn't spend time on unnecessary ones. Another example might be reserving 10% of the team's time to work on bug fixing or polishing a process, which should help you go faster in future iterations.
2) Business Collaboration
The next theme is business collaboration and includes two more principles. Quick note, one of the principles uses the term business people to refer to those involved with things like sales, marketing, customer support, and account management. We'll use the term developers to refer to those who are involved with making and creating products. So we discussed customer collaboration during the values discussion, and here we are again. Collaborating with your customers helps the team get critical business information immediately, allowing them to adjust and adapt to any new information instantly. No matter if it's realized early or late in the project, customers will get what they want to achieve their business goals.
You could achieve collaboration by making sure that business people work near the development team, ideally in the same office or virtual space. If that's not possible, maybe co-locating a day a week, encouraging instant messaging, or blocking off time on your team calendars each day or week to collaborate. The goal is to enable easy access between business people and developers. Another example might be how you handle feedback and changes and priorities. Rather than trying to keep the customer away from developers due to concerns about scope creep, create a weekly huddle where customers and business people can explore feedback and new ideas with the team. This could be a great way to discover that one really valuable feature is super easy to build, whereas another feature the users thought would be easy is actually really hard.
3) Team Dynamics and Culture
Our third theme is team dynamics and culture and includes four more principles. Remember, the first Agile value stresses individuals and interactions over processes and tools. Notice that the principles in this theme reflect that value. This theme emphasizes creating an effective team culture that is inclusive, supportive, and empowering. Having an effective team culture is essential to a project success. These principles really boil down to making sure your team is motivated to do the right thing, feels trusted to do the right thing, has the resources and space to work closely together on their goals and works at a sustainable pace. An example of emphasizing effective team culture would be to ask the team what kind of equipment they need to do their job, and then giving them those tools. Another manifestation of this theme is letting teams write their own processes and templates rather than forcing them to use something from headquarters.
Teams work best when they feel like their input is valued. So you as the project manager should make space for your team to engage and actively contribute to the team culture. You'll build trust and empower them to approach their work in a way that suits them best, which in turn will allow them to work more productively.
4) Retrospective and Continuous Learning
Finally, the fourth theme is retrospectives and continuous learning. The last principle stands alone in this theme, so I'll read it aloud: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." This one sits on its own because I want to draw attention to how important it is for Agile teams to continuously learn and adapt to what's working and what's not working for them. Teams should always be figuring out better ways to work. And it's really valuable to set this time aside after each iteration, to focus entirely on how to improve. In these sessions, the team can step back and consider questions like: how is the team doing? Are the customers happy? Are there processes we could optimize? Are our tools working for us? Are we following the values? Are we accumulating any debt? And by debt, I mean processes or technology that slows us down.
When to Adopt the Agile Mindset
Every project exists within organizations and settings with different cultures, business objectives, and industry dynamics. In this video, we'll discuss some different scenarios in which you'd want to adopt an Agile mindset. I'll also introduce you to a concept called VUCA, that can help you decide which management approach is best for your project. Remember, Agile is about delivering value in a world with high degrees of uncertainty, risk, and competition. It sets a team up to react as quickly as possible to new information, new market opportunities, and even new technologies. Agile works best in industries or projects that are susceptible to, or that encourage change and uncertainty.
What kinds of businesses or industries besides software come to mind that deal with lots of change? A few that I think of are biotechnology with emerging vaccines, treatments and technologies; media with endless new ways to share content; the food industry with celebrity chefs and the latest food craze; and fashion, an industry built on keeping up with shifting trends. Did any of these surprise you?
On the flip side, here are some industries that you might think of as fairly stable. Agriculture, aerospace, manufacturing, and mining, but even these industries with rigorous supply chains and codes have to adapt to change due to new laws and regulations, natural disasters, and other unforeseen issues. One thing that the year 2020 taught all of us is that no industry is truly immune to change and uncertainty. We're going to explore a concept for categorizing and thinking about these forces that shape our world, no matter what industry we're in. That concept is called VUCA, and it can help you decide which project management approach is best for you.
The US Military War College developed a concept called VUCA, spelled V-U-C-A. VUCA is an acronym that defines the conditions that affect organizations in a changing and complex world. It was designed to help us factor in the forces of change and uncertainty in our projects and businesses. VUCA stands for volatility, uncertainty, complexity, and ambiguity. I'll explain each one and what that could entail in projects and business settings.
V - Volatility
First up is volatility. Volatility refers to the rate of change and churn in a business or situation. In a volatile project, you would discuss how the next disruption to your operations is always right around the corner, or it feels like things never have time to settle into a normal rhythm.
U - Uncertainty
Next is uncertainty. Uncertainty refers to the lack of predictability or high potential for surprise. In an uncertain environment, it would be difficult to create plans for the future that were not based on a large number of assumptions that could turn out to be incorrect.
C - Complexity
Then there's complexity. Complexity refers to the high number of interrelated forces, issues, organizations, and factors that would influence the project. For example, if one product being worked on relied on diverse and global suppliers, that would add to the complexity of the project.
A - Ambiguity
And finally, we have ambiguity. Ambiguity refers to the possibility of misunderstanding the conditions and root causes of events or circumstances. A project that suffered from ambiguity would have difficulty pinpointing the causes of project delays, making it difficult to design mitigation plans to reduce the risks.
Let's recap. VUCA stands for volatility, uncertainty, complexity, and ambiguity. It's a concept that was developed to deal with these forces in a changing and uncertain world. Businesses can apply the concept of VUCA as a tool for determining how best to approach projects.
Having an understanding of these concepts will help with decision making in all kinds of projects. Adopting an Agile approach increases your chances of success despite this uncertainty. And these concepts apply to the business world at large, not just projects.
Projects and Industries that Benefit from an Agile Approach
When we get started on a new project, it's helpful to examine the environment and conditions in which the project exists before we decide the best approach to use. If your project environment has high levels of volatility, uncertainty, complexity, and ambiguity, then it's a good sign that you should consider an Agile approach. While an Agile approach is not a perfect solution that will get rid of VUCA, it will lead to better outcomes by giving you and your team tools and systems to mitigate the risks that VUCA presents. When you consider Agile values and principles, it's clear that Agile is a proven and well-documented solution to the challenges VUCA presents to your project.
For example, The Office Green market research team noticed a major shift to more workers setting up and working from a home office. They wanted to react fast to a potentially huge market opportunity and not lose revenue if businesses had less need for their previous office service. Instead of offering indoor landscaping designs for businesses, Office Green wants to find a way to capture this new market full of home offices.
This shift to working from home came about suddenly. So Office Green didn't have any project plans to start from. They didn't have time to do a lot of prep work, but they wanted to maximize this opportunity before it was too late. To do this, Office Green assigned you to be the project manager of a scrappy new Agile team. Your goal is to deliver their new service called Virtual Verde.
What environment did Office Green face? Volatility, uncertainty, complexity, and ambiguity. They experienced volatility in the form of a major disruptive change to their business plans, uncertainty through a lack of predictability, which made it difficult to create concrete plans for the future. A high level of complexity due to interrelated factors like suppliers and the economy, and they experienced ambiguity by not being able to determine or control what might cause future changes.
By using an Agile approach to their project, Office Green was able to address high VUCA factors that were affecting their business. Instead of business slowly or quickly eroding due to market forces, Office Green embraced the changing market and remained flexible in how they approached their next project. We'll follow along with Office Green and your work as a project manager of Virtual Verde throughout this course and find out how you do.
Introduction to SCRUM
So what the heck is Scrum? Well, I'll tell you first that it's not an acronym. If any of you have ever played or watched the sport of rugby, you may recognize the term. For those that aren't familiar with rugby, it's similar to American football, a full contact sport played on a field with a similar shaped ball.
Scrum refers to a formation in rugby where all of the players on the team lean forward, lock their heads together, and then work as one unit to try and gain precious yards towards the scoring line. The originators of the Scrum methodology saw their team as a heads-down group, working very closely together to get that ball down the field, just like Scrum in a rugby match. How does the Scrum methodology work as a project management methodology?
If you work in Agile project management, it's highly likely that you'll use Scrum or an approach that is based on Scrum. In the 2019 State of Agile Report, 72% of teams using Agile methods were using Scrum or a hybrid. When you use Scrum for project management, you form a team that will work together to quickly develop and test a deliverable. The work is completed in short cycles and the team meets daily to discuss current tasks and clear up anything that's blocking their progress. First, let's review some terms and concepts specific to Scrum.
The backlog is the central artifact in Scrum, where all possible ideas, deliverables, features, or tasks are captured for the team to work on. It's prioritized and proactively managed by the team continuously throughout the life of the project.
The sprint is the name of the time-boxed period in Scrum where work is done. The sprint can be between one and four weeks long, but most sprints are around two weeks. This is often called the iteration.
And then there's a practice called the daily Scrum, also called the standup. This is where the team meets for 15 minutes or less every day of the sprint to inspect their progress toward their goal.
Next are the roles, the first of which is the Scrum master. This role is responsible for ensuring that the team lives Agile values and principles, follows the processes and practices that the team agreed to, sharing information to the larger project team, and they also help the team focus on doing their best work. The other notable role in Scrum is the product owner, who is responsible for maximizing the value of the product and the work of the team. The product owner owns the inventory of work and has the final say on how to prioritize the work. And the development team is responsible for how a team will deliver that product.
Scrum is popular for many reasons. First, it has clear roles and responsibilities for the folks on the team, while continuously emphasizing the power of the team as a whole. Scrum has very regular and predictable meeting and delivery schedule with predefined agendas and outcomes for the meetings, making it easy to teach new team members. It supports and reinforces the Agile values and principles, while adding some structure and foundations that help new Agile teams get started and more experienced teams get better. And it's all free and open for all to use. Since it's the most commonly used Agile delivery framework, there's also a huge amount of guidance and support online as well as Scrum-specific training and certifications.
Scrum lends itself best to the following types of projects and teams. Ideally, a Scrum team should be cross functional with around three to nine team members. Some call this a pizza-size team because it has the same amount of people who could share a large pizza. If the team is too small, you might not have the diversity of skills to get work done. If the team is too large, it gets hard to distribute information. Lastly, Scrum works best for projects where the team and management are open-minded, adaptable, and value continuously learning how to be a better team. Trying to force a team to do Scrum will almost always fail.
Other Popular Agile Methodologies
There are many popular Agile methodologies that are still around from the '90s when Agile was invented. These methodologies share Agile values and principles, but have very specific practices and applications. In this video, I'll touch on a few of the most popular ones besides Scrum, which we covered in the last video.
Kanban
First, one of my personal favorites is Kanban. This is a methodology that can be applied in a very simple way, or it can be used to drive the entire project. The Kanban name comes from two Japanese words: kan, meaning sign; and ban, meaning board. You may have already used a Kanban board because it's the most famous feature adopted by the majority of Agile enthusiasts. The reason Kanban is so popular is that it provides transparent visual feedback to everyone who might be interested about the status of work in progress. Kanban boards or charts display the progress of a project as to do, in progress, and done. Also, just so you know, there are software tools that create digital Kanban boards for you.
The Kanban method ensures that the project team only accepts a sustainable amount of in progress work. This means the amount of in progress tasks are limited to what the team can actually handle during a certain amount of time. This is called the work-in-progress limit or WIP limit. The WIP limit is decided on by the team. This is a reflection of Agile, in that teams are both self-organizing and empowered, and they're operating at a sustainable pace. The team members add new tasks to be completed only after they finish their previous task and are below the WIP limit. This approach means that once a task has started to be worked on, it becomes a priority for the whole team to get it to done. By focusing on less work, the work gets done faster. This goal of trying to maximize efficiency is called flow, and is a core principle of Kanban.
Extreme Programming or XP
Another Agile methodology is extreme programming or XP. It was named that because it took traditional software development activities to an extreme level, but I also believe it's because it emerged at the same time as extreme sports like snowboarding. XP is another one of my personal favorites. It was the first Agile methodology I was introduced to back in my days, working on some of the original cell phones at Qualcomm, the company behind the radio technology we all use in our phones today. Since XP came out of the software industry, it refers to specific software terms and activities like coding and programming, but the XP method can be used in lots of non-software environments as well.
The XP methodology aims to improve product quality and the ability to respond to changing customer needs. It does this by taking best practices for the development process to extreme levels. For example, one best practice is the idea of test first development. This means testing out parts of the product before building them in full. Often, only the larger features get tested, which is still good, but means some details might get missed. XP takes this practice to the extreme, by finding ways to test more and smaller features of the product to get even more feedback.
The Four Basic Activities of XP
There are four basic activities that are performed during the product development process that the XP method tries to enhance.
1) Designing
In software development, this is where you write a design document describing the parts of the code or instructions for the product and how it will function. In non-software environments, this would be describing the various pieces and parts for whatever it is you're trying to deliver. For example, if you're delivering an ad campaign, maybe the main pieces are the artwork, the copy, and the ad by plan. XP wants to ensure that all of the pieces of the product will fit together properly, so it stresses simplicity. Start with a simple design to meet the most basic and important requirements. Simple designs also take less time to complete. Once the basic model is designed and has been tested, then you can think about adding on other features.
2) Coding
Code is the language that's used to write software programs. It's the instructions that tell the computer what to do. In software development, writing clear code is crucial, just like clear writing is crucial in any situation where you want to be understood. XP demands clear and concise code so that others can easily read and understand the program. This makes it easier to troubleshoot problems and come up with solutions. In non-software environments, code would be similar to writing clear and concise processes or instructions for how to build or use your product.
3) Testing
Like I described earlier, means checking the product for flaws so they don't end up in the final product. In XP, more is better. So if a little bit of testing can eliminate a few flaws, lots of testing will eliminate even more. The goal is to test for and eliminate any flaws in a feature before building it and continuing on. Testing also means checking to make sure the product features meet the customer's requirements, which leads us to listening, which is about listening to the customer and ensuring that the requirements are integrated into the product. This relates to Agile in the way that it values customer collaboration, frequent communication, and regular feedback. XP features some other innovative practices that are used across many Agile teams, regardless of the specific methodology being used. First, there's pair programming, which is when two team members work together at the same time on one task. Usually this is done in the same physical location, but with the use of digital collaboration tools, this can happen remotely too.
4) Continuous Iteration and Refactoring
This is the practice of merging product changes into a shared version several times a day in order to get quick feedback on the quality of the code or product. Then there's avoid big design up front. This relates to designing and means the design should be just enough to get started and should be continuously improved as the product evolves. And finally, there's right tests, not requirements. This means that instead of writing a product requirements document, and then later writing a test plan, your test plan can serve two purposes by A, telling the team what to build, and B, comparing what they built to what was supposed to be built.
Lean
Lean methodology consists of five principles that serve as a recipe for improving project outcomes. They are: define value, map value stream, create flow, establish pull, and pursue perfection. Let's break these down.
Define:
Define value means identifying and focusing on what the customer wants and including the customer in the process. A product's value is the sum of all the things the customer wants.
Map:
Map value stream means mapping out the process or stream, including all the steps involved in producing value for the customer. It also means challenging any steps that can be considered wasteful or unnecessary.
Create Flow:
Create flow means ensuring the product flows through the value stream efficiently, continuing to eliminate waste throughout the cycle. Work to remove interruptions, delays, and barriers to the work stream.
Establish Pull:
Think of asking someone to pull something off the shelf. You want to make sure the customer is pulling on the product or asking for it throughout the value stream. They might pull or ask for features and incremental deliveries. The idea is to make your process as smooth as possible so that the customer can pull on the product at any time, and you'll be able to present what you've been working on or add a feature request.
Pursue Perfection:
This means pushing your team to continuously improve the first four process steps.
So how does this relate to Agile? Well, Agile emerged after Lean, and the inventors of Agile were inspired to apply Lean manufacturing principles to software development. Like Agile, Lean is a set of principles and a value system. Many of the differences are really just in the wording.