Inside our Agile transformation

Image for post
Image for post

A company I previously worked for made the transition to Agile from what we called rapid application development (RAD) but was neither RAD, waterfall, nor Agile. It was a hodgepodge of people chaotically running around trying to get things done with no real guidance on how to do them. Through conversations with peers, discussions with clients, and our own research, we learned about the “new” hotness that is known as Agile. We decided to give it a try because our longstanding development process was simply not working.

What we were trying to fix

Because we touted that we were using RAD, requirements were usually lacking. I often use the analogy, the business wants us to build them a house, but they don’t know what square-footage, how many bedrooms and bathrooms they want, does it have a garage, what side of town it will be on, and how much should it cost? Getting clarity on requirements was often a long and grueling process that happened after development was already 50%, sometimes even 80% complete. This misalignment often led to a lot of rework and confusion as requirements inevitably changed. To make matters worse, the development team was never on the same page, because we each had to figure out how our part of the application should work ad-hoc. The result was an almost complete lack of collaboration on development efforts, which, in turn, led to inconsistencies in implementation. There was no cohesiveness in the codebase, which led to wildly-varying degrees of code quality. There was always a large number of bugs, and release cycles ranged from 3 to 9 months with weeks of hotfixes ensuing.

Our struggles along the way

Almost everyone was in agreement that we needed to improve our development process. But agreeing to a change and actually executing a cohesive development strategy are two different things. In the beginning, there was resistance mostly from the business side of the house. We had been doing things the same way for so long that it was scary to think of changing. If they decided to invest in a feature, they knew how long it would take and what the potential impact would be of other things in the pipeline. Risking changing that to something unknown and incomprehensible was terrifying. It was clear that in order to get off the ground with Agile, we would need to make it clear and explicit how all of the pieces of our current methodology would fit into Agile. The most difficult part was convincing everyone that some of the pieces were no longer relevant.

We discussed in length how requirements gathering, development, QA, and smoke testing would fit into a two-week sprint. For some, it was hard to believe that we could develop features in two-week intervals and have the code ready for production without risking our deployments. Previously, we had always braced ourselves for putting out fires after each code release to production. It was like preparing to launch a rocket into outer space.

Furthermore, we, the developers, didn’t know how to work as a team. We were used to working in silos, responsible only for our assigned features. We had to figure out how to self-organize as cross-functional teams to break up the work into two-week sprint cycles. The process proved to be difficult as more resistance materialized along the way.

It was during this part of the transition that developers began to feel anxious. Many questions were posed with regard to people’s’ roles with this paradigm shift. This was a very valid concern that needed to be addressed head on. When people start to fear for their job, they turn hostile and will resist with full force. The reality is, just because the development methodology changes doesn’t mean that you need fewer developers. Everyone brings something to the table. One thing that became very evident during this transition, was that people who flew under the radar before, now had a spotlight on them. Agile enables performance-based tracking, and with the use of Kanban or Scrum boards, it is very obvious who is doing what work and at what level of quality.

Our first sprint

After the convincing phase was over and everyone was ready to roll up their sleeves, we ran our first sprint. We intentionally ran it very light to prove it could be successful. We knew we would have enough problems on our hands making sure all the theory we had discussed would unfold the way we’d planned.

We decided to start our first sprint right after a major release. We had released about three weeks prior, handled the umpteen hotfixes we had to push out to put out the fires, and started the sprint once things had calmed down. After all that pain, it seemed like the perfect time to transition.

During this sprint, our resolve was tested. More hotfixes had rolled in, and how we handled them would dictate whether we would be successful in implementing agile. With pressure from the business asking for hotfixes, it became very evident that we needed to define what a hotfix was, and what could wait the week and a half we needed to officially close the sprint. This was a hurdle, but not one as large as those we had to overcome to get the process off the ground. We handled it in stride, moving features out of the current sprint to make room for hotfixes. We did not let the need to switch gears deter us from executing our plan.

After the sprint, we held both the sprint review and sprint retrospective meetings. These were critical meetings for the team’s understanding of what had transpired, and for discussing ways to improve any kinks in the process. After a couple more sprints, the business teams had forgotten how we used to do things before Agile. We were able to convince them to start using new software to manage the projects. Using velocity and burndown charts, the product team had radically changed the way they thought about feature development, and were delighted in their newfound speed to market.

We reaped the benefits

We ran several more sprints and continued to improve the process and our team relationships. After three months, Agile was just how we did things, and we were reaping the benefits of the new development process. We saw a huge increase in morale from all stakeholders. Development, QA, and product were all ecstatic about how smooth and easy it was to roll out new software. Gone were the days of the nit-picky QA vs development battles; we were now a single team driving success for the business. Developers were now collaborating on implementation details, each thrilled about learning and sharing their newfound knowledge with the team. We were learning things like architectural patterns and SOLID design principles, and how to apply them consistently across the codebase. We could finally collaborate with the operations and service departments to gather client feedback and pipe it into our sprint planning and feature development meetings.

Perhaps the most important benefit for the company was that development efforts could now be accurately estimated. The product team could ask for an estimate and have a realistic expectation of when the feature will be delivered. This allowed the business to accurately set client expectations on software delivery. Furthermore, the expense of testing new features was significantly reduced, and changes in requirements could now be more effectively accommodated.

The keys to success

Our road to implementing agile was long and bumpy, and filled with peril. However, below are some of the key points that ultimately made it a success.

Explain the process

In preparation for the transition, it was critical to thoroughly explain the process to all stakeholders at least several times. The key was to ensure everyone, especially leadership, understood the process as a whole. Simply touting the benefits wasn’t enough. People needed to understand how we would achieve our business goals.

The key was to ensure everyone, especially leadership, understood the process as a whole.

Once people began to understand the process, they were able to help explain it to others. It became more of a grassroots movement, which is much more effective than a top-down approach where you demand people do tasks.

Lead the change

Changing the development methodology is a large undertaking, one that needs a dedicated leader. There is a lot of work that needs to be done as people are figuring out their roles in the new paradigm. Navigating the nuances of the change is difficult and must be handled with great care.

As the transition began, there were a lot of responsibilities that were not picked up by members of the team. People simply did not know where they fit in. Even with traditional Agile roles defined, people didn’t fully understand what their responsibilities were. After all, this was a completely new way of doing things. As the leader of the change, it was my responsibility to fill the gaps as people learned the process. This meant filling multiple roles and taking on additional responsibilities. Leading by example was the only way to succeed.

Leading by example was the only way to succeed.

Listen to the team

As the transition to Agile began, there was a plethora of feedback from the team. Some of it was positive, a lot of it was not, but all of it was important.

It was crucial to listen to the feedback from the team, solicited or otherwise, in order to keep the transition’s momentum. Introducing a new way of working turns people’s’ worlds upside down, and they are very eager to get things stable again. Feedback came not only from sprint retrospectives, but also from casual conversations. Incorporating team feedback in the process transition was one of the keys to success.

Incorporating team feedback in the process transition was one of the keys to success.

People want to succeed, and they want to feel like their contributions make a difference. Listening to people and taking their words seriously is one of the easiest ways to show that their contributions are meaningful.

Remain steadfast in the pursuit

Early on, the team voiced concerns about the rigidity of Agile. The product and development teams didn’t understand the concept of moving backlog items out of one sprint and prioritizing them to the top of the following sprint. This made it difficult to explain how we could tackle epic-sized user stories in a two-week sprint cycle. Ironically, this is exactly where Agile shines. One of its major benefits is that it allows for ultimate agility in software development.

Even after meeting and discussing this very concept time and again, it remained a sticking point. In hindsight, I’m certain it was because of the years of mistrust between product and development teams. Neither believed we could work together to achieve such flexibility. Pushing past this deep-seated mistrust was imperative to achieving the goals we’d laid out in the beginning of the transition.

Pushing past this deep-seated mistrust was imperative to achieving the goals we’d laid out in the beginning of the transition.

It was worth it

Although it didn’t come easy, the benefits of implementing Agile far exceeded the pain of dealing with obstacles along the way. The company’s development process matured to new heights, the business acquired a new understanding of implementing positive process change, and leadership learned how to build bridges that enabled inter-departmental collaboration. It became apparent who could be trusted with the company’s most critical initiatives.

Simply put, the company had evolved.

If you enjoyed the read, please click the green heart and share on your favorite social media!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store