Manifesto of Agile Software Development

It is important to read and internalize the “Manifesto for Agile Software Development” (Agile Manifesto for short) if you are serious about understanding an agile state of mind and truly want to “be Agile.” It is critical that personnel at all levels of the company understand and believe in the statements that represent the values and principles. Although many are aware of it or have seen it at one time or another, few remind themselves of what it implies to be Agile on a regular basis, particularly when they are buried in the mechanics of implementation.

Here is the Agile Manifesto—73 words signed by seventeen authors in 2001: ¹

Manifesto for Agile Software Development

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 last phrase helps us understand the authors’ intentions. They are not saying there is no value in the items on the right, but instead that they have less value than the items on the left. Those who disregard the items on the right are either Cowboys or Bandwagon Jumpers who do not know better, or beginners who have not gained an appreciation of striking the right balance.

A perspective that helped me understand the nexus of these values better was realizing that the items on the left can help drive the need and level of the items on the right. Here is a deeper look at the four polar pairs of agile values declared in the Agile Manifesto.

• “Individuals and interactions over processes and tools.” Communication is the enabler for individuals to interact with their team members. The inspect-and-adapt model is an enabler for communication to occur throughout a project. The benefit is the continuous feedback. This helps us understand the process in which we work and how we may adapt it over time. This also ensures that a predefined process or tool set does not dictate how we interact.
• “Working software over comprehensive documentation.” When you ask a customer what they value most—working software or comprehensive documentation—how do you think they will answer?  Working software is the value that the company is delivering and the customer is buying. This helps us understand the business perspective of the product we are building. Working software also implies a certain level of quality, and it is only complete when it meets that level of quality. This helps us understand the engineering perspective of the product.
• “Customer collaboration over contract negotiation.” The team and stakeholders use collaboration as a method for establishing customer needs and allowing them to evolve over time through continued collaboration. While there will often be a need to execute a contract, the contract should not drive to a static list of exactly what will be built but allow collaboration to evolve the list. Remember, it is really in the customers’ best interest to get a product that best meets their evolving needs instead of a product that is based on a list of requirements from the past—sometimes the distant past. Because it is human nature to evolve over time, we should assume that the needs of customers will evolve. A static list can get outdated fairly quickly. This is what makes customer collaboration so important.
• “Responding to change over following a plan.” To build working software that is considered valuable to the customer, we must be willing to respond to the changes in customer needs and market conditions. If you stick with the plan, make the schedule, and come within budget but miss delivering what the customer wants, are you successful? Though it is hard to have all happy customers, the inspect-and-adapt model seeks customer feedback from the incremental reviews of the working software. This allows us to incorporate customer feedback and more closely align with and deliver what the customer finds valuable.

Principles behind the Agile Manifesto

Supporting the Agile Manifesto are the “Twelve Principles of Agile Software.” The Twelve Principles provide drivers for better understanding the values and are as follow: ²

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development.

Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity—the art of maximizing the amount of work not done—is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Take a moment now to reflect on these Principles. What are some of the attributes of the Principles that stand out? As you reflect on these, can you see if your product team or organization aligns with any of these Principles?

In Chapter 9, I dissect each of the Principles to better understand what it means to align it with the mindset that it represents. In Chapter 13, I provide an adaptable assessment mechanism that can be used to determine where your team or organization is in relation to being aligned with the Agile Principles and so having an agile state of mind. Remember, it is not enough to say I am mechanically “doing” Agile practices. Instead, to gain the business benefits of Agile, you need to “be Agile” and live these principles.

Scrum

Scrum is an iterative and incremental framework used to build software. It follows an inspect-and-adapt process to support product development and consists of Scrum roles, events, artifacts, and rules. The roles inform and surround the Scrum Team; the events are planned team activities that are time-boxed within the concept of a sprint, typically 1 to 4 weeks; and the artifacts are the items used in Scrum that represent work in some manner and illustrate progress. Rules are applied to the roles, events, and artifacts.

Scrum is not an acronym, so it should not be in all capitals. The word derives from a team formation in rugby in which the team moves forward as an interlocking unit in a manner that each player has a specialty function yet all players are contributing equally and simultaneously to the team’s forward progress toward a common goal. Scrum provides agile project and product management events or practices. Scrum is often used in tandem with XP, which provides many of the agile engineering practices.

An important aspect of Scrum is that the customers can change their mind on their needs as necessary to ensure they are getting the product they want and need at the end. This approach recognizes that customer needs and market conditions change and does not try to stifle—and indeed welcomes—the change activity. Changes can be added to the Product Backlog at any time and reprioritized according to the customer needs. During the next Sprint Planning session, any new changes can be considered for the new sprint. It is important to note that once a sprint is started, there should be no attempt by the customer or team to change the requirements. Instead, allow the team to focus on the prioritized requirements from the planning session. Although there are exceptions to this rule, it allows the team to focus in short bursts and produce working software that the customer can respond to.

The primary overarching role in Scrum is the Scrum Team. The Scrum Team is meant to be self-organizing so that members feel empowered to make the decisions and feel ownership of their work. The Scrum Team members are those committed to building the product and include the subroles of Scrum Master, Product Owner, and Development Team.

• The Scrum Master acts as a motivator for Scrum. This role acts as coach to the team to ensure that the Scrum roles, events, artifacts, and rules are understood and implemented effectively. He or she is the primary facilitator of the team.
• The Product Owner (PO) represents the customers, is the customer liaison, and is primarily responsible for understanding what is considered valuable from the customers’ perspective. The PO is the primary owner of the product backlog, where value is expressed.
• The Development Team is a cross-functional group of engineers who build the functionality. They are made up of personnel with cross-functional skills so that they have the capabilities to build the product without having to rely on others outside of the team.

Scrum events are meant to provide an imbricated pattern for the work. Each event relies on the other and provides input to the next event. When one or more of the events are missing, this reduces the effectiveness and ability to inspect and adapt. The Scrum events include: ³

• Sprint Planning is held in the beginning of each sprint and focuses on understanding the user stories that will be worked on in the sprint. The goal is for all Scrum Team members to plan this work. The list of work that can fit into a sprint is known as the sprint backlog.
• The Daily Scrum is a daily event time-boxed to no more than 15 minutes in which the Development Team communicates progress among themselves and introduces any encountered roadblocks.
• The Sprint Review is held at the end of a sprint. The Development Team presents the working software to the PO and customers to gain valuable feedback. This is part of the inspect-and-adapt process that allows the team to adapt to the needs of the customer.
• The Sprint Retrospective is the last event at the end of a sprint used to identify what went well in the sprint and what can be improved. It is an opportunity for the Scrum Team to reflect on the past sprint’s activities, including team dynamics, processes, tools, and culture.

Extreme Programming (XP)

Extreme Programming—commonly known by its acronym, XP—is an agile process that revolves around a set of practices that emphasize teamwork and customer satisfaction. From the customer perspective, XP believes that requirement changes are a natural part of the software development process and introduces a rigorous set of engineering practices to support these changes. XP is often used in tandem with Scrum, which provides many of the Agile-minded project and product management practices.

In XP, the team is typically twelve or fewer members and meant to be committed, empowered, and self-organized so they can make the best decisions to move forward because they are closest to the challenges and work to be accomplished. The two primary roles in XP are the Customer and the Developer.

The Customer is the primary driver of the project and represents the end user. The Customer provides business knowledge and should set goals for the project. The Customer is the contributor of the requirements and may change them as they understand their needs more fully.

The Developer represents the cross-functional engineering team that is needed to design, code, build, and test the product and focus on the daily work of understanding the stories and converting them into functional working software. The team focuses on building the product from day one while continuously engaging the customer to meet their needs.

The other, less formal roles include the Tracker who focuses on the schedule, throughput of work, and risks of the project, and the Coach, who will help the team understand and execute XP practices.

XP provides practices and rules that revolve around planning, designing, coding, and testing. Some include: ⁴

• User Stories are scenarios written by the customer for things they need within the product.
• Release Planning is applied at the beginning of a project and used to lay out the release plan and schedule.
• Iteration Planning is the process by which the customer determines the user stories for an iteration that fit the estimate of effort as established by the team velocity.
• Sustainable Pace determines the amount of designing, coding, testing, integration, and product-ready work a team can do within an iteration.
• Project Velocity focuses on measuring the progress on an XP project by adding up the estimates of the user stories that are finished during an iteration.
• Stand Up is a short daily meeting in which members of the team stand up and communicate their progress.
• Retrospective is applied at the end of an iteration and focuses on fixing XP or the way it is being applied when things are not running well.
• Simplicity is a design practice that has the team focus on the simplest thing that will work first.
• Refactoring focuses the programmers on continuously streamlining the code by removing unused functionality, reducing redundancy, correcting poorly written code, and improving on existing design.
• Spike Solutions are a special focus meant to solve a challenging technical, architectural, or design problem.
• Pair Programming is a coding practice in which two programmers work together at the same computer while programming a user story or task.
• Customer Availability asks the customer to always be available to and become part of the development team.
• Collective Ownership refers to everyone owning the code and tests.
• Continuous Integration advocates that programmers merge their code into the code baseline whenever they have a clean build that has passed the unit tests.
• Unit Test focuses on testing the code changes at the development unit level prior to merging it into the project branch. Otherwise the code change cannot be considered complete.
• Acceptance Testing focuses on establishing specific acceptance tests for each user story.

Dynamic Systems Development Method

The Dynamic Systems Development Method (DSDM) is an iterative and incremental agile project management and delivery framework. DSDM is based on Rapid Application Development (RAD) and focuses on continuous user involvement. Prototyping is a key component of DSDM and is found throughout the activities within the project life cycle. DSDM is periodically updated with guidance from the DSDM Consortium. ⁵ DSDM follows eight principles to guide the mindset for adoption:

• Focus on the business need
• Deliver on time
• Collaborate
• Never compromise quality
• Build incrementally from firm foundations
• Develop iteratively
• Communicate continuously and clearly
• Demonstrate control

Unlike other agile methods that focus on just the project lifecycle, DSDM utilizes three phases focusing on the pre-project, project, and post-project. The pre-project phase focuses on commitment and budget. The project phase focuses on the activities within a project life cycle. The post-project phase focuses on maintenance, bug fixes, and enhancements. In DSDM, you may iterate through an activity several times before moving to the next.

The project life cycle phase starts with “study” activities focusing on a feasibility study to ensure that DSDM will work for the project and is accepted by management and then a business study to ensure the project is worth doing. This is a bit unusual since most agile methods do not specifically have a step to verify if the method will be suitable and instead assume it will just work. However, ensuring that the methodology is aligned with the work and having management support are critical to the success of the project.

This is one of several DSDM’s success factors. DSDM specifically calls out the need to ensure management agrees to use the method and looks for a commitment moving forward. The other success factors are having customer involvement, an empowered project team, and a strong relationship between the customer and vendor. DSDM views the full picture of software development as areas to focus on because it is understood that any one piece that goes awry can lead to problems. It should be noted that DSDM may be combined with other methods and techniques like PRINCE2, XP, and Scrum.

Kanban

Kanban is a continuous flow method for managing the development and delivery of products. Kanban is a Japanese term that translates roughly to “signboard” or “story card.” This is because Kanban is primarily focused on making the workflow visible and highlighting the constraints to that flow. The origins of Kanban can be traced back to Taiichi Onho and the Toyota Production System. In its more modern form, David Anderson identified five core principles that support a successful implementation of Kanban. ⁶ They are:

• Visualize your work so that you can see the work and in context with other work.
• Limit the work in progress (WIP) using a pull system so there isn’t an overflow of work at any step along the way and so pace is understood.
• Manage the flow of work, applying measures so the team knows how much work to commit.
• Make the process policies explicit so that improvements can be made to acknowledged baselines.
• Improve collaboratively so there is the opportunity to improve the working process and workflow.

Whereas in Scrum you would use a sprint to develop a batch of work, in Kanban there is a continuous pull of single pieces of work.

One of the advantages of implementing Kanban over Scrum is that Kanban can be implemented successfully in traditional and command-and-control cultures. While Scrum provides a set of practices or events, it does align with the Agile Principles, which lead to an Agile mindset, implying a change to the traditional culture. With that being said, Kanban will not get you to the Agile mindset if you are only interested in the Kanban principles and practices so it may not be as agile as many believe. However, if you approach Kanban under the auspices of the Agile Manifesto, then you may achieve the Agile mindset.

Lean Software Development

Lean is an approach that focuses on building value by defining what is needed, building it with the minimum amount of effort, and delivering it when it is needed. The origins of Lean can be traced back to Taiichi Onho and the Toyota Production System. I include Lean not because it is directly an agile process but because it focuses on customer value, which is aligned with the agile values and principles.

Often when Lean is discussed, there tends to be a strong focus on eliminating waste—and rightly so. However the real focus of Lean is the identification of value to the customer: delivering what they want, when they want it, and with the minimum amount of effort. To be sure, what is considered valuable also becomes a driver for what is considered wasteful.

Mary and Tom Poppendieck advanced Lean thinking into software development. Their “Lean software development” approach presents the traditional Lean principles in terms that relate to software development. ⁷ They established seven Lean development principles:

• Eliminate waste: Continuously focus on eliminating waste. This can be in the form of unneeded customer features, unnecessary process steps, and more.
• Learn constantly: Use iterations, use continuous feedback, and speak to the people with knowledge, all to support continuous learning.
• Deliver fast: Make software available via a steady flow of customer value in smaller batches on a just-in-time basis.
• Engage everyone:  Allow the team to own their decisions, apply their own brainpower, respect each other, and have opportunities for excellence.
• Build quality in: Apply the nonfunctional qualities into each feature as well as a quality level of “done” criteria to ensure the working software has high quality.
• Optimize the whole: Focus on the entire value stream, not the short-term profits. Ensure the details are managed at the right level and you provide a working solution, not just software.
• Keep getting better: Always look for opportunities to improve. Failures are learning opportunities. The key is to develop your people.

It will be important to adapt these principles into your working process.

Value, Flow, Quality

VFQ is an educational framework that helps you achieve results in ensuring you are delivering customer value, establishing optimal flow, and achieving high-quality working solutions. VFQ applies a work-based learning program based on Agile and Lean and focuses on the importance of applying the attributes of value, flow, and quality when it comes to building product. ⁸ The intent is for the practitioner to use these attributes to help an organization identify the best approach for them to achieve the business results they are looking for. VFQ does this through the belief of applying skills in practice. I include VFQ not because it is directly an agile process but because it focuses on customer value, which is aligned with the agile values and principles.

VFQ education applies a number of learning pathways based on roles designed to select the most appropriate core of knowledge required by each role. However, because agile methods rely on cross-functional skills, the best option continues to be to take a team approach and study the course as a whole. The full course covers a wide variety of topics and emphasizes end-to-end organizational flow. The VFQ approach is intended for all levels, from a newly qualified developer to senior executives, and encourages those whose departments who are strongly affected by what occurs in IT, perhaps marketing and operations to participate.