I’ve been iterating over a simple agility model the past few weeks, and after some additional reflection I determined that last week’s revision did not work for me. I decided to use this week to simplify the model, capturing what I want to represent as fundamental agility:
The center represents how agile is built on a foundation of a lean and learning organization; wrapped around the center are the interrelated personal, team, and organizational entities that need to support agility by understanding and adopting the values and principles from the center.
Specific implementations such as Scrum or XP aren’t a part of this model, which helps to differentiate that the various frameworks, practices and techniques are tools that support agility because they don’t make you agile any more than picking up a hammer makes you a carpenter.
How do we put this model into practice? I’ll use a more complex example than I did in my Timeless Agility post.
One major challenge in software development is delivering software that a customer will value – and we all know that giving customers what they asked for initially is likely to not be what they really wanted. Feedback is essential, because this is how we learn about what customers really want.
The traditional approach of gathering the requirements in detail up front is an attempt to learn about what the customer wants and has an apparent advantage in that we are in real-time conversations with the customer, discussing and documenting their needs so that we can move forward with confidence.
However, this falls apart in actual practice. Documents – even when they include wireframe mockups – don’t hold complete information, as much as we’d like to think that they do. Once a development team starts to implement the requirements, questions will emerge. A bigger problem is that it is extraordinarily difficult for customers to validate the look and feel of the software along with its underlying behavior by reviewing documentation.
Seeing the software in action works much better. I’ve heard this many times: “Now that I see it…” And of course this is the preamble that leads to change. And when you are hearing this at the end of a development cycle or as part of a major milestone, it becomes a letdown because there is a difficult conversation about to occur that includes the magnitude of the change(s) and the impact to the schedule and budget.
Agile development addresses this issue by asking that we:
Elaborate the requirements on a just-in-time basis. We can plan – at a high level – on what we want to deliver, but we don’t need to specify all of the details up front. We can defer the detailed specification of a feature until we are very close to the time that the development team will work on that feature. As a benefit, we won’t be accumulating a large amount of “requirements inventory” that has the potential of changing, creating waste.
Deliver small features in short cycles. Small, vertical slices of business functionality should be delivered in the shortest amount of time as possible so that we can obtain customer feedback as soon as possible. This enables the development team to learn and understand what the customer really wants (and values). Short cycles give us quicker feedback, and multiple, and continuous cycles increase the frequency of that feedback. We avoid “batching up” the feedback until a milestone or end-of-project event.
If we examine the layers of being a learning, lean and agile organization, we can see how these layers support and complement each other in this scenario:
Starting with a learning organization, we want the team to have a shared vision on what to build (and how to build it, but I’ll defer on this in the interest of brevity and focus). We also want the ability to adapt this vision as we move forward, to change our mental model about what the customer wants as we learn as a team (team learning).
The principles of Lean Development build on this. I’ve already covered that just-in-time elaboration of requirements helps to eliminate waste. Lean also states that we need to deliver as fast as possible. Small features delivered in short cycles amplifies learning, and the combination of delivering as fast as possible and elaborating requirements on a just-in-time basis means that we are implementing another lean development principle of deciding as late as possible. This allows us to make more informed decisions because we will have better information than is possible to obtain up front.
Moving up to the Agile layer, we find that the value of “Adapting to change over following a plan” in the Agile Manifesto – meaning that we value the ability to adapt to what we learn and incorporate that learning into our process realized through short delivery cycles (versus conformance to an initial plan). The objective is to deliver valuable software – valuable to the customer – as stated in the first principle of the Agile Manifesto:
“Our highest priority is to satisfy the customer with early and continuous delivery of valuable software.”
A couple of other relevant principles of the Agile Manifesto:
“Welcome changing requirements, even late in development. Agile processes harness change for the customers’ competitive advantage.”
“Deliver software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
Another principle sets an expectation that is different for business people: “Business people and developers must work together daily throughout the project,” because we are elaborating requirements on a continual, just-in-time basis and reviewing working software in short delivery cycles.
Keeping the five characteristics of a learning organization along with the seven principles of lean development and the four values and twelve principles of the Agile Manifesto in mind as you learn about and experience agile will help you to understand what needs to change as you do agile, so that you can successfully bridge the gap from doing agile to being agile at personal, team and organizational levels.