When Do We ‘Scrum’ Down?

The following is a statement I hear very often from managers of Software Development companies.

“We are way better in Software Engineering than we used to be, from the time we started to follow Scrum.  Our engineering practices were not very strong when we were doing traditional SDLC based development, but now we are way better”.

How valid or acceptable is that statement? Can Software Engineering become better with Scrum? Or is it actually directly tied with the Project Management Approach?

Rather than challenging this statement or keeping you waiting further, let me shed some light as to when an organization can be effective by adopting Scrum.

When analyzing the effectiveness of a Project Management Approach it is primarily important to understand why Scrum came to being and to understand what sort of issues it is actually meant to solve.

A primary objective or construct of Scrum is to make “things” more visible and measurable. What are these things? This involves every work product, deliverable, activity, process step, output and every other element in a project. So, Scrum is expected to make,

1. Plans more visible, visual and trackable
2. Requirements more visible
3. Designs more visible
4. Code and documentation more visible and measurable
5. Test cases and scenarios more visible
6. Project progress more measurable
7. Blockers or impediments more visible

and so on.

Scrum is all about progress. Collaboration and communication to solve issues and take things forward is an important principle in Scrum. It encourages decisions to be made by the right people as soon as possible and to keep everyone involved, interested and informed.

We already know this…

Wait!! Isn’t this what we always hear about Scrum? Isn’t this what we already know about Scrum? Well Yes!! But does it paint a complete picture of Scrum? Unfortunately Not!! My belief is that it is equally essential to understand what Scrum is NOT!! Scrum is a project management methodology but does not define engineering practices.

What exactly are engineering practices?

A company adopts standards, methods, practices, frameworks etc. from knowledge around requirements, design, development, testing, infrastructure management, etc. and defines its own engineering framework. It may involve best practices, technologies, tools, techniques and everything else to successfully design, develop and deploy a solution.

What happens if your Scrum team lacks engineering practices?

I am an ardent sports fan and thought of pulling in some examples from different sports and sports personnel.

A team adopting to follow scrum without having a proper platform in terms of engineering practices in place is like,

• McLaren trying to win a Formula One race by asking Michael Schumacher to drive a TATA NANO
• Asking Sachin Tendulkar to bat on a badly curated pitch and score a triple hundred

No matter how proficient a race-car driver Michael Schumacher is or how genius a batsman Sachin Tendulkar is they would not be able to succeed in their specific sport. Simply because a TATA NANO is not fit for a fast paced race and since a dangerous and underprepared pitch is not suitable for a cricket match. In short, it is not possible to drive, if engine is not up to the expectations in terms of engine capacity and it is not possible to bat if the pitch or the cricket gear is not according to modern standards.

Scrum is NOT about the engine, it is all about driving the vehicle…

The engine of a software development team is the engineering practices followed. These are things such as how coding is done, reviews are done, documentation is done, testing is done, resources are planned, infrastructure is managed, and so on as mentioned previously as well.

It is important to know that none of the above is specified by Scrum. Scrum provides the guidance on how to navigate the road. It will tell you how to take a bend, when to slow down, when to speed up, when to look back and see what to change or improve, and so on. So as we see, it’s like trying to compare apples with oranges. Instead we need to figure out what we can make combining apples and oranges.

XP contributing to the confusion around!!

Agile comes in different flavours. More than 12 flavours of Agile exist and contribute in shaping and moulding each other. Many get confused by trying to understand Scrum by comparing it with XP (Extreme Programming). XP, in addition to its project management principles and practices has gone beyond and defined some good engineering practices. If I list some of these, they are constructs such as unit testing, continuous integration, pair programming etc. One can even argue that XP is actually more than a agile based project management methodology.

 

With our PRINCE2 Practitioner course, you can earn a PRINCE2 practitioner certificate in project management and become an expert in the field. Take your skills to new heights and achieve mastery with ease.

 

So in Conclusion!!

Following Scrum makes a lot of sense for a company with properly defined and diligently followed engineering practices. But when no proper engineering practices exist, it is quite easy to try hide your incapability under the comforting umbrella called ‘Agile’. Unless you address your problems related to software engineering processes in your company, adopting Scrum will most probably end up giving negative results. Do not use Scrum as a means to fix your engineering process. It is impossible and just a futile task!!

Think about getting your engineering processes and practices sorted out first before adopting a suitable project management methodology. You may first explore standards such as CMMI, ISO, etc. for the same. This can be discussed in a separate article, but hope this will be a starting point to you all.