Succeeding with Agile in a Waterfall Culture

Introduction

While working as both a developer and a project manager at JBS, I have seen many projects where the customer is looking to move away from a “Waterfall” type of project. At JBS, we’re excited to hear about this, as the Agile approach has been a staple of how we do things since the company’s inception. Many of our projects can be classified as “knowledge work” meaning the requirements are often not clear at the onset and can frequently change during the development process. We learned early that leveraging an Agile approach was a better way to tackle the evolution of requirements during the development process, and the shift to that approach has ultimately resulted in deliverables that are much closer to our clients’ evolving visions.

The Waterfall method mainly refers to projects in which requirements are defined up front, and the development process starts once the requirements have been completed. In essence, requirements first, development second, end product last. Moreover, whereas the Waterfall method can be successful with the right project (i.e., typically those with a well-defined scope that rarely changes), it has mostly yielded unsuccessful results for our customers. The biggest complaint we hear from them is that the end product, which sometimes takes years to develop, does not meet the needs of its end users because those needs have evolved since the beginning of the project. This is why our customers are requesting Agile – they want to try a different approach to ensure that they get something workable upon delivery.

So we’re always happy to hear that the customer is open to trying Agile, but how do we implement an Agile project with a customer who is traditionally used to taking the polar-opposite approach on their projects? It’s a challenge that we’ve had on many projects, and in this post, I will pass along what JBS has learned that has helped convert our Waterfall-minded customers to an Agile mindset.

Break the Mold – In Person

The first step to breaking the mold in a Waterfall culture is simple: Meet as many people face-to-face. JBS is a virtual company, so this hasn’t typically been something that comes easy for us. A great upside to being virtual is the lack of “geographic boundary,” which enables us to pull the best resources from a much larger pool, but it also means that our team is, well, located across the country. That said, it’s worth the effort to get the total team there, meet as many stakeholders as possible, and start preaching Agile. The goal is to establish the foundation for a relationship that will have a much higher level of communication than what your customers have been accustomed to in past projects. By engaging directly with customers, they are given a good reason to remain engaged in the project – which is key to any successful Agile project.

One of our clients was very heavily entrenched in a Waterfall mindset; they were tired of lengthy efforts with projects that delivered results that were far from what their end-users wanted. The process was too slow, and the end product wasn’t good enough. Their documentation process was heavy, and the release process was burdensome. We brought our entire team to the kickoff meeting, and to this client’s credit, many of their people attended as well. It was an excellent opportunity to not only set the tone for the relationship but to give them an in-person overview of what to expect from Agile and answer questions along the way. We were even able to document some early risks that a few people voiced regarding the project. All in all, it was well worth the effort and allowed us to establish the right tone for the project and ease some minds about what an actual Agile project entails.

Give the People What They Want

Now that the customer has laid down the Agile framework, it’s time to start executing. I have found that it’s prudent to keep the momentum from the kickoff meeting and start delivering as quickly as possible. Many Agile projects have a “Sprint 0” – a single first sprint that’s oriented around general setup items – developer environment setups, ramp on existing customer technology, etc. In many instances, it isn’t possible to provide a real Sprint Review that contains “presentable” work – this is understandable considering the nature of Sprint 0 tasks. However, what the team should be doing during Sprint 0 is setting things up so that the team can deliver in Sprint 1. In our experience, the first Sprint Review that contains an actual, presentable application should occur within the first month of the project. It doesn’t have to be pretty – simple functionality will do. But by getting something visible in front of the client, it shows the teams’ commitment to deliver incremental software, and establish the expectation of the client’s participation.

Early demos also force the product owner to work through some growing pains with Agile. On one project, our product owner was extremely hesitant to show the product of our first sprint, mostly out of concern that stakeholders would judge the product negatively, as they were accustomed to seeing products that were much closer to finished. Although we understood these concerns, we were able to convince her to go along with it, arguing that stakeholders would need to eventually understand the idea that incremental delivery means that product is seen as it is being built and not after it’s been completed and that this process naturally enables and encourages feedback (thereby improving the end product). It turns out that her concerns were valid – there were a lot of questions and confusion about what they were seeing (and why it wasn’t done). However, we expected this, and with a few minutes of explanation, we were able to outline why it looked like it did at this point (and not to fear, things will improve). It made for a longer meeting, but eventually, they got the idea, and subsequent meetings were not nearly as long.

Don’t Push Too Hard

At JBS, we do more than develop and deliver software. Delivering a successful application depends on our team getting engaged in our customers’ professional lives and understanding their pain points firsthand. Knowing the problems that the organization faces in general, not just those faced on our particular project, helps us to guide them from a technical standpoint better. Now, this concept isn’t unique to an Agile project – it’s just good business, and promoting the idea that “we’re all in this together” helps to cement the engagement and foster the trust that is needed to convert a client to an Agile believer. Yes, actively educate customers on Agile and have them learn by doing” as early as possible. However, don’t lose sight of the importance of understanding your customer’s culture and history first – and not immediately trying to force them to adapt to an entirely new project management methodology.

“Agile tailoring,” which is the process of creating a workable custom approach for the client that tailors the Agile methodology to their culture, is an excellent means of promoting Agile to a Waterfall-based culture. By tailoring the approach, pitfalls of pushing a concept too hard are avoided (which could result in a loss of support). With one of our customers, we realized that the Sprint Review was terrible on a Friday, so we switched it to Wednesday. We realized that our Sprint planning meetings were better if done immediately after the Scrum instead of in the afternoons when our product owner was likely occupied with other job duties. We switched up the format of our Retrospective several times because we felt that the old format wasn’t eliciting enough of a response from certain participants. These things may seem minor, but they went a long way toward making key stakeholders feel more comfortable with this brand-new methodology. Moreover, increasing the comfort level translates into better adoption.

Always Be Selling (ideas of Transparency and Participation)

As discussed earlier, the idea of transparency as an application is being built is an important one and also a difficult one for Waterfall-minded people to swallow – they are simply not used to voicing opinions and are also hesitant to show “unfinished” work to any stakeholders. However, as we have learned, getting the right feedback means keeping stakeholders engaged, and stakeholder participation yields productive feedback. Transparency is the key to participation and feedback.

Encouraging participation can be tiresome, especially in a culture where everyone is busy and time is short. However, don’t give up the fight – seek and solicit participation and feedback at every turn. With one particular customer, keeping all parties engaged and actively participating was a constant effort from the beginning of the project. We found that the best way to do that was to encourage and empower our product owner to make inroads with his co-workers. We empowered him by periodically doing what we called “dog and pony” shows – demos of the applications to people who weren’t able to get to our regular Sprint Reviews. Yes, it was extra effort on our part, but it resulted in more people understanding what we were accomplishing and how we were doing it. It promoted our product, and by association, people showed more interest in the application and the Agile process.

These are just a few of the things that JBS has learned managing several Agile projects in Waterfall cultures. Although there are many other key components to a successful project, regardless of the project management methodology chosen to run it, establishing trust with the customers and then easing them into the Agile world is the best way to ensure that they will embrace it. Also, quite often, getting a customer to embrace the Agile methodology is a key step in a successful end product.

About the Author
Doug Parker has worked at JBS for fourteen years, spending the first six as a UI/UX and .NET developer before moving to his current role as a Technical Project Manager (beginning in 2010). Doug is well-versed in both project management and Agile concepts and holds PMI Project Management Professional (PMP), PMI Agile Certified Practitioner (ACP), and Certified Scrum Master (CSM) certifications. His technical background provides a strong foundation to translate clients’ ideas into technically-sound applications, and his leadership skills allow him to align developer expertise with customer expectations. Doug has overseen several projects in which he has collaborated closely with clients’ business leaders in order to facilitate a smooth transition to the Agile methodology and a successful project delivery.