From Waterfall to Agile….. slowly

Other the years, I’ve worked with a few different development methodologies. Previously, I was working in scrummerfall. This means that we had two week sprints, tracked story points, effort, allocation, tasked out user stories, etc. But it wasn’t always easy to correct flawed design, and integration did not happen on a regular basis. Instead we’d end up with branches where things were fixed, and then spent months waiting to be part of an official release.

That was the most painful part of the process for me. If I fix a production bug impacting even one user, I don’t want it just sitting around somewhere waiting for a release. I want it released as soon as the fix is properly verified. Every time that your users run into a known bug in production their confidence in your product and their trust in you is diminished. Telling them that you’ve fixed the bug and it will be released in two months might keep them from complaining further, but it’s hardly a consolation.

I’d rather go further towards agile. Let’s get those fixes into customers’ hands as soon as possible. I find that’s what I’m working towards now.

I’ve come into a new amazing job working with great people, and I’ve joined the organization at a great time. Things are changing and people are open to change. The development methodology was outdated, but we are rapidly iterating on it and getting better — funny how that works. The pain of not changing is what you might imagine: bugs are not fixed and released quickly, new features are monolithic projects that reside on their own branches, and months later when they are ready to be reintegrated, you better believe there’s going to be merge conflicts. Time better have been scheduled into the project just for resolving merge conflicts or that release date is going to slide into a death march.

Now, all of that is starting to change. These monolithic projects are starting to break down into smaller chunks that can be completed and integrated outside of the projects they were included in. More collaboration is being done in order to see this accomplished. Testing is being improved at a rapid pace. The environment is clearly headed in a direction where contributing is going to be a total joy.

Having branches with smaller scope doesn’t just mean that you see this code integrated into your master branch sooner. It also means that developers branching off of master are more likely to have architecture changes they should be working with instead of needing to duplicate work. Merge conflicts will occur less often, meaning less wasted developer time and more time spent solving problems and writing code. With code being integrated more often into master, you also end up with code that doesn’t sit around under-appreciated in feature branches for months and can instead make it to the customer that much faster.

Heck, my next project is even moving to sprints. I’m going to be leading sprint planning sessions as early as next week. This should increase developer collaboration and help ensure that the proper people involved are thinking about what they are going to need to do before it is too late.

But how did we get to this point?

Well, step one was identifying a set of projects that overlapped in a significant way. These are projects that if completed in a bubble would cause a large number of headaches since similar architectural changes would be needed in both projects. If these were completed without a strong story of collaboration they could have been implemented completely differently. The story of combining these projects and breaking them up into more logical chunks was suggested to the other project lead who decided that it wasn’t a bad idea. Once there was buy in on that level, providing the idea to others in the organization was easy and widely accepted. Not only did the change make logical sense, but as a collaborative decision, the leads were able to both feel like we were part of the decision and got to take ownership over the task.

Step two was identifying that everyone could better track the tasks and logical chunks (user stories?) if we had a collaborative way to organize the projects. This lead to a suggestion and acceptance of sprints and sprint planning. Again, it was a decision made as a group so that all parties feel invested in the success of this project. If it succeeds then we all succeed in helping bring a better methodology to the team. Group success is always better than solo success.

When acting as a catalyst for change, you need to identify the people that are going to back you, those who are skeptical, and those who will not want to change. The skeptics are the important group here since they are the only group that you can sway and could be your strongest supporters in the long run. How do you change the mind of skeptics? I find that the best way is to bring them into the decision. Do not attempt to force process change on anyone. If someone is part of the decision with you then they will get to share in its success and will be pushing for it to succeed. If you force a process change, then they may go along with it grudgingly and never truly enable it to succeed. Apathy is not your friend when trying to bring about change.

That’s it for now. This journey still feels like its just beginning. Any challenges encountered along the way will be shared here to help out anyone else going through the transition of waterfall to agile.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s