Get certified - Transform your world of work today


Success Story: Sailing Through the Perfect Storm with Scrum

22 April 2014

The journey

A high-profile software development project supporting a critical business imperative had been sitting on the shelf for a few months. It was awaiting a new crew to take ownership and successfully sail it to its destination.

All is calm

My crew did a quick outward assessment of the project, and all the assumptions in our sailing plan checked out fine:
A proof of concept had been completed, which had apparently delighted users.
The requirements were supposedly mostly complete.
There was a straightforward development platform with a short learning curve for a new team, which we were told should easily support all the remaining business requirements.
It was low in complexity -- after all, the business was committed delivery in three short months at an unimaginably low cost for an IT project.
There were committed users.

What could be better in terms of a quick win for our team and the IT organization! It was the perfect day for my crew and I to sail.

The navigational course is charted

We picked the project up from where it had been left off. With so much "known" in the project, Waterfall was selected as the best-suited development method. We timeboxed all the project activities -- the requirements sessions were laid out on the project plan; the remaining time was fixed for development, followed by testing and then UAT working toward a production deployment; the project plan (MPP) was created, locked down, and communicated widely. The business excitement grew as this initiative was reignited and a plan was now in place to deliver.

Great start! So, we set sail!

Early run into troubled waters

Our goal was to start with a quick validation of the existing requirements, followed by documentation of the remaining functional requirements.

We encountered our first high waves. Our users did not want to retread requirements; they did not have the "time" we thought was available. Committed? Yes, they were, but not with time for IT -- business priorities superseded.

They were led to believe that the POC was complete and all those requirements were understood, and we would be building the product without further conversations around requirements. The requirements now had to be validated with nine stakeholder groups, versus the one primary stakeholder whom we expected would represent all project requirements. Building consensus required a separate effort unto itself. Scheduling meetings grew into a nightmare with this large group.

As we started gathering and documenting requirements, the proverbial devil in the details was quickly realized. As the documented requirements' complexity grew, we could only guess against product manuals as to whether the product could support the requirements satisfactorily. Paper documentation was our basis. The expectations were changing. The requirements were morphing. The clashes between "change requests" and expectations and the ensuing project management processes became more frequent.

We were now heading into high and dangerous waters.

In deep trouble

We were stuck. We couldn't move forward. We couldn't proceed to development until each and every requirement was documented and signed off, the scope locked down with all the signatories, and the process toll gate for requirements crossed -- after all, that's what our method prescribed.


Stakeholder frustration was at its highest! This had escalated to project sponsorship and leadership frustration. Their available time and patience for us all but dried up. They feared our project commitments were lost, our understanding of the business needs to build the product were in question. Our team's morale had sunk; the ship had all but capsized. Most of our project assumptions from the precheck "Boat Log" had failed by this point in the project.

Implementing a course change: Mind-set transformation from Waterfall to Scrum

We had no choice but to rethink the way forward in a serious manner. The path we were on was not one to consider anymore. Despite the setbacks, at the back of our minds we were confident that we knew what had to be delivered -- we just had to find our way out of this stormy patch and start sailing again.

We changed tactics and adopted Agile, specifically Scrum. Converting from the MPP and iterations to sprints and from requirements to backlog, transforming terminology and introducing new ones -- this was how users perceived this, as yet another IT fad! That was their mind-set by this stage, as you might guess.

To put words into action, to prove the method (after asking for forgiveness, of course), we decided to stop the requirements process and build product per all the available requirements to date, with assumptions where there were gaps but without going back to the users. We changed our mind-set from order takers to trusted advisors!

We translated the Agile process to our users as a series of quick show-and-tell events, with a week or so in between, and we would validate their requirements based on working product and not paper documentation. We would incorporate changes into the product after each show-and-tell and iterate until the product was satisfactory to them.
This change seemed to be working. We saw hope that we might sail out of the choppy seas. We gradually instituted more practical Agile and Scrum strategies:
We started validating what we built with the users frequently, to ensure that we stayed on course with expectations (sprint reviews).
We ensured that our development and testing teams met frequently to so that all team members were at all times on the same page with the course we were on (daily Scrum calls).
We started managing a prioritized list of features, reviewed frequently. This allowed us to make up lost time and focus on what the business required most to get a product out the door for usage (release backlog and sprint backlog).
We created working software as we went along -- ready to ship and use by the users.
We were responding to changes much faster than we had before (sprint planning).
Consensus building was easier based on using a working product for reference versus a paper-based requirements (sprint review).
Our collaboration with the users became more engaged -- show-and-tell makes for more engaging conversations.
We were able to better inform our users about the capabilities of the technology platform and hence adapt the requirements accordingly to avoid as much custom development as possible. This led to lower maintenance costs over the long term and would make our future upgrades smoother.

Back on course and sailing smoothly

The trust in the business and IT teams grew; the team and its interactions were now being valued. We were actually pleased that the "actual" user groups were involved -- the fear of multiple groups to work with had disappeared. We welcomed all the feedback; we realized that the earlier the feedback, the better for us -- versus learning about problems in production, when it would be too late.

Overall, the teams started working much better together. Sailing to our destination smoothly finally became a reality! We were delivering. Our users were finally delighted, the feedback was positive, we did multiple production deployments. Beta testing with pilot groups in production was instituted to gain truly valuable production usage feedback to inform the development of the remaining features and solidify what had been built to date. The pressure on the entire team was reduced, as the results were speaking for themselves.

Reviewing our sailing log

The Scrum method led to improved teamwork, better communication, faster results, production quality that met expectations, and lowered overall costs (although costs were nonetheless greater than original cost expectations set before the project started). More important, we were able to manage business expectations throughout the course of the project, reducing surprises later on.

The key signs we should have taken heed of when we first set sail:
  New technology for the team and related unknowns
  Unclear requirements
  Multiple stakeholder groups
  Complexity of requirements -- fear of the unknown

This would have led us to select the right techniques to deliver the project at the onset -- or, in other words, our sailing plan would have been much different. In hindsight, Agile/Scrum mitigated a lot of the rough sailing we experienced.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.7 (11 ratings)


Carlos Monroy Nieblas, CSM, 4/22/2014 11:51:36 PM
This scenario is so familiar with many "small" and "easy" projects. There seems to be an eagerness for some stakeholders to perceive all the needs with too much optimism that sometimes they can become blind or lose objectivity while evaluating the work.
Jason Martinez, CEC,CSP,CSM,CSPO, 4/24/2014 8:20:19 AM
Great job Rahul and Saugata, this was one of the most pragmatic teams that I worked with when it came to adopting scrum tactics and it appears the iterative and incremental approach to adopting the latest "IT fad" as dubbed by your stakeholders ended up providing business value for your team and stakeholders. I feel proud to have worked with such a great team who has come such a long way in such a short period of time. 9 stakeholder groups is a lot of people to come to alignment and prioritization... bravo.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up