SCRUM — The trendy methodology and why it falls short

SCRUM — The trendy methodology and why it falls short

SCRUM has come a long way in terms of popularity and use over the last 10 years — going from an obscure methodology mainly used in small website teams to being tested and adopted by more business critical development and operations teams.

However, SCRUM has been used in ways that are anti-SCRUM/AGILE manifesto and how SCRUM is intended to be used. Just as Waterfall, it comes down to the people involved and how willing they are to make things work effectively and efficiently while being pragmatic.

Here are the common ways that SCRUM/AGILE has been implemented that result in a process that is anything but Agile.

1. SCRUM has been an excuse to think less

In the world of project management, project managers and business analysts love to plan, analyze, have business requirements translated to technical specifications, and oversee the development process from beginning to end. Take the standard waterfall planning and analysis phases out of the picture, then you get something that practically goes right into building something. But build what? And, how are we getting the requirements?

It has become unfortunately common in projects utilizing SCRUM to negate any kind of planning and thinking prior to the building. This leads to a lot of technical debt and extra work due to the directionless beginning and a poorly described end-point.

The lack of overall thought put into the product by non-technical and technical members has been a hurdle in many projects; unfortunately, unwinding the fuzzy path and building the firm foundation usually occurs when the project is at its most vulnerable state, leading to a plethora of headaches.

2. The software development team loves it but the business camp is no where to be seen

In many ways, SCRUM has been adopted by the software engineers because it allows them to focus more on coding and less on meetings. That’s a good thing! Developers should focus on designing and creating systems and less on the finer points of business requirements and drafting accompanying technical specifications.

SCRUM definitely encourages fewer meetings and more focus on code for developers. However, if the business is not included or on-board, then SCRUM becomes nothing more than a development team management tool than a means to build better systems for the end-users. Why, you ask? Without business involvement, then there is no real feedback loop and so is no different than what the output of a full-on waterfall process would provide.

3. Unless you have the right people, it is just as siloed as any other methodology

SCRUM/AGILE depends heavily on collaboration in order to reduce the necessity of temporal project documentation. If the development team members, SCRUM Master, and Product Owner are only talking during the SCRUM ceremonies (planning, daily standup, review, and retrospective) then they are not collaborating enough.

It’s not uncommon for teams to rush through ceremony obligations and then hide away in their caves until the next ceremony. This mentality completely squashes all of the benefits that SCRUM/AGILE is meant to achieve.

Most SCRUM teams will work with user stories and user stories have three main parts: the actual story, the acceptance criteria, and communication. The communication piece needs to persist past just talking about the story during sprint planning. If sprint planning is where communication ends, then you will see the stories look more and more like a section out of a business requirement document and you will see more re-work that will need to happen in following sprints. If you are using SCRUM, be ready to constantly collaborate!

4. Highly regulated environments have a difficult time with SCRUM

This likely does not come as a huge shocker! Highly regulated environments such as healthcare and finance have a difficult time effectively using SCRUM/AGILE. If they do, it’s probably more ‘WAGILE’ (waterfall beginning, SCRUM middle, waterfall ending).

Having worked in both Healthcare and Finance environments, there has definitely been an aura of apprehension from project leadership to use SCRUM due to all of the legal components and sensitivities involved in the project. However, my feeling is that if there is a more active feedback loop instilled in the teams, then SCRUM actually has a huge advantage over standard waterfall since compliance verification will be encouraged to be an ongoing activity instead of a end-of-project check during the UAT phase, which inevitably leads to lots of expensive re-work and release date slippage.

5. SCRUM has been used as an aggressive waterfall process

What’s more fun than a long, lengthy waterfall project? Doing non-stop, aggressive, Just-In-Time waterfall process every two weeks… As SCRUM as a methodology is aging, many proponents have advocated more aggressive approaches to keep the trend relevant, sharp, edgy, and so forth.

Strangely, this seems to be shaping the whole SCRUM process into more of a short-interval waterfall type process where a single sprint is a complete, end-to-end quasi-waterfall project. It is taking the idea of every sprint ending with a releasable candidate to the extreme, as every sprint, in fact, ends with a production release.

There is nothing necessarily wrong with that if you have a system to support it; however, it becomes an issue when it encourages poor work to be published that looks and feels unfinished. It also seems to deter ‘big’ things that take time and produce high value in favor of small, bite-sized things that provide equally small, incremental value. In my mind, this leads to a deeper discussion around LEAN and MVP principles — a blog post for another day!

6. SCRUM at it’s core doesn’t feel all that “Agile”

Is SCRUM really even all that Agile? The methodology is intended to increase communication and shared-understanding as a team. But, SCRUM ceremonies overtime seem relatively pointless.

Agile development should be focused on understanding what the work is, collaborating as a team to get work done well, and to keep an open feedback loop with business stakeholders. However, how often does sprint planning, daily stand-ups, reviews, and retros feel like they actually produce the intended benefits? Does the time guessing story points before you do any work actually allow you to plan better from sprint to sprint? Do daily stand-ups become repetitive and feel like the least efficient way to say you are blocked (the few times that you are actually blocked)? Why wait for the review to show the business stakeholder your work? Should they not see the work as soon as it is available to be seen? After the first couple of sprints, does the retro provide enough value to have a formal meeting?

What are your thoughts on SCRUM/AGILE? Leave a comment and let’s discuss!