When I joined my last company I was transitioning from healthcare public policy to private healthcare IT. New to IT, I was a little behind the eight ball when it came to the project delivery methodologies discussion raging in my, then, new company. The discussion was over transitioning from a Waterfall approach to delivering solutions to our customer to a more collaborative Agile one. I came in naïve and left a proponent of Agile. Nonetheless, I do not reject or disparage Waterfall; a methodology is simply a way to approach an activity and therefore may or may not be useful depending on personnel or circumstances.

So when Stuart Hamilton’s article – Why Agile Doesn’t Work for Large Projects – appeared in my LinkedIn feed one morning I approached it inquisitively. “Hmm, I wonder in what ways Agile might not work for larger projects?” I clicked.

Five Adopting Agile Misconceptions

I clicked hoping to find examples or evidence of when Agile might not be the best methodology for large projects and learn a bit over breakfast. Instead, the article was a defense of Waterfall evidenced with what appeared to be misconceptions around Agile.

Keep in mind: I do not know Mr. Hamilton and LinkedIn is not made for long form, in-depth treatises, so this is not a rejection of Mr. Hamilton’s premise or refutation of his article. Rather, I noticed in the article some generalities and misconceptions on what is Agile, and mistakes early adopters of Agile make. I noticed because they were all mistakes and misconceptions my former company and I made.

Below are five basic adopting agile misconceptions (or mistakes) and ways to address them. Agile may or may not fit you or your company. Determining that will take curiosity and being open to change.

Mistake: Mandating from on High

Mr. Hamilton’s article starts with a fairly typical company adopts Agile story: CEO learns Agile is new, hip, and has potential benefits. CEO then mandates all projects be Agile. Employees then complain Agile does not fit projects currently in flight…as if that is Agile’s fault.

The problem here is not a shortcoming of Agile, but a mistake in leadership. No leader with fiat powers should mandate major methodological change without a robust explanation of why the change in methodology is being implemented, training on the new methodology, and a gradual transition to the new methodology. Each of these steps requires discussion and feedback with those affected by the change to suss out problems and enact refinements. This is standard change management; without these actions any change will drag out longer than necessary or fail from lack of support.

Change Requires Everyone

No one, leaders included, can possibly know everything or anticipate every problem – Leaders who engage their staff in change management will uncover an organization’s idiosyncratic problems sooner and generate greater and more innovative solutions to solve them.

No one, staff especially, can be expected to perform a new function in a new way without some level of explanation or training. Major change management requires major retooling of how work is done and people should be given time to develop their new skills and “muscle memory.” Complaints that Agile does not fit current projects might contain valid concerns, however, it is also likely staff new to Agile need time to see how work can be done in an Agile way.

Really, this issue is methodologically agnostic. If the methods were reversed and the CEO mandated a transition from Agile to Waterfall, the same arguments could be made that Waterfall does not fit projects currently in flight, but, again, that would not be Waterfall’s fault. Do not mandate from on high; engage in robust change management and expect the change and benefits to take time.

Misconception: Agile Delivers Only When Ready

In our article’s implementation story an Executive demands delivery on a certain date and an uppity developer says it will come when ready. Agile sets up roadblocks to project completion because Agile does not deliver on certain dates and Waterfall gives certain dates!

This story sets up a false binary dilemma. Agile does indeed tout delivery when ready, but this only plays to the positive. If the project team completes deliverable work earlier than anticipated, they implement earlier. Benefit! And if the work is not ready by a set date, do we really want to implement bugged code?

Flexibility Though Experience

The misconception here centers on a misunderstanding of flexibility. “When ready” is undefined; a hard date is definite. Ergo, Agile cannot make dates! Not true. Agile is built around giving teams the skills to forecast their work better and speed up their delivery. Fore example, a mature Agile team practicing SCRUM will be able to tell you how many sprints into the future they will be able to deliver work because their process is indefinitely stable. Prediction problems manifest mostly in nascent Agile practitioners who do not know enough about working from an Agile perspective or their project teammates to make accurate predictions.

Continuous delivery of valuable software is the hallmark of Agile delivery. “Agile delivers only when ready” is not a mantra; it is an excuse from someone who is not communicating, someone who likely is not practicing Agile.

Mistake: Cherry-picking

I am going to quote the next section of Mr. Hamilton’s article because it succinctly summarizes a big problem that occurred on the initial rollout of Agile at my old company: cherry-picking what you like without understanding the whole methodology.

“The PMO then mandated all projects … now be Agile. Actually, I kind of liked it. It didn’t make any sense … but the old methodology had lots of pointless documentation, whereas you could bend Agile to rationalize … leaner documentation … I would set up tasks to align to 2 week periods, satisfied the criteria for Agile where I needed to, cherry-picked a few things about Agile I liked (e.g. the daily standup), and this gave me the freedom to deliver with minimal overhead.”

This mindset is not unique. Some other cherry-picking I am intimately familiar with because I heard it…or did it.

• “The old way has pointless [fill-in-the-blank] (typically documentation), but Agile advocates lean [documentation] so we will do that!”
• “I’m being forced to work in two week sprints, so I’ll divide what I’ve always done into tasks spread over two weeks. Now I’m Agile!”
• “Daily standups aid communication, so we’ll do those. … For an hour. … And invite everyone. Agility achieved!”

Cherry-picking mistakes stem from inadequate training. Adopting the tools and trappings of an Agile methodology without understanding why they exist is not being Agile, doing Agile, or exhibiting Agility. Calling your bloated all-hands status meeting a Scrum of Scrums and claiming victory is ignorant malfeasance.

---

---

Beware accessories

The Agile Manifesto lays out four values statements and 12 principles of Agile. All the ceremonies, tricks, and tips (Scrum, Kanban, XP, etc.) basically everything else is an idiosyncratic embodiment of the values and principles that may or may not work for you or your company. Maybe SAFe fits your organization. Maybe DAD will aid your organization more. It does not matter which is better; just do not confuse a practice or a strategy with the methodology.

---

---

Good Faith Effort

Back to our cherry-picked “improvements”:

1. Is your documentation simple to the point that it is “maximizing the amount of work not done?” (Agile Principle #10) Are you focusing on documentation over delivering work? (Agile Value #2) If not or you are, cut the wasted documents.
2. Do sprints allow you to “Deliver [work] frequently,” (Principle #3) which is “the primary measure of progress?” (Principle #7) If not, are you using sprints to make and meet commitments or just to do your thing with ‘minimal overhead?’
3. Do standups enable the “most efficient and effective method of conveying information [a] face-to-face conversation?” (Principle #6) If so, use it. If not, what will?

When the values and principles of Agile are not learned and understood, you do not have a way to measure progress. I personally hate documentation. I crusade against documentation because most organizations over document as a result of bureaucratic age and inertia or as a result of poor communication lines. Those problems can be solved without Agile. Yet they can only be solved if you understand you have a problem (documentation), understand what the solution you are adopting (i.e. Agile) will do in regards to that problem (focus on simplicity), and adopt the solution in good faith. An Agile methodology might result in MORE documentation if doing so aids simplicity or efficiency elsewhere. But only through trying something in good faith can you realize any benefits.

Misconception: Agile Works for Software Development, Not Other Business Functions

Agile was originally conceptualized to improve software delivery. In fact, the Agile Manifesto I linked to above still refers to software. So it is understandable to misconstrue Agile as only a software thing. After all, how do you make finance, communications, marketing, training, human resources, etc. Agile? Answer: Iteratively.

Agile focuses on delivering value as fast as sustainably possible. Are you revamping your staff onboarding process? Why wait six months to complete everything if you can start sending out a better acceptance letter tomorrow? That end of the year financial summary needs a retool. Why perfect the whole thing if you can update the one report everyone uses most first and build from there?

Maybe First, But Not Last and Always

In addition to misidentifying Agile as only a software thing, the misconception that Agile does not align with other business functions often stems from the fact that development typically adopts Agile first. Agile will look different in the trenches for Training and Marketing than Development because Training and Marketing are different than Development. Aligning across business functions is about communication and collaboration, both methodologically agnostic.

Think about other improvement methodologies. Kaizen was most famously developed to improve manufacturing on the Toyota assembly line. However, the broader, universally applicable principles and ideas of (Lean) Kaizen can be applied to a whole range of industries, tasks, and processes. Agile is similar.

Agile came from software but it does not have to stay there. Interactions over processes, collaboration over negotiation, responding to change, these are ideas that can add value across all business units in an enterprise.

Mistake: Engaging on False Case Studies

People love to speculate and debate about what might have been. Count me as one of them. Skeptics to change often point to case studies — both inside and outside the organization — to debate the merits of change. When this leads to instruction and improvements directly applicable to the work ahead, great. When it causes a rehash of unique past issues, time is wasted and relationships imperiled.  Do not engage false case studies.

A perfect example of a case study you should probably never use: Healthcare.gov. Healthcare.gov can prove basically anything. A massive undertaking, with endless opportunities for spin for supporters and detractors, it illustrates why we should avoid speculative case studies. Authorized by the Affordable Care Act, Healthcare.gov is a political landmine which mentioning or discussing even today often results in discussing provisions, positions, and actions motivated by political ideologies that have nothing to do with a functional website. Read enough about the implementation of Healthcare.gov and you can support almost any position you want.

Can the implementation of Healthcare.gov teach better implementation? Sure, when used right.  But it is not going to help in a discussion over the value of retrospectives.

Improve for Next Time, Not Last Time

Rolling out a new methodology is going to have detractors. Do not let yourself get bogged down in speculative arguments that do not discuss the merits/demerits of the methodology. The claim that this or that project should have used this or that methodology, because issues would have been exposed earlier or the budget spend would have been smaller is counterfactual. Every methodology has blind spots and flaws. Claiming one may have (blank) when another did not (blank), cannot be proven and does not matter anyway. Stop focusing on case study specifics and instead talk about what is generally instructive for the future.

Summary: Be Curious About Change

This article is by no means an exhaustive list of the mistakes or misconceptions I made or had about Agile. All of them, however:

• Mistake: Mandating from on High
• Misconception: Agile Delivers Only When Ready
• Mistake: Cherry-picking
• Misconception: Agile Works for Software Development, Not Other Business Functions
• Mistake: Engaging on False Case Studies

Share one trait. These adopting agile misconceptions happen when you do not remain curious and open to change. Everything new has something to teach, seek it out.

And tell me why Agile doesn’t work for large projects. I honestly want to know.