A lot of attention is paid (here, as well as elsewhere) on the “Agile Manifesto“, and while it’s an important component of the Agile way of thinking, it’s not the be-all, end-all statement that came out of the Snowbird conference around the turn of the century. Rather, there are twelve guiding principles in addition to the four core components of the manifesto. Let’s take a quick look at each of these, and see how they affect how we perceive and implement Agile practices…
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This is the single most important aspect of Agile that needs to be understood and adopted as a part of the culture of any organization that wants to be “Agile” — that the customer and end user is the ultimate focus of the entire process, from beginning to end. The customer is the judge of the success or failure of a product or feature — not the company or its stakeholders. The customer is the one with the problems that we are solving, and as such they need to be an integral part in the product process from inception to delivery.
Ignoring your customers until your product is ready to ship is the number one Agile anti-pattern in the world.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
The second most important part of Agile is…well, being “agile”. Any organization that still invests heavily in front-end definition, design, and requirements is not being Agile…and definitely not being “agile”. The entire point of agility is that you’re able to accommodate important changes in requirements at any point in the process, and still deliver something that’s useful to the customer and that solves one or more of their problems. Agile processes rely on prioritization and not contract negotiation to deliver success — when new requirements come in, they’re not subject to heavy, detailed change management processes — rather, they’re stack-ranked along with everything else that needs to be done, and assessed as just another task or user story in the process.
Thinking that things are entirely or mostly defined ahead of time is another massive Agile anti-pattern that many companies suffer from.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
There are a couple things going on in this principle — first, that working software is the goal of the process at every step, second that work should be iterative and improve upon itself, and lastly that the iterations that are engaged in should be shorter rather than longer. If you’re working on a project that runs for six months without checking in with the customer (or customer proxy), then you’re not being Agile. If you’re working on one-week iterations, but not delivering something that solves at least one customer problem in each iteration, you’re not being Agile. Agile iterations must be long enough to deliver working software, and short enough to ensure that what you’re delivering actually solves customer problems.
Just because you’re working iteratively doesn’t necessarily mean that you’re being Agile; iteration is important, but delivering working software is equally so.
Business people and developers must work together daily throughout the project.
Collaboration and interactions between people are key to the success of any Agile organization. Silos and “tossing requirements over the wall” are counter-productive to Agile approaches, as is segmenting your organization between “business” and “technology” people. Everyone on the “business” side should be ready, willing, and available to provide as much support to the “technical” teams as possible, and vice-versa. The age-old idea that there’s some inherent difference between the way that the “business” should be run and the way that “technology” should be run are entirely artificial and counter-productive in an age of rapid innovation and even more rapid delivery.
Discouraging collaboration or encouraging the “siloing” of efforts is a strong Agile anti-pattern that persists in many corporate cultures.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Agile values individuals as individuals, and it values teams as teams. People are not interchangeable cogs that you can randomly move from one project to another and expect them to excel every step of the way. Individuals are motivated by different things — and in a true Agile approach we harness whatever motivates the individual members of our organization to create teams of these motivated individuals who are internally driven to succeed. Agile bucks the idea that extrinsic rewards provide exceptional results, and rather focuses on ensuring that individuals have the motivation, environment, and tools that they need to be driven to succeed on their own. There is no “carrot or stick” approach in Agile — there are interesting and compelling problems to solve for customers that are solved by the people who have the necessary interest and intrinsic motivation to solve them.
Expecting people to perform merely because they’re a member of “a team” and not because that team shares an intrinsic motivation to deliver is an extremely common anti-pattern in large organizations.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
The age-old method of having a single SME who writes down everything they want and hands it over to developers as a “punch list” of requirements is heretical to Agile approaches. Different people think and communicate differently, and the written word is one of the worst ways to express what you’re trying to say. At worst, it is vague and difficult to decipher for the person who didn’t write it; at best, it’s a clinical, sterile document that exchanges precision for feeling. If the goal is to express the pain that the customer feels, and to motivate our teams to excel at their jobs because they want to, then neither of these approaches to written requirements will have the result we desire. Rather, we use things like User Stories, which are explicit in the problem that we want to solve, but which allow our development and technology teams to use their creativity to address in the best way possible.
Even when we use tools to track work and to communicate the most basic information we cannot forget that the most important way to communicate with each other — regardless of roles — is always face-to-face conversation.
Working software is the primary measure of progress.
Particularly in the world of large corporations, we have the concept that everything can be measured, assessed, and KPI’d. We track revenue, story points, velocity, burndown, bug counts, ad nauseum. Yet we often forget that what we’re really trying to do is to solve problems for people. And none of those measures track how much value we’re actually bringing and whether or not we’re solving customer problems. The end goal of every iteration should be working software — it has to do something that we believe to be valuable. Anything less than that is a failure; anything more than that is icing on the cake. Agile teams measure themselves on whether or not they’re contributing value, and whether or not they’re creating something that works at the end of every iteration.
Repeat this: Velocity is not the measure of progress. Burndown is not the measure of progress. Story points are not the measure of progress. Capacity is not the measure of progress. Deadlines are not the measure of progress. The only thing that matters is how much working software you’re creating.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
There’s this false idea in the world, held by both developers and business people, that Agile means no documentation; that Agile means doing whatever you need to in order to achieve a goal; that Agile means changing priorities and teams rapidly to ensure maximum output; that Agile means unpredictability and lack of forecasting. The fact is, one of the primary goals of Agile is to create an environment of predictability, of stability, and of a constant, acceptable pace of product development that scales indefinitely. There’s nothing in the principles of Agile that precludes creating plans for delivery (though those plans have some uncertainty to them!) or being able to project when something might be shipped. Conversely, there’s nothing in the principles of Agile that expects developers to engage in “crunch time” behaviors — in fact, such behaviors are in many ways antithetical to Agile concepts; if your team has to work extra hard to deliver something, you’ve failed as a business to prioritize your User Stories effectively.
No truly Agile practice should result in burnout, crunch time, nor extended and constant uncertainty — anti-patterns result in these contradictory behaviors.
Continuous attention to technical excellence and good design enhances agility.
Truly Agile teams do not slap shit together and call it “good” — they take the time and effort necessary to understand what it is they’re trying to do, how they believe they can solve the problems, and to break things down into small enough “chunks” of work that they can both iterate on the problem and deliver potentially shippable solutions at every single step of the project. The majority of this work happens before the teams commit to doing the work — there is work required ahead of time to talk about approaches, to discuss architecture, and to engage in discussions with business people, stakeholders, and technical teams. We often refer to these as kickoffs or backlog grooming — but Agile should never be an excuse for poor quality or bad design.
Bad design and low standards result in poor solutions that don’t really meet customer needs; it is a decelerating factor not an accelerating factor.
Simplicity–the art of maximizing the amount of work not done–is essential.
Far too many people read this the wrong way, and in doing so hamper their ability to fully engage in strong Agile practices. Simplifying your goals, your stories, your work, and everything else is a process that starts with the opposite — a very broad understanding of what the goals are and how they might be achieved. The result of such efforts is not necessarily a smaller project, but smaller and simpler increments that may add up to something very large — and which may also indirectly shrink the overall goals as well. The biggest hurdle here is that simple is harder than complex — especially when people engage in brainstorming and edge-casing, which often happens with technical teams. Solve the problem first, then iterate on it in small chunks.
“Make every detail perfect, and limit the number of details to perfect.” – Jack Dorsey
The best architectures, requirements, and designs emerge from self-organizing teams.
The key word here is “emerge” — when you put the right people together, and all of them are aligned toward the same goals, a few things happen. First, they naturally hold each other accountable, because there’s in intrinsic feeling of camaraderie and of purpose. Second, they support one another and at the same time challenge each other to ensure that the end result meets not only their individual expectations but their collective expectations — which are almost always higher. And finally, they improve the whole through collaboration — the sum of any self-organized team is at least 2x greater than its individual parts. The key factor here is self-organization, which can be a hard sell in many organizations — but the best teams are not those slapped together by a middle manager; rather, they’re the groups of people who chose to align themselves toward a common goal.
People who work toward a common goal because they want to will always be more effective, stronger, and more reliable than teams working together because they’re told to.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
In nearly every organization I’ve seen challenged by implementing Agile practices, the single biggest thing that they miss is the importance of continual or continuous improvement. Agile has its origins in Lean Manufacturing concepts — the value of the individual, the focus on the outcome over the process, and most importantly the need to constantly measure, adjust, and improve how you’re doing what you’re doing. Any team that chooses not to engage in retrospectives within the team and reviews with their stakeholders after every iteration risks stagnation and continuation of anti-patterns because they never realize them. Many teams view these sessions as counter-productive, as wastes of their time, as “soft skill” exercises that just take time away from execution. But most teams simply avoid them out of fear (and rationalize it however they like) — fear of being called out, fear of accepting responsibility, fear of change. The honest truth is, when run properly, these can be some of the most empowering meetings that the teams will engage in — they’re intended to push people to improve, to constantly get better and more effective, and there’s no good reason not to engage in those discussions.
Failing to properly “look back” and honestly assess how a team is doing and where they can improve is a FATAL anti-pattern to long-term Agile success.
