Our Scrum Journey for Custom-Developed Software

‍

We have adopted Scrum for our software development projects for a long time already.

Scrum has been the solution to many problems that we faced when working together with other people, with different roles, different responsibilities, varied interests, and in many cases remotely.

This blog post is not intended to analyze the Scrum methodology as such, nor to present an overview of the existing software development methodologies.

We want to share our implementation journey: advances and setbacks, mistakes and successes, achievements and frustrations that occurred along the way, cause it could probably help you with other implementations that you should be carrying out.

Life before Scrum: really?

Yes, sure! We were used to applying Waterfall, and it is worth saying, with more successes than failures.

As you probably know, the Waterfall methodology—also known as the Waterfall model—is a sequential development process that flows like a waterfall through all phases of a project (analysis, design, development, and testing, for example), with each phase completely wrapping up before the next phase begins.

The Waterfall methodology depends on the belief that all project requirements can be gathered and understood up front. The project manager does their best to get a detailed understanding of the project sponsor’s requirements.

During the design phase, the software developers design a technical solution to the problems set out by the product requirements.

Once the design is complete, technical implementation starts. In this phase, programmers code applications based on project requirements and specifications, with some testing and implementation taking place as well. If significant changes are required during this stage, this may mean going back to the design phase.  

Before a product can be released to customers, testing needs to be done to ensure the product has no errors and all of the requirements have been completed, ensuring a good user experience with the software.

Finally, the final product is deployed to the market or released to customers.

The biggest problem is the lack of clients’ involvement in the design and implementation phases. Nothing is released to clients until the final product is completed, which does not allow to mitigate uncertainty and handle eventual deviations against customer expectations.

This drawback is quite serious as clients often don’t fully know what they want at the front end, opening the door to requests for changes and new features later in the process when they’re harder to accommodate,  can be time-consuming, painful, and costly.

On the other hand, the Waterfall methodology is a straightforward, well-defined project management methodology with a proven track record. Since the requirements are clearly laid out from the beginning, each contributor knows what must be done when, and they can effectively plan their time for the duration of the project.

In addition, the total cost of the project can be accurately estimated, as can the timeline, after the requirements have been defined.

To change or not to change: that was the question

At Switch we have been always looking for innovations, continuous improvement, so we are always keeping an eye on what is happening in the world, even looking at what is happening in the world outside the IT industry.

Thus, in 2013 Scrum appeared, already with a certain maturity, and, according to those who promoted it, it promised to bring the solution to our problems in the development life cycle.

‍

‍

We started by reading every article mentioning Scrum, and we became more and more excited about entering that world.

We internally organize labs and workshops to start to experiment with Scrum.

We found out that early deliveries to clients allow us to control deviations and implement changes needed in the initial stages, making them easier and less expensive.

In addition, constant communication enables information to flow to the entire work team in a comprehensive and orderly manner.

We had doubts as well: shortness of the sprints, so many hours dedicated to meetings, protocols being too cumbersome to be implemented, how to correctly assign the tasks to each member, etc.

‍

‍

‍

‍

‍

‍

‍

‍

‍

‍

Let’s try. It sounds good

The day and the project to start applying Scrum in real life arrived.

We were committed to it and we had the desire and the confidence.

However, as Scrum is basically a framework, we have decided we would apply some guidelines and we would adapt others. Kind of a Scrum customization.

Isn’t valid? Of course, it is, but probably this could have been a good option after gaining some experience.

In hindsight this was one of the big mistakes we made when implementing Scrum. We made decisions for which we were not yet in a position to do so.

For instance, we decided to skip ceremonies as we thought they would not contribute at all, while professional advice says that you should start using all the protocols for two sprints and see how it goes. Then you should do a quick retrospective and see where adjustments need to be made.

In a nutshell, we jumped to a simple conclusion: Scrum didn’t work!

Was Scrum itself not working or it was our implementation?

Step back or double down?

By that time Scrum had been already adopted by numerous teams throughout the world, and especially in the IT world. So why hasn’t worked for us? Could it be that we did not give enough importance to the dailies? That our dailies were held every two or three days? Not having applied in a discipline way grooming session could have affected our results?

Probably… so we have decided to give ourselves a second chance with Scrum, going back to basics and taking professional advice.

We were committed to adhering 100% to the process, every event, role, etc., at least for a decent period, enough to test, measure, do, and correct.

Just after that time we could sit down to draw conclusions and adapt Scrum to our needs or projects, or disregard it.

‍

‍

‍

‍

It seems to be working! Time to improve it

‍

We were gaining experience, understanding each role and event, taking advantage of its strengths: mainly in sharing information, being transparent, and delivering features at early stages enabling us to iterate and close gaps.

We were yet not 100% convinced with everything proposed by Scrum: meetings, how to deal with continuous changes in requirements and their impact on the budget, etc.

Probably not surprising having those concerns, we were stepping out of our comfort zone, so we were forced to learn, to experiment, to be open to new ideas, and to overthrow paradigms.

Even if Scrum is quite easy to understand in its terms, it could take some time to get used to it; it implies a difficult cultural change for a team.

Doubtless, Scrum, being a flexible framework, was adding value to our development cycle process, but on the other hand had brought issues or new areas in which we should focus.

We found out that its semi-prescriptive approach helps remove ambiguities in the development process, while still providing enough room for us to introduce our personal touch.

Nothing is permanent but change

Today we have fully adopted Scrum as the framework for software development.

We have reached a degree of maturity that allows us not only to take advantage of its strengths but also to adjust it to each project.

Currently, 99% of our projects are developed with Scrum. As we act as tech partners with our clients, we have encouraged them to adopt Scrum as well, and we have supported them in their successful adoption.

I’m sure we all agree that the ever-changing context implies facing, quite often, new realities and new challenges.

For instance, the outstanding growth we have experienced in recent years has led us to handle larger work teams, more complex projects, etc.,  and we have been forced to look for new alternatives or amendments.

But even if sometimes is hard to change and adapt, to succeed you must run towards it.

“When you are finished changing, you’re finished”. BEN FRANKLIN

I think those words echo today more than ever before. Don’t’ you?

Conclusions

The “panacea” does not exist

Every software development methodology or framework has strengths and weaknesses, so the key is to identify which one to be applied depending on context.

In any case, nothing can be worst than not applying one.

All I know is that I know nothing

You need to recognize your lack of expertise when starting to implement something new.

Scrum is a lightweight framework, which includes tools, meetings, roles, that helps teams to structure and manage work. Although is not rigid but rather flexible, before starting to adapt the process you should be sure that you have sufficient knowledge and experience to carry out the changes that will better fit your organizations and projects.

It’s OK to ask for help

Being self-taught contributes a lot to acquiring knowledge, but this may not be enough.

Don’t be afraid to ask for help, for advice. It’s a sign of strength, that you are willing to improve, to learn and move faster than going alone.

Seeking help from third parties allows you to consider different points of view, experiences, best practices, etc.

Continuous improvement

You must be as agile with your framework as you are with your product.

You can stray from Scrum fundamentals to fit your specific needs.

This is about implementing and improving.  Take the time you need to check how things are going, make any necessary adjustments, and don’t force things just for consistency’s sake.

Keep in mind that clear communication, transparency, and a dedication to continuous improvement should always be at the core of the framework you choose.

The rest?  The rest is up to you.

‍