Developing Custom Software – Transitioning From Waterfall To SCRUM Midway

At BluEnt, we work with a wide array of projects in different niches as custom mobile app developers. There are so many anecdotal stories that happen when you work with clients all over the world.

This one is from a while ago. We were working with a client for over 12 months. He owned a small business in Toronto. We were working with a small, in-house but talented team, good management and great work environment. Our developers had a good grasp on the technologies and tools which were being used. The late-night work was bearable with good colleagues and an awesome coffee machine in our building.

But, life is not that smooth, is it? Like the age-old circle of life, the problem came bouncing off to us.

So, what was the problem? The problem was, we did not have any specific management platform.

*Cue gasp*

Now, I know this is unbelievable today. Every custom software development partner puts in project management the first thing in a project. But it was nearly a decade ago, and Asana and Basecamp were not dropped by the stork yet.

Every week, these were common sightings within several developmental phases:

• We scheduled in MS Project. Our documents, assigned tasks and roles were included but our team was unable to add any business value.

• We missed deadlines continuously – yes, time zone made a difference, but mostly it was because of a lack of focus. Our developers dropped features, we never did any innovation because all implementations were suggested by the business itself.

• We never gave demonstrations to stakeholders.

Does this remind you of something?

I remember cramming these points for an exam for my Software Development Paper. They are all classic waterfall model problems.

The team decided enough was enough when we missed a crucial milestone. We suggested a change from Waterfall to Scrum methodology. I still remember the project manager's look when he asked if teams could transition midway from one development model to another.

Truth be told, I had no idea. But I knew this for sure, things could not go downhill from here.

So, what did we do? We all spent the next couple of days to train the team on Scrum development objective. Imagine suspending a project which is already running late! There were so many views of several Scrum videos. We revamped all our old projects with Scrum templates. Most of our unfinished requirements were converted to user case and we organized them into the product backlog.

Did it help?

Nearly 10 days after the fiasco, we had our first sprint. The team was immediately aware of the newfound focus and it came as a pleasant relief.

During quiet contemplation, we found that the team worked mostly towards secondary features but now we could our focus on high priority tasks. By the end of the first sprint, we had something which we never had before – measurable progress.

Honestly, the team thrived on the scrum transition. We were able to achieve every milestone of the project with a couple of sprints and came up with a software which provided business value.

The most unexpected outcome was how much the client liked Scrum. One of the team members told me that although he did not fully understand what Scrum was, he could feel the change. They also noticed that the sprints now made their interactions with our team more meaningful. He was happy that the development was now taking place the way it would add value to the business.

Key takeaways?

• The overall communication improved drastically. Longer, unnecessary meetings were now productive sprints. We had more meaningful interactions with the stakeholders. We could demo the current development progress. An effective minute of meeting email communicated the key points that were discussed and what encompassed the next milestones.

• We were earlier fearful that transitioning to scrum midway would reduce the planning time. However, with more productive and focused efforts, we did not reduce our planning time and achieved significant results with detailed structures.

• Contrary to popular belief, we all learned that a development methodology has a major impact on the overall project.

When you want to work with a technology partner, think about your project. Look for every area which needs improvement. Pick a process which is efficient. Every project is different as is every development team. With our experience, we can help your project requirements for solutions that add value to the business.

Maximum Value. Achieved.