---

What Can Cause Chaos And Frustration Before The Scrum Framework? This Might Surprise You!

To better understand the impact of the Scrum framework on our software engineering practices and businesses, it makes sense to have a look at a day in the life of a software project.

Therefore, I would love to briefly talk about a software project from the past before we adopted the Scrum development and software delivery framework in our organizations.

A few days before I wrote these lines, we had lunch with a former colleague with whom we worked almost 20 years ago.

Marcus earned his Scrum master certification and Scrum product owner certification from International Scrum Institute™. He currently works as a Scrum master for one of the leading software houses in the agile project management software domain.

As a Scrum master, Marcus is now in charge of supporting an agile Scrum team whose members are located in geographically distributed locations around the globe.

During our lunch, Marcus admitted that there are a lot of typical challenges with distributed agile Scrum teams. Some of the problems he specifically mentioned related to his software project configuration are:

• Differences in working styles among Scrum team members,
• Timezone differences,
• Cultural misfits, and
• Language constraints.

Despite these difficulties, Marcus still added that running a software project with the agile Scrum process is more fun, productive, and enriching than how we used to work 20 years ago. Compared to days when we used to work without Scrum software development and Scrum software delivery processes.

Marcus’ statement was indeed a big testimonial for the credit of the Scrum framework from a very accomplished and experienced manager, Scrum master, and product owner.

Thank you, Marcus!

Then we explained to him one of our past software projects before we adopted the Scrum framework. I’m sure many Scrum masters will recognize similar experiences in their projects before they earned their Scrum master certifications.

Back in the late 1990s, we were part of a software engineering group to build a smart card-based public key infrastructure. Smart cards securely protected private keys of infrastructure members, associated public keys and their wrapper certificates were openly distributed (as the name public implies).

Back in the day, this was by itself a relatively complex IT project that required multiple interdependent hardware engineering and software engineering teams. We had to do massive amounts of research and development (R&D) to build a fully functional hardware and software system.

Remember, in that project we did not yet use the minimum viable product (MVP) concept to experiment, create, learn, and experiment again.

Without Scrum, creating such a sophisticated infrastructure that constituted numerous hardware and software elements was a real challenge.

Here are three significant setbacks we used to have without any Scrum masters and anyone who possesses a Scrum master certification in our teams.