As we begin discussing the practical application of agile, it’s important to understand where agile came from. Contrary to popular belief, agile practices did not appear in 2001 with the Agile Manifesto (more on this later). Contemporary practice of agile traces its roots to Scrum, which in turn looks back to quality processes in manufacturing and evolving methods in product development prior to alignment and adaptation for software development and other projects.
Agile can be traced back to manufacturing and quality practices pioneered by Ohno at Toyota and the work of quality gurus such as Deming, Shewhart, and Juran.
I like to ask students in my agile project management classes if they own or have ever owned a Toyota automobile (in my case, I’ve owned three). I ask this because one can trace agile to Taiichi Ohno’s Toyota Manufacturing System (TPS) as well as to the work of quality experts such as W. Edwards Deming and Joseph Juran. Following World War II, Japan worked to rebuild its heavy industry and sought the advice of experts such as Deming and Juran, whose work was not gaining much traction in the United States.
Plan-do-check-act cycle
When at any point it becomes necessary for a practical reminder of what agile is about, remember PDCA. Agile is much more than this, but PDCA helps focus teams on how to execute.
Roots of Agile Frameworks: Scrum
When thinking about agile from a practical perspective, it is critical to understand that many well-known agile practices are derived from Scrum. Jeff Sutherland is widely known in agile circles as the co-creator of Scrum and its most passionate advocate and practitioner. Sutherland credits the work of Hirotaka Takeuchi and Ikujiro Nonaka and their 1986 article in the Harvard Business Review as foundational to the creation and evolution of Scrum (Sutherland, 2011). In their seminal 1986 article, Takeuchi and Nonaka illustrate the distinction and advantages of a rugby-like approach to new product development versus the traditional relay race approach. The article introduces the word “scrum” and makes a direct comparison to the rugby scrum to describe the approach to new product development that evolved to become one of the roots of the Scrum framework and ultimately most agile frameworks (Takeuchi and Nonaka, 1986).
- 1.
Built-in instability
- 2.
Self-organizing project teams
- 3.
Overlapping development phases
- 4.
“Multilearning”
- 5.
Subtle control
- 6.
Organizational transfer of learning
Takeuchi and Nonaka state that “These characteristics are like pieces of a jigsaw puzzle. Each element, by itself, does not bring about speed and flexibility. But taken as a whole, the characteristics can produce a powerful new set of dynamics that will make a difference” (Takeuchi and Nonaka, 1986).
Jeff Sutherland defined the initial Scrum rules, the meetings that are inherent to the Scrum methodology, and the artifacts that are used within Scrum. Working with Ken Schwaber, Sutherland presented this methodology at a software development conference in 1995. The paper described and introduced the Scrum method. These writings formalized and documented an approach to software development that could be adapted and improved upon going forward.
Formation and Emergence
Other approaches to software development continued to develop throughout the mid-1990s. Kent Beck, another influential agile figure, came up with the concept of Extreme Programming, often abbreviated as XP, in 1996. Beck focused on frequent releases of software and short development cycles. One key element is the use of paired programming, where software developers work closely together with one at the keyboard and another looking over the shoulder or sitting side by side – literally two sets of eyes looking at the code and collaborating in real time, as the best way to actually write and implement a feature.
Kent Beck was also instrumental in another approach to agile development that is known as Test-Driven Development (TDD) . There is a focus on short development cycles, but one of the key points here is that a software developer would start with the test itself. They would write a failing test for a particular feature, and then they would write code until that code would pass the test.
Closely related to this concept is Feature-Driven Development (FDD), which was pioneered by Jeff De Luca in 1997. The project would be driven from a list of requirements and tasks from a feature list. The project team would build an overall model or design, and then the project would be planned feature by feature. The team would design each feature, and each feature would be built out and tested – so the process of working through each feature design, build, and test is essentially what would drive the project.
Kanban and Lean
Kanban emerged in the 1940s from the work of Toyota and their manufacturing system. It is said that Toyota observed how grocery stores replenish their shelves, basing replenishment on the stock on the shelves vs. the supply that their vendors wanted them to take. We see this manifest as management of work in progress.
In Kanban, we only pull in more work when there is “space on the shelf” so to speak. This is often what is called the “just-in-time” approach to manufacturing for inventory or to providing work in progress. “Kanban” itself refers specifically to a visual signal or card. At Toyota, this card appeared in a basket of parts to indicate that it is time to send the card back up stream so that more parts can be released into the manufacturing workflow.
Kanban was adopted in many manufacturing and service work settings, and in the early 2000s, some began to adopt Kanban practices for the management of knowledge work (Terry, 2018).
As with Kanban, Lean has roots that trace back to automobile manufacturing. Some look all the way back to Henry Ford’s production line. There is solid evidence that Toyota and the Toyota Production System perfected lean principles to make their manufacturing processes more efficient by ensuring that the process stops when there is a defect. Human observation is critical to ensure that defects are detected and that production stops until the reason for the defect is addressed and fixed (Skhmot, 2017).
One source for the emergence of lean principles in manufacturing is a 1991 book by James Womack, Daniel Jones, and Daniel Roos in which the authors studied various manufacturing systems and compared them to the methods in place at Toyota.
Lean principles trace value from the customer perspective and seek to illuminate any steps in production that do not create value. Lean seeks to streamline processes so that product and value flows toward the customer and allows customers to pull their value from the next activity. Constant attention to the value stream ensures that any waste is removed, and that flow and pull are enhanced with the intention of creating a perfect value stream (Skhmot, 2017).
2001 – The Manifesto
The Agile Manifesto (agilemanifesto.org, 2001)
The most critical thing with the Agile Manifesto as it applies to practical agile is to embrace and live these key values. As Dr. Jeff Sutherland notes, “Agile is not a process, it is a set of values” (Sutherland, 2019). In addition to PDCA, keeping the Agile Manifesto values at the forefront of practice is key to practical agile delivery. In addition to the Manifesto itself, the collaborators developed twelve principles behind the Agile Manifesto which provide the foundations for the agile frameworks and practices you may already be familiar with and which are discussed in this book.
- 1.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- 2.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- 3.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- 4.
Business people and developers must work together daily throughout the project.
- 5.
Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
- 6.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- 7.
Working software is the primary measure of progress.
- 8.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- 9.
Continuous attention to technical excellence and good design enhances agility.
- 10.
Simplicity – the art of maximizing the amount of work not done – is essential.
- 11.
The best architectures, requirements, and designs emerge from self-organizing teams.
- 12.
At regular intervals, the team reflects on how to become more effective and then tunes and adjusts its behavior accordingly (agilemanifesto.org, n.d.).
Following 2001 and the emergence of the Agile Manifesto, agile methods and practices experienced accelerating adoption within software development and also in other domains and verticals interested in adopting agile project management processes and techniques and methodologies for their use.
2010–2020
Prior to 2010, the Project Management Institute (PMI) and its core certification of Project Management Professional (PMP) were perceived such that many practitioners of agile said “we don’t want to be like them.” In turn, PMI and many practitioners of PMI’s project management body of knowledge (PMBOK) believed that agile methods lacked rigor and discipline and were not robust or mature enough for critical projects. Yet in 2010, PMI recognized agile as a viable method of managing projects and announced its own certification in agile, the PMI Certified Agile Practitioner (PMI-ACP).
PMI’s embrace of agile was the essence of practicality. In addition to recognizing that aspects of agile had been around for decades (rolling wave project planning being one example), PMI also recognized that agile was gaining significant traction and that it would be much better (and profitable) to embrace agile. Within PMI’s practitioner ranks, people like Jesse Fewell were advocating a pragmatic view of agile as a complementary approach to managing projects that had its appropriate place in the spectrum and toolkit of organizations and project managers.
The years 2010–2020 also saw the proliferation of training, additional flavors of agile certifications, the emergence and acquisition of entire methodologies (e.g., Disciplined Agile, which was acquired in 2019 by PMI), and continued consternation on the part of agile purists who (with some reason) decry the dilution of the core values of agile. As a practitioner, writer, and teacher, I’ve observed this expansion and dilution and see it as all the more reason to focus on hybrid and practical approaches and outcomes that leverage the basic tenets of agile.
The 2010s saw recognition from adopters that agile could not automatically solve systemic problems. The 2010s saw the emergence of mixing and adapting to create the hybrid approaches which are the focus of this book: A departure from orthodoxy and purist approaches in agile project management, replaced by a trend of taking the elements that work best while adapting or discarding other elements that may not work for particular projects and organizations.
This mixing and adapting of hybrid approaches, taking elements that work best while adapting or discarding other elements that may not work for particular projects and organizations, is our focus: The recognition that while agile frameworks like Scrum provide their best and most impactful results when deeply understood and implemented to their purest and fullest extent, there are unquestionably benefits from understanding and applying elements of agile frameworks that work for practitioners and their organizations while recognizing that not all organizations can (or should) worry about doing a “perfect” implementation of an agile framework.
Summary
In Chapter 4, we learned a bit about the roots and history of agile – where it came from, how it evolved where it was used, and how it emerged to become the set of frameworks that we are becoming familiar with and that have been widely adopted. This is important because this helps you understand key elements that should always be present in your application of the frameworks, tools, and techniques, regardless of whether you are using a hybrid or a purist approach.
Chapter 5 will discuss more agile values such as flexibility and adaptability before diving into the agile life cycle and practices.