When people hear the word ‘agile’, what immediately comes to mind is a software development methodology like scrum, XP, and Kanban. They might think about iterations, sticky notes, and daily stand-up meetings. But agile is so much more than tools, techniques, and structures. In fact, you could say that agile exists in spite of all the structures companies put around it. Agility means having flexibility to navigate around constraints and unknowns.
The Agile Manifesto originally applied to software development, but that was just a mistake of history. The original signers were programmers, so they talked about the values and principles in terms of software. However, they almost immediately discovered that the values and principles apply to any product development, particularly in knowledge work.
Agile is a mindset of learning and discovering how to manage uncertainty. The four Agile values tell us how to efficiently learn and discover in the software domain. Taking each in turn, we can learn and discover more from individuals and interactions than from processes and tools. We can reduce uncertainty more efficiently by looking at working software more than by looking at a set of documented specifications. Clearly more can be learned via collaboration with customers rather than the adversarial perspective given by contract negotiation. Finally, there can be very little learned and discovered by following the original plan; much more is gained from responding to change.
The Agile values are supported by twelve principles that help us make sure that learning and discovery is happening in our organizations. Each of the principles has a message about behaviors that guide project teams to continuously learn and discover better ways to deliver a working product. While there isn’t necessarily a direct mapping between the values and principles, I find it helpful to view each principle as especially supporting one of the values.
Individuals and interactions over process and tools
Build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done.
Daniel Pink, in his book, Drive, lists three elements of the motivation formula: autonomy, mastery, and purpose. In situations where people are paid fairly, this trio drives, engages, and stimulates us to do our best work.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Long hours make us less, not more, productive. Allowing that there will be occasional exceptions, overtime only serves to cover up for schedule, management, or quality deficiencies. Working overtime to fix a symptom of broader issues only enables the broader issues to continue without penalty. The Agile approach exposes these deficiencies as early as possible and remedies their causes, rather than treating the symptoms.
The best architectures, requirements, and designs emerge from self-organizing teams.
The essence of emergent design is that we start with what we know, create an initial design, then extend the design as we learn more. Self-organization, also known as spontaneous order, is the spontaneous emergence of order out of seeming chaos. These two ideas, emergent design and self-organization, are at the heart of valuing individuals and interactions over processes and tools. Software development, as well as other knowledge work, is a creative endeavor. Prescribing the use of certain tools and adherence to processes tends to hinder creativity. Teams that organically form around the work are inherently creative and driven by the three elements of the motivation formula.
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.
Agile development is a series of experiments. There is really only one way to know if a product works: use it in the same way as the customer would. There is also only one way to know if what you’ve built is what the customer actually needs: use it the way the customer would. With that in mind, the best way to test the product is to use the customer. This is no different from traditional product development in that the true test happens when the customer uses the product. The difference with Agile is that we want the customer to test the product early and often, so that we don’t waste development time and money on a product they don’t want or can’t use. So we develop iteratively – we develop something that works, but it may not have all the features or formatting yet. We give the customer something to test as soon as we produce something that appears to have a use.
Working software is the primary measure of progress.
Agilists are concerned about cost and schedule constraints, but when we want to know if our projects are going well our first metric is the amount of value delivered to the customer. We are concerned with whether the rate of delivery is increasing, whether the customer still thinks the value delivered outweighs the cost of delivery (read: cost/benefit analysis), and whether the quality of the product allows the team to continue to deliver new valuable features (i.e. no re-work).
Simplicity -- the art of maximizing the amount of work not done – is essential.
"Make everything as simple as possible, but not simpler." - Albert Einstein
There is a Lean concept that says you don’t want to waste your time and money building a product no one will want to use or pay for. The idea is to build a product that allows a team the maximum amount of learning and discovery with the least effort. This is referred to as the Minimum Viable Product, or MVP. Part of making sure you expend the least amount of effort is to do the simplest thing in the simplest way. We want to give the customer something to react to as soon as possible, so we don’t want to spend too much time making our software code perfect. We are more interested in whether we have built the right thing, and then we can worry about adding more functionality and complexity based on the customer needs.
Continuous attention to technical excellence and good design enhances agility.
“Simple” does not mean bad, though. Unsustainable and poor-quality product development contradicts and reduces agility. Architecture that is poorly conceived or is not aligned with the product vision will hinder the changes you want to make. Misaligned architecture will work against the team and its growing understanding of the system’s purpose and realization.
Customer collaboration over contract negotiation
Business people and developers must work together daily throughout the project.
Shorter feedback loops are necessary when trying to discover the MVP. The most immediate feedback is available when the customer and the development team are always connected.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Requirements gathering, clarifying questions, product demonstrations, feedback, peer review. Stop me when you read a type of interaction that is better from a distance, over the phone, or via email. Multiple studies have proven the value of face-to-face conversations, especially in the area of non-verbal communication.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Early and continuous delivery is the basis for better ROI from agile projects over traditional projects. In the end, the agile project might cost just as much and take just as long as the traditional project. In the traditional project, the benefits will not be realized until all the requirements have been met and the full product is released. The ability to use a version of the agile product sooner to begin receiving some benefits to offset the costs is a huge difference in ROI.
Responding to change over following a plan
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Transparency, inspection, and adaptation are the three pillars of Scrum and they apply to all Agile product development. Traditional projects conduct lessons learned meetings, sometimes referred to as post-mortems. These happen when a project is over and the team is disbanding, which means the “lessons” will not necessarily apply to the next project and team that each person joins. Teams that frequently review recent performance , communication, and collaboration, and then take action based on their discoveries is likely to be more effective.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
There are several reasons to welcome change during the execution of the project. First, businesses don’t stop changing just because there is a project happening. To be competitive, we need to allow for changes during mid- to long-term projects. Second, our understanding of the business problems can change during the execution of the project. In some cases, new insights can change the solution in a positive way. Finally, we need to be open to emerging technologies that can be part of the solution.
The product architecture has to be able to support changing requirements. The architecture should be flexible enough to support implementation of changes and robust enough to stay stable during development. To align the final product with customer needs, changes must be seen as a possibility and not as a way to delay and complicate a project.
Being Agile
Agilists are informed by the values and guided by the principles, but there is virtually no limit to ‘agile’ practices. This fact is critical to understanding what agile is, because as soon as there are limits placed on practices, agility itself is limited. As an example, Scrum is one set of practices that stand under the Agile umbrella, as is eXtreme Programming (XP), but if a team or individual does not think beyond the rules of the Scrum Game, they are not agile. We say that those people are ‘Doing Agile’ because they approach Agile as a process and a set of practices.
Being Agile means approaching Agile as a mindset and culture, internalizing the values and principles, so that the adoption of particular practices is based on the usefulness under the current circumstances, not because there is a prescribed process that teams must follow. It is relatively easy to get a team or company to rigidly follow a set of practices like those described in Scrum or SAFe. The problem is that projects are not predictable, so people must have agility to adapt to the inevitable changes. Mastering basic practices should be a starting point to becoming Agile, not the end of the journey.
Why Agile?
In the course of our work, of course, there are people who just want to be told what to do. They want a checklist of practices so they won’t need to think. This is a task-based mentality and works fine on an assembly line. With an assembly line, task workers know what is going to be produced; in fact, there are controls in place to make sure the final product is well known before work begins.
On the other hand, knowledge workers want to know the context of the work, the reason for the work, and want to innovate to produce better products. Knowing why our work is needed is important to knowledge workers because the exact outcome of the work is not knowable until the work is done. This is not to say that there is nothing known when knowledge workers begin, but it does mean that the exact final outcome is not knowable in advance. Whether doing software development, finance, marketing, education, or even some type of operations, most people are knowledge workers.
In addition to the outcomes being unknowable, knowledge work also involves more intangibles than task work. The person who builds a house uses a finite supply of tangible materials. In that circumstance the cost of changes is very high. The person who builds software is producing code, which has no practical limit and has a very low cost of changes. The Agile values reflect the idea that the best outcomes are achieved if decisions are made as late as possible, waiting until the last responsible moment so the customer is certain to get what they need.
Flexibility, transparency, inspection, adaptation, autonomy, mastery, purpose…there is no limit to the attributes of a master agilist, just as there are no limits to what a truly agile team can accomplish. Constantly striving for better, higher, faster – that is what Agile is.
Please subscribe and share this blog using the widgets below and Follow me @QuietAgilist or Connect with me on LinkedIn to get updated when I post a new entry. It's free with no obligation!