What is Agile?

In preparation for my presentation at the upcoming LAST Conference, entitled “Being agile over buying Agile”, I decided to try and capture in a couple of simple diagrams what Agile is (or what it represents). When we strip back all the Agile stuff out there, how can we very simply describe the members of the Agile family?

There are many principles, processes, tools, methods, methodologies and practices that are given the Agile label nowadays, so it is in some ways unsurprising that there is so much confusion and misunderstanding. Well the good news is that the reality is far simpler. The term “Agile” refers specifically to the collection of knowledge captured in the Agile Manifesto. That’s it. Agile can be taken to mean so many things that many are overwhelmed by the sheer quantity of Agile “stuff”. But really it’s very simple.

It’s not just about agility (with a lower-case “a”). Team and business agility is indeed promoted via various facets of Agile (and Scrum, the most popular Agile product development framework) but is only a small part of Agile. However, Agile is represented by only 4 key statements (Agile Manifesto) and 12 principles (also described on the Agile Manifesto website), many of which are really saying the same thing. I posit that this diagram encapsulates Agile in its entirety.

 

For those of you who prefer bullet-points, here is Agile described in such a manner:

• Individuals and interactions over processes and tools
  • Business people and developers must work together daily throughout the project.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software over comprehensive documentation
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Working software is the primary measure of progress.
• Customer collaboration over contract negotiation
  • Simplicity–the art of maximizing the amount of work not done–is essential.
• Responding to change over following a plan
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Self-organisation
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
• Technical excellence
  • Continuous attention to technical excellence and good design enhances agility.
• Continuous improvement
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
• Sustainable pace
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

What about Scrum?

There is similar confusion about what Scrum is and isn’t and its place in the Agile world. Again, Scrum is a simple framework but is difficult to master, usually largely due to organisational challenges. The following diagram describes the key principles highlighted in the official Scrum Guide.

That’s it! I haven’t listed the roles and artefacts because these are generally well-known. What’s most interesting to me is why the principles of Scrum (and Agile) are often misunderstood and/or intentionally or unintentionally neglected by organisations attempting to adopt Agile/Scrum, leading them to trip up and not reap the benefits (or ditch Agile altogether).

Why is Scrum described as an Agile framework?

To answer this, let’s begin by looking at where Scrum and Agile principles align:

Daily interactions

Agile says: “Business people and developers must work together daily throughout the project.”

Scrum says: “Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated Increment in the remainder of the Sprint.”

Every Scrum team has a Product Owner who represents the business and customer interests. Scrum teams have a Daily Scrum, and it is implied throughout the Scrum Guide that the PO is a crucial and integral focal point for the team’s priorities.

Working software

Agile says: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

Scrum says: ”Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.”

It should be noted that Scrum is not only for software development; it can be used for any kind of product development. However its iterative approach to delivery, when used with software, seems congruent with the Agile principle of delivering working software frequently. Scrum is conducted around Sprints of up to 4 weeks in length, and a product increment is delivered in each Sprint. Interestingly, while Agile has a “preference to the shorter timescale”, it deems it acceptable to deliver software every “couple of months”. Scrum explicitly states that 4 weeks is the maximum length of a Sprint because beyond that timeframe predictability suffers and risk increases. Therefore it can be argued that Scrum promotes faster delivery and feedback loops with the customer than Agile does.

Customer collaboration

Agile says:

“We value customer collaboration over contract negotiation.”

“Simplicity–the art of maximizing the amount of work not done–is essential.”

The simplicity principle can be taken to mean that constant customer collaboration will minimise the work done because only the highest value backlog items will be worked on in each Sprint. It may also refer to simplicity of design.

Scrum says:

“During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done. This is an informal meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.”

“The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings.”

Responding to change

Agile says: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Scrum says: ”The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.”

Scrum allows the Product Owner to add new items to the Product Backlog at any time, as well as change the order of existing items. This means that new requirements, if they are deemed of high value or priority, can be scheduled for the very next Sprint.

Self-organisation

Agile says:

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

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

Scrum says:

“Scrum Teams are self-organizing and cross-functional.”

“They [development team] are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;”

“[Scrum Master coaches] the Development Team in self-organization and cross-functionality;”

“The Development Team self-organizes to undertake the work in the Sprint Backlog, both during the Sprint Planning Meeting and as needed throughout the Sprint.”

“By the end of the Sprint Planning Meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.”

Technical excellence

Agile says: “Continuous attention to technical excellence and good design enhances agility.”

Scrum says: “The Development Team may also invite other people to attend in order to provide technical or domain advice.”

Scrum does not prescribe how the work will be delivered and thus does not talk about technical practices. Agile says that “technical excellence” is a good idea but is again silent on specifics. The conclusion we can draw from this is that the “Agile” technical practices we hear of such as TDD, BDD, continuous integration, continuous deployment, pair programming etc. are not really Agile practices at all, strictly speaking. There is no specific mention of them in the Agile Manifesto or the Principles. However, these XP practices are generally considered to be highly effective (even “best practice”) in software engineering and as such are congruent with the Agile principle of “continuous attention to technical excellence”. It is therefore considered wise for development teams to use some or all of these techniques when working within the Scrum or Kanban frameworks, not just XP.

Continuous improvement

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

Scrum says:

“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.”

“[The purpose of the Sprint Retrospective is to] Identify and order the major items that went well and potential improvements; and, Create a plan for implementing improvements to the way the Scrum Team does its work.”

“By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.”

Sustainable pace

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

Scrum says: Nothing specific about this, although the Scrum Guide does talk about the development team “forecasting” how much work to pull into the Sprint Backlog based on what they have delivered in the past. It does then seem that sustainable pace and the avoidance of “death marches” is very much an Agile principle, not Scrum (or at least is more prominent in the former).

Teamwork

Agile says: Agile mentions teams in the context of collaboration, self-organisation and continuous improvement but does not say anything else on the subject.

Scrum says: Everything in Scrum is about the team. Teamwork is described in the Scrum Guide as key to a successful Scrum implementation, particularly with regards to shared activities (cross-functional teams with no roles, sub-teams or titles) as well as the above Agile principles.

That said one could imply by Agile’s description of teams that they are referring to cross-functional teams. If a team is able to ship working software regularly then by inference they must have all the skills required to be able to achieve this, inferring cross-functionality.

Empiricism

Agile says: Nothing about this really. It does not mention estimation or the use of data for planning. It does put a focus on working software as the primary measure of progress but does not explicitly promote empiricism as Scrum does (inspection, adaptation and transparency).

Scrum says: “Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.”

Servant leadership

Agile says: Agile does not talk about leadership or management of any kind, whereas Scrum describes the leadership qualities required of the Scrum Master. It could be argued that Agile takes a more company-wide, customer-centric view of collaborating with “business people” and “users” (outside of the team), whereas Scrum focuses largely on the team’s interaction with the Product Owner and thus places more emphasis on the leadership required. Indeed the words “customer” and “user” (in the end-user sense) are not even mentioned in the Scrum Guide.

Scrum says: “The Scrum Master is a servant-leader for the Scrum Team.”

Summary

So it can be seen that there are several principles and practices that can be summed up fairly simply in Agile and Scrum. Most are intertwined but Agile makes a bigger deal about some and Scrum makes a bigger deal about others.

Many of the terms used today when talking about Agile are more Lean principles, such as building the “right thing” by validating hypotheses in the market. Feedback is considered crucial to Agile development but is barely mentioned. Agile and Scrum both seem to focus on the relationship with the customer or the business stakeholders and embracing changing requirements (which implies feedback is required) rather than making feedback the key factor.

Technical practices are covered in XP, which is considered an Agile framework (like Scrum) due to being iterative in nature and the focus on quality and technical excellence. Team practices such as pair programming, swarming, “stop starting, start finishing” are nowhere to be seen in Agile or Scrum. Nor is the term “the art of the possible”, which is often quoted as an Agile phrase regarding what can be done if you get people in a room and re-focus them on the higher purpose.

Process visualisation is also notable in its absence. Queue theory, activities, swimlanes, task boards, identifying bottlenecks, limiting WIP, etc. have more of a background in Kanban but are considered by many to be “Agile” principles or practices, perhaps because their implementation traces back to the key Agile Manifesto statements and principles.

Either way, what “Agile” and “Scrum” are is simple in some ways and complex in others. Some even describe them as philosophies rather than collections of frameworks, methods, processes and tools. They key point is that rather than getting too bogged down in what is and what isn’t Agile, let’s instead focus on our goals and how to get to them more effectively.