- It’s a mindset or a philosophy.
- It is the values and principles of the Agile Manifesto.
- It is a framework rather than a methodology.
- It is a way to get more features out the door quicker than ever before.
- It is something that the development teams do.
- Agile development is anarchy! (I haven’t heard this one lately).
One of the challenges with agile development is that it defies being meaningful y described in a sentence or two. I’ve tried, but I never liked the results. I’ve also heard people criticize agile development because it can’t be defined succinctly.
These days, my response to this is that if we didn’t already understand non-agile approaches to managing and working, we couldn’t succinctly describe those in a meaningful way, either. Not well enough to understand how to apply what we believe and value as a set of practices that addresses the full spectrum of software development from inception to delivery.
I do have a definition, but I’ll get to that a little later. Let’s tackle the confusion factor first.
How We Get Confused
We can get confused about agile because most organizations begin small, implementing something like Scrum – the most popular agile framework in use today. This is a great step, but without some additional information casual observers run the risk of evaluating agile on the basis of what they are seeing and relating those observations to what they know. For example, it is possible to equate the following:
Product Backlog = Requirements
ScrumMaster = Project Manager
Sprints = Mini-Projects
These are close, but there are some important differences that differentiate the items on the left from those on the right.
Another point of confusion is around the issue of whether agile is a mindset or philosophy or something more specific like practices or a framework or methodology. It may sound backwards, but agile frameworks were like Scrum and XP were developed before the term agile was coined.
The term agile development came about as a result of seventeen thought leaders gathering in February of 2001 to talk about their particular approaches to software development. They sought to find common ground that brought balance to software development, finding an alternative to “documentation-driven, heavyweight software development processes.”
What we now call “heavyweight” software development processes grew out of the need to address the problems with ad-hoc software development, with the goal being of formalizing software development in ways to that led to producing quality software. However, these thought leaders determined that formal approaches had not only became increasingly bloated over time, they did little to actually solve the problem of reliably delivering quality software. But they did do plenty to increase costs.
As you may surmise, agile development is an umbrella term that captures the essence of what these thought leaders had already implemented in the creation of other methodologies introduced by these thought leaders, which at the time included Scrum, XP, Crystal, FDD, and DSDM. Scrum, for example, was first used in 1993.
The Depth of Agile
Agile goes even deeper than The Agile Manifesto. Let’s take a look at the depth of agile courtesy of a perspective put forth by Allen Kelly in his book, Changing Software Development: Learning to Become Agile (Kelly, 2008), as depicted in Figure 2-1:
Scrum and other agile frameworks and practices sit on top of a larger foundation that includes the values and principles of The Agile Manifesto. That means that if you are implementing agile development using Scrum, then you should be implementing Scrum with its roles, events, and artifacts along with honoring what is found in The Agile Manifesto (The Manifesto for Agile Development, 2001).
The four values of The Agile Manifesto:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
- 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.
- Eliminate waste
- Amplify learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- See the whole
- Systems thinking
- Personal mastery
- Mental models
- Shared vision
- Team learning
Team learning is different than individual learning; a group of great individual learners does not mean that great team learning will take place. Just like a sports team, a business team must discover how to learn together as team to create great team results.
As we move up one level to the principles of lean development, we see that there is one principle that tells us to Amplify Learning. How do we do that? Delving a little deeper into lean and we find that one way that lean development amplifies learning is through the use of short cycles to increase feedback. This gives us some additional insight on how to enable team learning in a product development context.
Moving up another level to agile, we can readily point to one of the twelve principles of The Agile Manifesto that incorporates everything discussed thus far: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Now we have greater specificity on how to address the challenge of team learning.
And finally, if we are using a framework or methodology like Scrum, we have a prescribed event that enables team learning in support of everything found in the depth of the layers below: The Sprint Retrospective. This is where the team gets together to determine how they can improve in the next Sprint (a short delivery cycle measured in weeks, typically 1-4 weeks in duration).
By using this model, we provide ourselves with some very deep, rich territory to explore what being agile is all about.
Next post: The Breadth of Agile
This post is a draft of content intended for an upcoming ebook: Agile Expectations: What to Expect from Agile Development, and Why. Blog posts will be organized under the “Agile Expectations” content on the left-hand side for easy reference. I welcome your comments and feedback! – Dave Moran
Kelly, A. (2008). Changing Software Development: Learning to be Agile. John Wiley & Sons.
Mary Poppendieck, T. P. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley.
Senge, P. M. (1990, 2006). The Fifth Discipline: The Art & Practice of The Learning Organization. Doubleday.
The Manifesto for Agile Development. (2001). Retrieved from The Agile Manifesto: http://agilemanifesto.org/