When I first discovered “agile software development” in 2005, and experienced working in an “agile way”, the impact on me changed my career. People say you gravitate towards what you’re good at or enjoy, and agile helped reveal how much I value working together on a goal.
At that time, my mentors in agile software development reiterated to me the importance of using principles for experimentation, how technical practices are the systemic constraint of software agility, and how continuous improvement is not a meeting or post-mortem. They guided me with customer centricity, introduced new methods and programming practices, and motivated me to learn systems thinking.
But most of all, they kept me mindful that the manifesto for agile software development is about agile software development. Today, I lament the state of agile in the industry today: what agile is perceived to be, what people talk about, what experiences folks have with “agile transformation”. Similar to exploring the gaps between what Scrum is, and what Scrum isn’t, I’d like to do the same with agile. What follows isn’t an all-inclusive list; rather, the topics which I believe are misrepresented often and most damaging.
“We use the Agile Methodology.”
Articles about “the Agile Methodology” are everywhere.
Let’s create shared understanding by setting our definitions from a trusted source.
meth·od·ol·o·gy noun: methodology; plural noun: methodologies a system of methods used in a particular area of study or activity.
meth·od noun: method; plural noun: methods a particular form of procedure for accomplishing or approaching something, especially a systematic or established one.
The agile manifesto contains four values and twelve principles. Of the twelve principles, we might be able to infer methods (you might even argue this is the point…), while none of them describe exactly an established procedure for accomplishing an outcome (again, maybe that’s the point).
If we really stretch our thinking, we might be able to infer a method from a couple. For example, we could consider:
- Deliver working software frequently…
Though again… is this really a method? Or a principle which speaks to software development practices as the systemic constraint of software agility? - Face-to-face conversation…
Again, hard to call this a method by definition, especially since the principle merely suggests effectiveness, not an established process.
The closest principle which might suggest a method is the last:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
You might call this a method, though I’d argue it isn’t a “particular form”, and even such a case wouldn’t be sufficient to call this a “methodology”. At best, you might say, “the agile method” to suggest the practice of inspecting an outcome, though Francis Bacon might be sad to hear you missed the point.
In short, there is no “Agile Methodology”. Be weary of those suggesting otherwise.
“Okay okay, we’re using the Agile Framework, then.”
Let’s go back to starting with definitions and ensure we’re speaking about the same thing.
frame·work noun: framework; plural noun: frameworks a basic structure underlying a system, concept, or text.
Stated again, agile is a set of four values and twelve principles for use in software development to enhance learning throughout (and ultimately, software development effectiveness). I suppose you could massage the definition to fit the meaning here, though what if we consider the word “manifesto” – given all the discussion today about agile originated from the Manifesto for Agile Software Development.
man·i·fes·to noun: manifesto; plural noun: manifestos a public declaration of policy and aims, especially one issued before an election by a political party or candidate.
The “agile manifesto” was signed by a group of seventeen people interested in pursuing alternate approaches to software development (compared to methods in use at the time). They publicly declared their aim and beliefs in the form of values and principles. Manifesto is clearly the right term.
If you intend to refer to the “agile framework”, why not be specific? Take for example two frameworks which pre-date the Agile Manifesto, XP and Scrum, and how they align with agile values and principles. Referring to them by name creates clarity. If you intend to design your own unique ways of working to be informed entirely by agile principles, great, feel free to call it a framework. Otherwise, “the agile framework” simply doesn’t exist.
“Agile requires a timebox” or “Agile is about forcing work into sprints”
Planning a timebox for whatever purpose you intend is a method, as discussed prior. The closest interpretation of the agile manifesto to this method might be the first principle stating the relationship between customers and frequent delivery. What’s not said, however, is delivery must be on a cadence, a sprint, a timebox, a “sprint goal”, a “user story”, or any other method which folks often equate to agile.
Agile software development encourages us to design our methods towards frequent customer interaction via working software. How you do this is not a matter of agile per-se, rather your application of the principle(s).
“Agile is about more than just software development.”
Of all the statements I hear in our industry, this one triggers me the most. In fact, if I had to choose one I believe to have caused the most damage to our organizations, this is number one on my list. “Agile transformation” is at the root of so much harm, neglect, and poor experiences on people, products, and organizations, I fight feelings of frustration every time I hear it.
Let me first acknowledge my understanding of how “agile done poorly” is not a good proxy for “agile transformation” or agile in the first place. I am deeply aware of how agile imposition, the “agile industrial complex”, certification schemes, and other negative applications of four values and twelve principles are not “agile transformation”. I don’t think we need to debate this.
The perspective I’d like to share with you, instead, is that the form “agile transformation” evolved into was misguided due to co-optation.
If “software development” literally being the title of The Manifesto for Agile Software Development isn’t clear enough, the first sentence stating the intent seems rather damning:
We are uncovering better ways of developing software by doing it and helping others do it.
Somehow along the way, we took a turn towards organizational change focused on things other than agile software development, yet called it “agile transformation”. On top of that, we mixed in gatekeeping and paywall schemes to “certify” privileged people for their ability to provide project management to ensure business deadlines are met. With money comes power and just a few years after the manifesto, folks were already lamenting the status quo.
If we take the Scrum Alliance certification database as a proxy to illustrate co-optation, at the time of writing this post, searching for only “Certified Scrum Developer”–a certification gained by programming–identifies 8,382 people.
However, searching for only “Certified Scrum Master”–a certification which requires no programming to achieve–well, there are literally too many people to return a search result.
If what you desire is organizational development, management transformation, measurement systems, work forecasting, transparency and visual systems, facilitation, team development, experimentation, learning organizations, operational effectiveness, and other challenges which often get lumped into “agile transformation”, you might consider there are already communities with decades-long study, science, and methods to learn from. (Yes, every one of those links are to separate bodies of research, thought, and study without the word “agile” in them)
Looking to agile for your non-software context is questionable at best. Agile is a set of four values and twelve principles for software development, which often can be very effective for its stated purpose. Let’s try that, for a change.
“There are no agile best practices.”
Folks often proclaim there are no silver bullets in agile, or emphasize how “best practices” are an anti-pattern in agile thinking. I argue this is false, though my argument is grounded in the lens of what agile is, and is not, stated above.
If we rightfully adopt the view that agile is about software development, I don’t think it’s unreasonable at all to claim there are best practices which characterize agile. In fact, you might consider taking all of the programming “rules” of XP and calling them best practices for agile software development. Therefore, just a few best practices are (not intended to be a complete list):
- Test-first programming
- Commit and integrate in a matter of hours (at worst), not in a matter of days (or worse)
- Refactoring is a part of writing code, not a late-stage activity
- All bugs are guarded by unit tests
- Production code is (at least) pair programmed
However, if we mistake practices and processes like Scrum Masters, story points, user stories, backlogs, agile coaches, release trains, PI planning, burndown charts, or other things unrelated to agile software development, then yes – there are no best practices. In fact, you might consider whether you need to use such things at all.
“Agile requires co-location” or “Agile can’t be done with remote teams”
The manifesto for agile software development includes a principle which states:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
When this principle was written, video conferencing technology like WebEx and GoToMeeting was still in its infancy. Most remote conversation relied on speaker phones in the center of a meeting room table or VoIP through applications like Skype. Remote code collaboration through technology like Git had yet to emerge, with the best available experience for developers funneling through tools like CVS and Subversion. The ability to have an effective synchronous conversation (including activities like diagramming on a whiteboard to increase shared understanding) was nearly impossible while remote. Pairing remotely was practically out of the question.
If we rewind and imagine ourselves in the shoes of people circa 2001, face-to-face communication represents everything a phase-gate process is not: Dialogue over goals and objectives, the combination of visual and verbal communication, a synchronous approach to rich conversation which builds shared understanding… not to mention speed.
It’s hard to fault people for literally interpreting “face-to-face” as “agile must be co-located”, though the principle is less about co-location and more about collaboration, interaction, and dialogue. “Face-to-face” here is a rejection of the phased software-by-specification approach, of the silos between business, development, and testing (and customer…), and of the idea software development is predictive, rather than emergent.
It’s probably true that the easiest way to apply this principle is through co-location of people, though the mindful student of human systems always holds close the truth that collaboration does not equal co-location. Especially with the capability technology provides us today, it’s never been easier to have a rich, synchronous conversation with visual elements from anywhere in the world. Furthermore, codebase communication tools exist which facilitate collaboration in ways not possible when agile was scribed as a manifesto.
Agile teams are not co-located, instead, they are collaborative, synchronous to the best of their context, and prefer methods which enable them to discuss, decide, and work together. To say this can’t be done remotely is not only false, but ignorant to the base conditions which make collaboration so effective in the first place.
“You can’t have more than nine people on an agile team” or “Agile is ‘two pizza’ teams”
Whether it be the “seven plus/minus two” rule or the popular “two pizza team” rule, the effectiveness of small, self-organizing teams has been popularized throughout the business world. It makes sense: Small teams have fewer relationships to navigate, fewer unique personalities to understand, less communication overhead, generally an easier path to self-organization.
That’s all the principle is, though: Teams which self-organize to deliver value directly to the customer. Whether the team be two-pizza sized, or twelve-pizza sized, nothing about the number of people on a team equates to agility. Instead, what’s truly important when using agile principles for software development, is the ability for the team to directly evoke a feedback loop between customer and software.
In fact, I argue the false assumption of “small team equals agile” is another one of those good ideas implemented at face value which contributes to dysfunction. When it comes to the goal of delivering value, in the pursuit of “small agile teams”, I have seen many organizations justify a dependency chain of teams (components, capabilities, etc.) to “keep team complexity low”. Another classic systems thinking misfire: By focusing on parts, namely “two pizza teams”, organizations fail to see the importance of minimizing dependency in the system of work.
If increasing the membership size of the team eliminates dependency, start there. Doing so is agile software development: self-organizing teams with the ability to deliver valuable software. Once there, the agile principle of retrospection will help you improve the system of work to reduce complexity, overhead, and (likely) team size.
“Agile is about completing projects faster” or “Agile is twice the work in half the time”
Jeff Sutherland wrote a book highlighting the value of attending to dysfunction and delay, abandoning gated work systems, customer collaboration, and cross-functional teams. He called it, “Twice the Work in Half the Time”. Unsurprisingly, when you reduce decision making latency and allow coding to start in conjunction with customer interaction, things go faster. When we work in teams with short feedback loops, improvement happens throughout – from product to process. Given he advocates for such things, the title of the book isn’t so surprising.
What IS surprising, however, is how this book became a promise in the eyes of management. Somewhere between publishing a popular book and mainstream agile adoption, the agile principle of “early and continuous delivery of valuable software” became “twice the work in half the time”.
Even more malevolent is the pattern of agile becoming a solution to the problem of developers, rather than a solution to the environment provided to developers. Now apply this false promise of “twice the work” without the organization changing to benefit software development and, well, you get the manifestation of popular agile today.
“Agile Coaches are a helpful part of organizational change, agile transformation, and improving results.”
That was true, once. It’s probably not today.
Agile Out Loud 
Some great points here – a very good article – but I will disagree regarding best practices.
The best practices are essentially XP practices. Some of them have been discredited and shown to favor certain personality types over others. I do not feel that test-first programming or pair programming are “best practices”. I feel that they are practices that are effective for some people, but not “most” people. There are very effective alternative practices.
Also, the key element that is missing is managing one’s test coverage – not just unit test coverage, but coverage at all levels of a system. Today’s systems are distributed, and integration tests are essential. So are component-level tests. Unit tests are only one part of the testing strategy, and for distributed systems, a strong argument can be made that unit tests are not the key element. Regardless, the most important testing practice is not to use a “test first” approach, but rather to ensure that one maintains high test coverage.
LikeLike
I’m afraid that everything you write is defensible, logical, sometimes self-obvious, and should shake the foundations of the agile-industrial complex to the core. But it won’t.
It won’t because the two fractions of the software development theater of operations hear entirely different words — and the one with control over the budget, hiring, buzzwords, boardroom and corporate message will silence you by calling you a charlatan.
The other — those condemned, like Sisyphus, to roll the code stone up the hill for eternity — have no voice, and therefore, no influence. This fraction hears what you say, cheers from our tiny cells, and hopes for another ray of sunshine like this to penetrate our gloom.
LikeLike