THREE ELEMENTS OF CHAOS AND FRUSTRATION BEFORE THE SCRUM FRAMEWORK

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

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 one of my ex-colleagues with whom we used to work together almost 20 years ago.

This gentleman, Marcus has got 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 operating an agile scrum team whose scrum team members 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 used to meet with the scrum framework. I'm sure that many scrum masters would resemble this experience to their previous projects before they've gotten 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 certifications 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 these are days before we had the minimum viable product (MVP) concept to experiment, create, learn, and experiment again.

Without scrum to create 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.