Don’t Forget About Agility

My motivation for this article

For 7+ years, as of the time of writing this, I have been openly objecting to Agile’s impact and usefulness as a means of project management and approach to software development.

I’ve spoken about this topic in numerous public forums, hijacked an interview last year on a related topic to share my thoughts about Agile, and participated in countless private debates and conversations on the subject.

I’ve recently joined Brainly, the team building the world’s largest social learning community, as the CTO. Out of respect for my new colleagues and in anticipation of future discussions about Agile with my new team, I feel I need to publish a more complete set of thoughts on my point of view regarding Agile based software development.

Don’t live by Agile rules, live by the principles.

This is the point of this entire article. If you understand how this applies to adding agility to your software development and project management methodologies then go away now and do something more productive with your time.

For those who want to explore this statement in more depth with me, let me start by saying that Agile-with-a-capital-A is the thing I’m objecting to. This is the formal Agile. The noun. The thing-you-can-buy that will fix your organizational problems, and allow you to ship software product better, faster, happier… insert-unqualified-expectation-here.

Software development is a team activity.

Like any team activity the results are based on the contributions of individuals acting alone, but also acting in relationship to each other.

Agile is a set of practices and processes that make assumptions about your team makeup and treats that unique relationship or people + project + physical environment, which is a product of those individuals in the team, as a known constant.

It’s not. Take any 5 people and put them in a room for 8 hours a day for a year with a set of tasks to perform and give them no direction on how to organize themselves and they will develop a relationship that is unique to that team, working in those conditions. The way they communicate, the processes they choose to use to organize their work, and ultimately the efficacy of the team and their work product will be unique to that set of conditions.

Rewind time and start with the same set of conditions but distribute those 5 people geographically throughout your building. Raise your hand if you think this will result in the same relationship, communication process, organizational process and same work product ?

There is no definitively correct answer to that last question. It depends on the people, the tasks, the room, the building, and many other undefined attributes of that scenario. Every variable can change the outcome, or not. Who is to say which is better for those unknown 5 people in those unknown conditions ?

I object to Agile because it pretends to have the answer.

For example, The Twelve Principles of Agile Software states as one of its principles, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

This is wrong. I have personally worked with many talented Software Engineers who did not have the interpersonal skills to be *more* efficient and effective conveying information face-to-face than say, over email, or Slack, or some other communication channel that allows for unnatural conversational pauses and reflection before response.

Putting that to the side for a moment, how can this be true for all conversations ? As a Software Engineer myself I constantly find myself in conversation with other engineers and I often ask to “see the code” to understand what is being explained to me. Speaking for myself, I prefer not to comb through code and build mental models and enter into deep thought processes with someone sitting next to me talking or staring at a screen with me.

I have had countless conversations over Slack with long pauses between statements as code was mentally digested or deep thought was performed before the next response in the conversation was offered.

I can definitely say that some of the most productive working relationships over the last 20 years with work colleagues have been without ever meeting my colleague face-to-face. This false assumption about face-to-face communication stated as a principle is just one of the oversubscribed-to assumptions that make me resolute in my opinion against Agile.

I’m taking a hard stand here.

The Twelve Principles of Agile Software are infected with false assumptions and should be thrown away. But that doesn’t mean that the Manifesto for Agile Software Development is bad. In my opinion these are the real principles of agility and should be taught and discussed more broadly instead.

Why is it that The Twelve Principles have gained so much traction and the subject of so much discussion and promotion ? Because you can’t package and sell “It depends” and that’s really what it comes down to if you internalize the Manifesto. It depends on all of the variables of the situation in which you are trying to promote agility.

It’s not all bad.

There are some great ideas in the Manifesto for Agile Software Development. The 17 people who met in 2001 codified a thought process that has penetrated deep into the executive meeting rooms of the biggest companies in existence today and has been credited with many successes at companies of all sizes.

The ideas encompassed by the Manifesto are timeless truisms that are more obvious and self-explanatory to me today than they were 12 years ago when I was running my first Agile experiments at my own software development house.

The overreach was the creation of, and poor design of, The Twelve Principles, and subsequently the build out of big business selling Agile as a set of processes to be installed uniformly across an organization, instead of a set of principles that needed contextual assessment and application. If Agile had been marketed with a warning label :

For responsible and thoughtful consumption, please seek the advice of an expert if any of the following conditions appear,

• Operational and Process Dogmatism,
• Excessive Reliance on Examples of Other Agile Implementations,
• Termination of High Performing Remote Workers Because They Can’t Meet Face-to-Face,
• Company Wide Implementation of Ceremonies Without Assessing Their Value,
• Use of the Statement, “That’s Not Agile”

I think we all would have seen the big business Agile movement as a good idea that needed to be iterated forward. We could have approached Agile with more thoughtfulness and ultimately more agility.

Today I continue to object to Agile and promote thoughtful agility in my own teams. There’s no playbook for that but that’s also kind-of the point.

P.S. If you already take a pragmatic approach to Agile then I consider you a fellow believer who values agility over Agile and I would love to hear your success story in the comments below.

— — —

Manifesto for Thoughtful Agility in Software Development

(a pragmatic expansion on the Manifesto for Agile Software Development)

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to realize that systematizing values is hard and should be done at an organizational level where team context and conditions can be better understood and considered in the solution. We have come to value:

Individuals and interactions over processes and tools

Choose processes and tools in service of creating high value interactions between individuals on the team instead of dogmatically choosing processes and/or tools and expecting individuals to produce valuable interactions with each other.

Working software over comprehensive documentation

Use documentation in service of the individuals and interactions on the team for the purposes of producing working software more effectively or more efficiently. Nothing less, nothing more.

Customer collaboration over contract negotiation

Implement a process for, and set of expectations with, your stakeholders such that they can propose project scope changes at any time and in return will receive an assessment of the impact of the change on the project success criteria.

Responding to change over following a plan

Implement a process for, and set of expectations regarding, the proper cadence for integrating change into previously planned work. Optimize for the lowest impact and most frequent change integration cadence your project and team can withstand without adding unreasonable risk.