When NOT to Use Agile

When HealthCare.gov first rolled out, everyone experienced how terribly it was built. Many Agile enthusiasts cried out, “If only they had used Agile…!” We have since learned that HealthCare.gov used Scrum. It’s uncertain how superficial their adoption was. Michael Daconta has already done a great job describing their poor use of Agile methods in the GCN blog, and NPR has published findings from the McKinsley & Co. consultants who were brought on in March to do a progress report.

My focus here is not about the degree to which Agile was or was not properly used for HealthCare.gov. My focus is to debate under what circumstances, if any, Agile will not work. When would you NOT use Agile?
My assumptions for this debate are as follows:

1. Agile is any processes, practices, tools, and frameworks that comply with the Agile Manifesto and its 12 Principles.
2. In the spirit of healthy debate, I assume the audience to be open to the possibility of new and different ways of doing things. This applies particularly to both Agile skeptics and to those entrenched in a specific Agile approach.
3. The ideas in this discussion are not etched in stone. I encourage you to share your own ideas so we can learn and grow together.

Possible Agile Risks

I was recently invited to an introductory Agile presentation. The audience was Project Managers with varying Agile knowledge and experience. It facilitated a conversation for answering questions and resolving concerns around Agile adoption. About halfway through, there was a slide that had five “Possible Agile Risks”:

1. Business or management commitment
   • Agile requires an increased level of commitment from the business and IT management to be successful
2. Remote or distributed teams
   • Agile benefits from close collaboration on a consistent basis. Distributed teams pose a challenge in the effort to do this effectively
3. Remote product owners
   • The business must be consistently involved, so a remote product owner may be challenging to engage
4. Balance delivering new features with high-quality, sustainable code
   • Agile delivers new features frequently, but this should never come at the expense of creating low quality code
5. Team not provided adequate guidance as they implement Agile
   • Anything new will take time to get good at, it is important to supply the team with training and guidance so they can improve quickly

This disclaimer followed these risks: “These risks do not preclude teams from applying Agile; they just need to be addressed in the scenarios they are present.”

Before we get to my reaction, let’s walk through these risks. Let’s identify why they’re risky in an Agile environment.

Business or Management Commitment

A deep understanding of the business is essential to the success of the software that supports it. In Agile methodologies, this means a dedicated person who has a deep understanding of the customer’s needs, often called a “Product Owner”. Traditionally, this person is seen as “from the business side”. However, getting someone from the “business side” isn’t always possible and is, arguably, unnecessary.

In my area we have Business Analysts who understand the business needs. They are bilingual in business and IT speech. Our developers and testers have a deep business understanding of the business because they’ve been supporting it for a long time. Some Agile practitioners feel the Product Owner role is unnecessary; they believe the team should understand the customers’ needs better than anyone. The team can, therefore, manage the work themselves.

In Agile, management is not a clearly defined position. Managers may feel their job is threatened by a “self-managing” team. A manager must have the team’s best interests at heart. They must become Lean-Thinking Servant Leaders, not Command-and-Control Managers. This is a cultural shift from Waterfall. Agile teams without Servant Leader management will plateau until they are allowed to “self manage”. However, that doesn’t mean they can’t find some measure of success.

Remote or Distributed Teams

This is one of the first and most frequent challenges brought up when introducing Agile. A team is distributed when its members are not capable of frequent face-to-face conversation. Lack of co-location for an Agile team is a challenge, no question. However, modern tools such as IM-enabled ad-hoc video conferencing, digital code review tools, etc. make long-distance coordination much simpler. It may be hard to work out timing with time-zone differences, but it’s possible to have a time overlap for some real-time collaboration. This may result in having a tech lead that takes the brunt of the development’s complexity to reduce the need for collaboration among the other team members, though this will limit the team’s overall productivity.

Remote Product Owners

For this I say, “See my previous 2 sections.” However, perhaps there are situations where the team is new to the product? Perhaps the SMEs are remote? Even worse, what if those remote SMEs do not dedicate time to work with the development team? Wait, what on earth are you thinking? Seriously, this is a bad idea, regardless of methodology. You are stacking the deck against yourself and setting the team up to fail.

Balance New Features with Quality Code

One of the 12 Agile Principles states, “Continuous attention to technical excellence and good design enhances agility.” Delivering new features at the expense of quality is the technical equivalent of being “penny wise, pound foolish”. This may be faster short-term, but the long-term consequences are a slow-down of delivery. Without addressing the quality of the application, it will eventually be cheaper to replace the application than to fix it. This isn’t unique to Agile. This brings me to my initial reaction to ‘Possible Agile Risks’.

My reaction to "Possible Agile Risks"

When I first saw this list, my reaction was that the first four are not “Possible Agile Risks”. Instead, they are “Possible Software Development Risks”! The four risks of commitment, distributed teams, remote product owners, and quality are often associated with Agile development because Agile brings risks to light early. Agile makes it much more painful to ignore risks than to address them. They are not less risky with non-Agile approaches. In fact, the realization of these risks is more likely in a non-Agile approach. In Waterfall projects, risks manifest so late in the process that they are painful and expensive to fix. The first four are risks to all projects; but not necessarily the fifth and final risk on the list.

Agile Training and Guidance

Without proper training and guidance, it is difficult for those unfamiliar with the Agile paradigm to be successful with an Agile approach. Most people new to Software Development find the Agile way of thinking to be a more intuitive and human-centered. In those cases, there is less risk because less training is needed.

Those entrenched with Waterfall approaches will find it difficult to switch gears. This is the only risk I could concede as being a “Potential Agile Risk”.

Where’s the Risk?

So there are my thoughts on five risks commonly thought to make Agile less successful. I have yet to find a risk that is made any less risky by Waterfall. Does that mean Agile’s guaranteed to succeed? Absolutely not. In fact, Agile will push you to your limits. Then, right as you’re starting to feel comfortable, it pushes you some more. However, Agile will consequently turn your team into the best team they can be. Agile will expose risks and inefficiencies sooner. It will also make them more painful. As long as you don’t ignore the pain, taking care of those risks and inefficiencies will be less expensive because they are dealt with early.

But hey, maybe I’m wrong. What risks have you heard associated with Agile? What situations are wholly inappropriate for the basic tenants of the Agile Manifesto?

Taming the Wild West: the Differences between Agile and Cowboy Coding

One of the strongest arguments for Agile is that it’s not Waterfall. However, not everything that isn't Waterfall is Agile, a fact that’s not always understood. This misunderstanding hurts the Agile brand when people familiar with only Waterfall begin associating all other methodologies, including a lack thereof, as Agile. I want to be very clear about this: Agile is not Cowboy Coding, and Cowboy Coding is not unique to Agile teams. It is important both to understand how Agile and Cowboy Coding are different and what Cowboy Coding looks like so that you can identify it on your teams (yes, even Waterfall teams).

The Loner

One of the easiest signs of a Cowboy Coder is that he’s a loner. He may be working under the name of Agile, but there are no Agile methodologies or frameworks I’m aware of that support such behavior. In fact, the backing principles of the Agile Manifesto state, “Business people and developers must work together daily throughout the project”; “Build projects around motivated individuals”; “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”; “The best architectures, requirements, and designs emerge from self-organizing teams”; and “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” The manifesto, its principles, and all Agile methodologies and frameworks I know of are very human-centered with an emphasis on collaboration.

If you have a loner on your team that insists on working in a silo, there’s a possibility that you have a cowboy in your midst. Try to rein them in using mandatory meeting/ceremonies that promote meaningful conversations and practices like Pair Programming. If they absolutely refuse then you will likely end up spending considerable time managing the work around them – holding ad hoc conversations, formal code reviews, knowledge transfer workshops, etc. – with diminishing returns.

Straight to Production

Working directly with Production code or with a source code repository that isn't versioned is a bad idea. Don’t get me wrong, I love Continuous Delivery and working off the trunk, but a software development team must be very mature and disciplined to make this work. They use feature toggles and branching by abstraction to protect code that isn’t ready for Production. They build test suites around the code so that each commit is verified against regression. They do their due diligence to make sure that a change isn't going to blow up if it’s pushed to Production. Cowboys, simply put, don’t.

If you find yourself consistently in a situation where the same person or people are making changes directly to Production without due diligence then you might just be working with Cowboys. Have them read up on DevOps and Continuous Delivery so they can learn the right way to get changes to Production quickly. Emergency situations that require quick, non-vetted changes to Production should be avoided at all costs.

Wastes of Time

The Cowboy will often refer to Testing and Documentation as a waste of time. They may even commit the cardinal sin of Agile, reciting the Manifesto blasphemously: “‘Working software is the primary measure of progress’; anything else is just a waste of time!” To those people, I would ask them to define “working”. Does it pass the Acceptance Criteria associated to the work (or did you even bother to ensure you had Acceptance Criteria)? Can anybody actually use it, or is it too buggy or complex? Is anyone other than yourself aware of the assumptions made around input, output, workflow, etc.?

Without proper testing and documentation, you can’t prove your software works nor can anybody understand how it works. With that being said, if your tests and documentation don’t contribute to the value and usability of the software then they are, in fact, a waste of time. Focus your testing efforts on tests that actually stand a chance of failing and finding vulnerabilities. Don’t spin your wheels creating “write-only” documentation. This is the approach that Agile espouses; anyone who says tests and documentation are altogether useless is operating with a Cowboy mindset, not an Agile one.

“Emergent Architecture”

One of the backing principles to the Agile Manifesto states “The best architectures, requirements, and designs emerge from self-organizing teams”. There are those who believe this means “just make it up as you go.” That’s not entirely accurate. There still needs to be intelligent design, and that design needs to make the software as easy to comprehend and maintain as possible. As another principle clarifies, “Continuous attention to technical excellence and good design enhances agility.” This means having a thorough understanding of the latest design patterns and practices. It means taking the time to refactor working code into something better. It means taking a little bit of time up-front to design what you think will work and adjusting as you go.

Agile developers do not shoot from the hip. They take pride in their applications; they have a sense of ownership. They will throw research spikes, read books, build proofs-of-concept, attend conferences – do what it takes to build the right thing in the right way. You’ll spot a Cowboy by their purposeful lack of direction, sticking code wherever they please with the sole purpose of “getting something to work” so they can move on to the next thing. If they do it in the name of “emergent architecture” then call shenanigans. That’s not architecture, it’s just reckless.

Somewhere to Hang their Hat

The good news is that cowboys can be tamed if they can come to appreciate the practices, tools, and frameworks that Agile provides. Cowboys won’t jump on the bandwagon just for the heck of it. There will always be some that refuse to be tamed, but many will see the benefits and forsake their wandering ways once you give them a safe place to hang their hat.

One of the great things about reformed Cowboys is they are used to developing quickly and cross-functionally. If you arm them with XP practices, Agile tools, a Kaizen mindset, and continued training and development, they can become model developers that contribute quality software time after time.

Just don’t make the mistake of trying to get them to do something for which there is no tangible benefit. They don’t take too kindly to that.

Understanding the “Why?”

"Would you tell me, please, which way I ought to go from here?"
"That depends a good deal on where you want to get to," said the Cat.
"I don't much care where –" said Alice.
"Then it doesn't matter which way you go," said the Cat.
"– so long as I get somewhere," Alice added as an explanation.
"Oh, you're sure to do that," said the Cat, "if you only walk long enough."

I've written a couple of blog posts on understanding the principles of Agile, the “book version”, as it were, in order to achieve the success that is associated with Agile. If you've been in the Agile arena for any significant amount of time, you know there are a lot of disagreements as to the “How” of Agile. There are many different methodologies, frameworks, tools, and practices out there to support Agile teams. Some believe this is because people simply disagree on how to best implement Agile and, in some cases, this is true. Others understand Agile was never intended to be “One Size Fits All”. There are many options because there are many teams and each team must determine what solution works best for them – and evolve that solution over time in the spirit of Continuous Improvement.

This means you cannot determine “How” you want to implement Agile until you understand the needs of the team. “We need to have a Daily Scrum.” Why? If you can’t answer this then it’s not going to bring as much benefit as it should. If you understand the Daily Scrum as a touch-point to align across team members; identify risks and dependencies the team is encountering; and jump-start communication that will occur throughout the day then it becomes a stale and stagnant status update meeting.

My recommendation to Agile teams, and all human beings for that matter, is to not adopt something without understanding the “Why?” behind it. True Agile teams do not do things for the sake of doing them. They do them for a reason and nothing is sacred; if a tool or practice outlives its usefulness then it must be “put out to pasture” so as to not get in the way of the team’s continued growth. By regularly re-evaluating the usefulness of your current implementation, you also get the benefit of being open to new things. No matter how good your team is, they will never be as good as the team they could be.

Agile: The Book vs. The Movie

I’ll be the first to admit that I’m a pretty big bookworm. I also love to go to the movies, which is less and less frequently now with young children at home. It’s an all too often occurrence for me to read a book and, as I see the images play out in my mind, think, “This would make a great movie!” Of course, that sentiment occasionally becomes reality and I find myself leaving the theater thinking, “The book was so much better than the movie!” The movie may even be good. It may be the best movie I see that year. But the book is invariably better.

I see teams, both inside my company and out, that struggle with making Agile work. Too often they get some basic knowledge, get really excited, and start forging onward without taking the time to continually research Agile best practices and innovations. It’s a stripped-down version of Agile, usually built on the roles and ceremonies only and not the principles on which Agile is founded. They’re taking all the action, but cutting out sub-plots and character development. It’s the movie version of Agile.

Over the past year, I’ve had several people express how impressed they are with how “by-the-book” my area is running Agile. And it’s true; we stay very true to the published recommendations that are widely accepted by the industry. We’re able to do this because the team has changed the way they approach software development. They have changed their mindset to one that aligns with Lean and Agile principles. They are flexible and embrace change because they know if something doesn’t work they can dump it after 2 weeks when the Sprint ends. This paradigm shift is essential for teams to be successful with Agile. It’s also the Scrum Master’s greatest challenge.

A team can run Scrum without a dedicated Scrum Master, but they are largely secretarial. They ensure the ceremonies are held and time-boxes are respected, but not much else. A dedicated Scrum Master is also a mentor and coach, with much of their time spent removing impediments; resolving conflict, hopefully in a productive way that results in learning and compromise; evangelizing Lean and Agile principles; and advocating XP and other technical excellence practices. This helps the team obtain and retain their “High Performing” status indefinitely. This is all made possible not in spite of all the change that is inherent in Agile, but because of it.

When it comes to Agile, I’ve “read the book” and “seen the movie” and, as with all other cases, the book provides a much richer experience. It might take longer to get through; it might take some imagination; and you might have to read it more than once. But the book is invariably better.