Implementing Agile Processes in Traditional Workplaces: A Case Study.
This week's topic: Tips on convincing your coworkers that it's not 2005 and that they should embrace some change in their software delivery.
Transitioning from traditional work methods (looking at you, waterfall) to Agile can feel like learning a new language. The unfamiliar rhythm, terminology, and all of those sometimes redundant meetings can initially be overwhelming. However, the promised benefits of enhanced collaboration, increased productivity, and quicker product delivery make this shift enticing.
I’d like to share an example of our journey into the Agile world at NewRez, a mortgage fintech company I worked at a couple of years back, which was all waterfall all the time up until I joined. I will cover adopting Agile and effective change management, adjusting stakeholder expectations, and empowering our development team.
Let’s dig in.
Encouraging the Development Team to Embrace Agile
The first step in our Agile journey at NewRez was establishing buy-in from our development team. Given the significant shift from their familiar workflows, we approached this with a clear change management strategy. We adopted the WIFM or "what's in it for me" approach, highlighting Agile's benefits to their daily tasks and the flexibility it would provide. They squawked a bit when we asked them for things like sizing work, but things started to change when we established the why and highlighted when we were using them.
Initially, the team perceived Agile's frequent meetings as disruptive, reducing their focus time. But we really gained their buy-in by continuously emphasizing the value of these collaborative practices and showcasing their potential to reduce miscommunication. Over time, the team began to appreciate our new Agile-ish rhythm, noticing the advantages of ongoing communication and immediate problem-solving.
Educating Stakeholders and Managing Expectations
While securing buy-in from the development team was crucial, educating our stakeholders about the changes was equally important. Stakeholders were used to dictating all process aspects, including UI/UX design, even without specific expertise in these areas.
We held dedicated training sessions to explain the Agile philosophy and benefits, emphasizing that it's a team effort involving various experts. We clarified that they wouldn't lose their influence; their input would become part of a more dynamic conversation. Managing their expectations was key to maintaining a healthy, productive relationship between the stakeholders and the development team.
Just to be clear to all of you product folks who might fall into this at times: Roadmaps are cool and all, but I would highly recommend NEVER committing to an ETA unless you’re in lock step with your dev team - have sizing, have a plan, etc. Be sure to bake in change management time as well. Not hitting deadlines DESTROYS your credibility regardless if it’s your fault or it’s on the dev team. Also - don’t differentiate when you do need to talk about deadlines and potential sliding. You’re all one team and moving away from this vibe can be a trust killer with your team.
Leveraging User Stories and Streamlining Product Delivery
Another significant shift was transitioning from long, exhaustive write-ups to user stories with acceptance criteria. While initially met with skepticism, we highlighted that this approach allows for greater flexibility and encourages innovative problem-solving. These clear acceptance criteria sparked a new creative momentum in the team.
Ultimately, Agile's nature of breaking down large projects into smaller tasks can lead to quicker, more frequent product updates and shorter lead times to market/going live. By incorporating metrics tracking and analyzing customer sessions, we were able to continually refine our processes, making our product more responsive and user-centered.
Need some data to share with your friends to move them out of the old school?
Check this out:
The fun part about this data is that it’s super basic - aka, we’re not even touching all the flavors of Agile. If you’ve been in the product/project management world for a while, it’s almost a given you have contributed to a failed initiative stuck in the waterfall world. Hopefully, you’re not too triggered by this one.
Final Thoughts
Our journey to Agile at NewRez was more than a methodology switch—it was a cultural shift involving both our development team and stakeholders. We built a more collaborative, innovative, and user-focused team by strategically managing change, guiding stakeholder expectations, and leveraging Agile's benefits.
Embracing Agile is not just about adopting a new way of working; it's about fostering a mindset of continuous improvement, open communication, and shared responsibility. Organizations can harness Agile's power and drive significant product and process improvements by managing this change effectively.
Share Product Party
Like what you’re reading? Think you have some product manager friends who might benefit from this type of content?
Tell some friends by clicking here and picking your favorite place to promote your favorite newsletters:
This is a great example of how to successfully switch to agile! It’s true is not about changing processes or methods, but the mindset in the organization is what really makes the difference.
I’ll share this post in my company, the image is a great demonstration of the benefits against waterfall.
Great post, Mike!
Great story about changing to Agile! I enjoyed how you compelled the change and got buy-in.