Foundations of Agile
Agility is more attitude than process, more environment than methodology.
—Jim Highsmith
During one of my agile seminars, I ask people “What is Agile?” I bring up a list that includes, “Agile is a methodology,” “Agile is a process,” “Agile is a set of practices,” and “Agile is a set of tools.” I see a lot of heads nodding in the affirmative, believing that some or all of these are what Agile is. Then I cross them all out and bring up a single line that says, “Agile is a set of values and principles.” Some have an aha! moment.
Figure 6-1. Though there is value in the items on the right, we value the items on the left more
I ask you to take a moment to understand this and learn more about the overarching values and principles of Agile.
Agile Is a Set of Values and Principles . . . Seriously!
The foundational building blocks of Agile are its values and principles. This is probably the most important point that is often misunderstood and needs to be recognized. Agile is not a process, methodology, practice, or tool but a set of values and principles. The implication is that Agile is more about a state of being: the Agile mindset. Processes and methodology can help you do Agile in the mechanical sense, but Agile is a culture shift that requires a willingness to adapt to the Agile mindset. Agile values and principles are components of the Agile mindset.
Agile Pit Stop Agile is not a process, methodology, practice, or tool but rather a set of values and principles. The implication is that Agile is essentially a state of being: the Agile mindset.
It is important to not just read the Agile values and principles found in the Agile Manifesto, but embrace them. Why do you want to embrace these values and principles? Maybe it is because you believe in the importance of customer and employee engagement and that providing value to the customer is important to the success of your business. Maybe you realize that you need to be more adaptive because uncertainty exists and customer needs change. Reading Chapter 3 provides you a better understanding, but ultimately you own the answer to this question.
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: 1
Manifesto for Agile Software Development
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 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.
Agile Pit Stop Because it is human nature to evolve over time, we should assume that the needs of customers will evolve.
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.
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: 2
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.
Introduction to Agile Processes and Methodologies
Now that we have discussed the Agile Manifesto and reflected on the values and principles within it, let us dive into the more commonly known agile processes and methods. Let us remind ourselves that there is nothing called the “agile process” or “agile methodology.” Remember, Agile is a set of values and principles. The various agile processes and methods introduce a framework for approaching software development to ensure the customers gain more assurance that they get a solution that solves their business need.
Agile Pit Stop There is nothing called the “agile methodology.” Remember, Agile is a set of values and principles.
With that in mind, there have been several frameworks, processes, methodologies, and practices established in an attempt to support and promote the agile values and principles. This section will focus on Scrum, XP, DSDM, and Kanban because they may be more commonly encountered. It will also discuss Lean and Value, Flow, Quality (VFQ). While they are not agile processes or methods, they can help us align with the agile values and principles. The purpose here is to understand them. Even though I am highlighting these, it does not imply that they are necessarily better than any of the others not discussed here. There is no one correct process or methodology to use. The best one is the one that suits your working environment and your type of work. Let us examine these in more detail.
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.
Agile Pit Stop Scrum is a sports term borrowed from rugby. It is not an acronym, so do not capitalize the letters.
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.
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: 3
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.
Agile Pit Stop The primary roles in XP are the Customer and Developer. Other, less formal roles are the Tracker and Coach.
XP provides practices and rules that revolve around planning, designing, coding, and testing. Some include: 4
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. 5 DSDM follows eight principles to guide the mindset for adoption:
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. 6 They are:
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.
Agile Pit Stop I have found that Kanban is effective when the work is more interruption-prone and when priorities can change from day to day.
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. 7 They established seven Lean development principles:
Agile Pit Stop Often Lean is discussed in terms of eliminating waste. However, the real focus of Lean is to identify value to the customer: deliver what they want, when they want it, and with the minimum amount of effort.
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. 8 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.
I started this chapter by underscoring that Agile is not a set of processes, methodologies, practice, and tools. Rather, Agile is a set of values and principles. I took you on a tour through some of the many Agile-based processes, methods, and frameworks: Scrum, XP, DSDM, Kanban, Lean, and VFQ. However interesting and useful you may find any of these frameworks, never forget the key proposition that Agile is that set of values and principles that drives an agile approach regardless of the framework you select.
Agile is essentially a state of mind—being Agile—that is bound up with a change to your culture. The agile state of mind understands the importance of customer engagement to value and of employee engagement to self-organization and ownership. Ultimately, it doesn’t matter what processes, methodologies, and practices you apply. What is important is that you shape your implementation around the agile values and principles with the goal of gaining an Agile mindset and achieving business results.
1 “Manifesto for Agile Software Development” at agilemanifesto.org
2 “Principles behind the Agile Manifesto” agilemanifesto.org/principles.html
3 Ken Schwaber and Jeff Sutherland. The Scrum Guide (2013). www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf#zoom=100
4 Don Wells. Rules of Extreme Programming (1999). www.extremeprogramming.org/rules.html
6 David J. Anderson. Kanban. Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.
7 Mary Poppendieck and Tom Poppendieck. Lean Software Development: An Agile Toolkit. Addison-Wesley Professional, 2003.