On an almost daily basis I see misinformation about Agile in articles shared on LinkedIn.
Some of this misinformation is so wide of the mark that folks who are learning about Agile are, at best, not actually learning anything about what Agile really is, and, at worst, being turned away from Agile and the potential benefits it might bring them and their organisations.
Of course there is no reason for folks who know no better to believe my article provides any more accurate information about Agile than any other. Hopefully other known, respected Agile practitioners will comment and verify what I am saying is correct.
I’d also appreciate any feedback on areas I can improve the article, along with additional questions to pose and answer, pushing it toward becoming a definitive FAQ on Agile.
Agile is a software development philosophy, described by just 4 values and 12 principles in the Manifesto for Agile Software Development (more commonly referred to as the Agile Manifesto, or even the Manifesto).
The Manifesto was created in 2001 by a group of 17 software practitioners who were operating with a variety of “lightweight methods” such as Scrum, XP (Extreme Programming), Crystal, RAD (Rapid Application Development) and FDD (Feature Driven Development).
Here is my attempt at Agile in a sentence (albeit a long one!):
Agile is a software development approach where business people and self-organising, cross-functional development teams collaborate with customers to continuously deliver valuable software, all the while remaining flexible and responsive to changing needs, working at a sustainable pace, and reflecting on and improving the software and their effectiveness.
The lightweight methods mentioned above (which led to the agreement on Agile values and principles) were in stark contrast to the prevalent methods for delivering software in the 1990s. Traditional software methodologies were heavy in process, phases and approval steps, and driven by documentation milestones rather than the delivery of “working software”. This would lead to software projects sometimes taking months, even years, before a line of code was written.
Another consequence of the traditional approaches was that developers would not get feedback* on the software they were building from the customers for whom they were building it until the software was “finished”. The time lag between when the requirements were gathered and when the software was delivered would often lead to the software not matching up to the current needs of the customer.
Agile approaches reduce this risk by shortening feedback loops as much as possible. Developers (including programmers, testers, designers, etc.) share their code and designs with each other, on a near-continuous basis. They also build the software in increments (aka “feature by feature”), showing the software they have built so far to the customer on a frequent basis (no more than every few weeks, often far more frequently).
If the customer is happy with what they see (i.e. it is “valuable” to them), they can start using it right away, even if it does not yet have all the features they (think they) want. If they are not happy, the team can make the necessary changes quickly and come back to the customer with a new version of the software.
* Thanks to Ed O’Shaughnessy for his feedback which led to this section on the importance of… feedback! Shortening feedback loops is a key underpinning of Agile.
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
“The best architectures, requirements, and designs emerge from self-organizing teams.”
~ Principles #8 and #11 from the Agile Manifesto
In order to be able to continue to meet the demands of rapid value generation for the customer and the business indefinitely, we need to ensure the codebase is kept in an easily adaptable state.
To achieve this sustainable pace, it is vitally important the system is architecturally consistent with the ability to adapt. Keeping architecture flexible is overlooked in many projects, and with the team continually incrementing in short iterations, after some time it is common to end up with big refactoring or rebuilding efforts in order to make the codebase adaptable again.
It is also important that teams do not get tired, stressed or burn out. Tired developers write poor/buggy code, and teams who do not stop to reflect and improve on the product they are building, and the way they are building it, will not build great software.
Simply, a method or framework which is consistent with the statement above — or, more precisely, aligned with all the values and principles in the Agile Manifesto.
Of course the lightweight methods and frameworks mentioned above (such as Scrum) could, post-2001, be described as Agile (but they do not equal Agile — see below).
*As mentioned above, Scrum pre-dates Agile. Post 2001, Scrum could be described as an Agile framework, but it does not equate to Agile. There are many ways to work which are consistent with Agile but are not Scrum.
*Astute readers may have noticed I said “Agile is not a means of getting more done, faster”, but then went on to say that “Agile can improve operational efficiency — deliver more value, faster”!
Due to the iterative and incremental nature of Agile approaches, where we continuously focus on the highest value deliverables in very small batches and defer the rest, an adherence with Agile values and principles will likely derive greater value returns from your investment, and earlier, as compared to a traditional sequential, documentation milestone driven approach. We are not doing more work more quickly — rather, we are delivering work in smaller batches, sooner — keeping things simple, eliminating process steps and work which does not contribute to value.
Such a focus on early and often delivery of customer value inevitably leads to an improvement in “flow efficiency” — where the time software code is not delivering value to the business is reduced — and it is this form of efficiency to which I refer.
Agile describes a set of universally sound project management and software development principles, all of which are likely to reduce risk, at least in some measure, for all but the most risk-free of projects.
Before anyone calls out “Agile didn’t invent these things!”, these principles are nothing new, and were not new in 2001. Rather, Agile packaged them in a convenient form.
Agile encapsulates most of what we need, at least from a values and principles perspective, to deliver software projects more effectively. What projects would not benefit from a focus on individuals and interactions, continuous improvement, delivering working software for the customer in rapid iterations, technical excellence and responding to change? On working across functions and departments, delivering, reflecting and improving* in short, continuous cycles?
This is particularly true if the alternative is teams reverting to their functional silos, handing off work, requiring long approval cycles, back-loaded testing phases, and measuring progress using documentation milestones. Such approaches are simply not viable anymore in the majority of industries relying on rapid software delivery and results.
However, given the nature of Agile, there are key elements which must be in place, at least in the medium to long term, for an Agile delivery model to be sustainably “fit for purpose”:
In short, we must have a customer, and our customer has to both want, and be able to absorb, an Agile approach. Without this prerequisite in place, it becomes nonsensical to describe the way we are working as “Agile”, at least from a delivery point of view.
Even if Agile passes the “fitness for purpose” criteria, one could also argue that Agile is not a good approach — or at least is not needed — for simple or complicated endeavours (as opposed to complex ones), i.e. projects which have a known, predictable set of steps to follow to meet a desired objective, with no learning or feedback loops required.
One could equally argue that we “might as well” do all projects in an Agile way, even if they are simple or complicated. However, if we are not currently set up to do Agile Software Development, and the majority of our projects are simple or complicated (this is rare, but possible), the costs of making the changes required to enable Agile may be too high to justify.
*Hat tip to Alistair Cockburn’s “Heart of Agile” model, which infers that any approach which broadly involves a continuous focus on four key activities — Collaborate, Deliver, Reflect and Improve — could legitimately be described as an Agile one.
** An ex-colleague of mine, and highly experienced and respected agile practitioner, John Sullivan, correctly pointed out in the comments that, although “physical things like automated testing and CI builds” are the typical technical approaches in agile environments, they are not agile per se, because they are tools and practices rather than values and principles. Nouns rather than adjectives. Most importantly, there must be a desire to continually, repeatably ensure that code works properly — both the code we add, and the code already in the system.
I also thank John for his feedback and comments around emergent/adaptable architecture, which I have incorporated earlier in the article.
Because Agile is a set of values and principles, it can be thought of as a thinking model, or mindset. That is, an individual, team or organisation who willingly delivers software in a manner aligned with the values and principles of Agile could be said to be behaving in an Agile way, or having an Agile mindset.
While Agile, from a project mechanics point of view, is about continuously delivering valuable software, there is also a prominent human element. The number one value in the Manifesto is “Individuals and Interactions over Processes and Tools”. Number three is “Customer Collaboration over Contract Negotiation”.
However, the most telling hint that Agile is intended to be a more humane approach to software delivery is in principles 5 and 11:
“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.”
There is no doubt an emphasis on autonomy and empowerment* in Agile. This strikes a chord of dissonance with many in the industry due to the traditional way development teams are managed, which is more akin to “command and control”. It is also contrary to the traditional way of working, which is to deliver big batches of requirements according to an agreed schedule rather than be experimental with both product and process, embracing frequent change and feedback.
To be consistent with, and glean benefit from, Agile, individuals, teams and organisations often have to embrace new servant leadership styles, and managers must show genuine trust in their teams rather than micro-managing them. The focus on self-organising teams who are continuously improving often requires a shift to a “safe environment”, in which team members feel psychologically safe (meaning there are no negative implications for them) to express their opinions on things that aren’t working, either from a product, process or human relationship perspective.
The way people think and behave manifests in the organisational culture. Given the changes in mindset and behaviour required for many, it is little wonder “going Agile” usually becomes an enormous undertaking which extends way beyond the development team(s).
* Thanks to Daamon Parker for prompting me to include the importance of psychological safety, autonomy, empowerment, trust, support and experimentation for being successful with Agile.
I hope this article has helped solidify your understanding of what Agile is and isn’t. If you are interested in learning more, or would like me to help your organisation with Agile training or coaching, please feel free to send me a message, or follow me on Twitter.
What FAQ’s (and answers) would you like to see added?