Perhaps the most important reason was transparency. Before Scrum, customers would want something, Product Management then defined requirements, the development team committed to fulfilling them, but the end results were not always as expected. Delivery sometimes slipped, and if a release was rescheduled, the risk was unclear and nobody could tell if the new date was really realistic. Also, the company needed to be able to respond quickly to changes in market conditions and business strategy. Scrum helped Polarion understand what the company needed to do to build quality software faster. That’s why Polarion switched from defined and predictive development to an empirical iterative incremental model – exactly what Scrum is about. Software Development Times, October 4, 2012.

I got emailed this introduction as a teaser for an e-book. This struck me as a perfect example of why we try to make changes. What we are doing isn’t working, so let’s try something totally new and see if that works.

My consultant mind kicked in and so I thought about the claims in the first half of the paragraph (i.e., the problem statement).

First, “the end results were not always as expected.” OK, the thought that jumps to mind is that any technique or tool not executed well enough can see this kind of inadequate results. I don’t see the “why” or a root cause here, just a general statement of not getting what we wanted. I keep reading.

See also If Our Crisis Is Obvious To Everyone Then It Is Too Late To Fix It

Second, “Delivery sometimes slipped.” Again, no details why, it just slipped … sometimes. Gee, that would be a great result for many places I’ve worked. In one case it was not a question if the project would be on time but how late it would be. No projects were ever on time. Again, no root cause nor a hint of why deliveries had slipped. I read further.

See for example Its The Schedule, Stupid

Third, “If a release was rescheduled, the risk was unclear and nobody could tell if the new date was realistic.” The pattern is now clear. We continue to talk about general symptoms without ever mentioning if a why-it-went-wrong was identified. Why is never answered. It is like saying the car won’t start. The solution? Let’s go buy a new car!

See How To Get The Schedule Right

I love tools and systems, and Scrum in particular. However, if someone identified the above problems to me I wouldn’t recommend Scrum, instead I would deep dive to understand why their current processes are producing these results. In every case I’ve done that, we’ve achieved on time delivery with good quality. This was always done using the current people + processes + tools but with the reduction or elimination of key bad management practices (e.g., optimistic estimating, over-committing, etc.).

See why In Project Management 9 + 3 Is Not Equal To 12

My conclusion from this experience is that while I would prefer to use the most modern and agile approaches available, these don’t automatically result in the underlying problems going away. Why not?

When I first started to dig into Agile some years ago, there was nothing that made me particularly excited about it (as a programmer, for example, I was completely turned off by the notion of pair programming). We were already fixing organizations and getting software intensive projects to on-time using what was essentially incremental delivery approaches (lots of short waterfalls — does that sound familiar?). I then ran across Scrum and fell in love with it. Scrum codified so well so many good practices in a neat and well defined process that people were using successfully.

See for comparison Why We Don’t Need All Those Experts

But, and this is important, when I dug into how Scrum was doing, I started to see and hear the same things I’ve always seen and heard. Often, teams were not getting the results they expected! The notions of “Scrum-but” was being talked about as the reason for some missing expectations. There were challenges, for example, with scaling Scrum to large organizations that worked efforts worldwide. Again, these were all the same kind of issues we’d seen in the past with other methodologies. The only detail being different was the method being used.

See a solution in The One Perfect Project Management Methodology

None of this is an indictment on Scrum or Agile or any particular tool or technique (including waterfall!). Instead it is a reminder that digging up the root cause of our problems is always critical. If we don’t know the root cause and fix that then the chances that any change (incremental or revolutionary) will fix the problems are much less probable.

Why is this? Because, at least in my experience, the fundamental root causes stem often from managerial and cultural issues that don’t go away with a new methodology. This was an often quoted maxim at the Software Engineering Institute that no tool would fix an otherwise dysfunctional organization. The dysfunction may be nothing more than a senior manager who is absolutely certain (she did get promoted to senior manager didn’t she?) that the way to get something done that needed six months was to target completing it in four months.

See more at A Successful Manager But Never A Successful Project

Don’t fall for the hype or the notion that some tool or method will solve all our problems. They might indeed be great tools and we might indeed want to adopt them, but if we continue the same bad management habits we’ve used in the past, then that shiny new tool will probably not solve our problems. Finding the root cause of our problems first, is one of those fundamental project management tools that works.

Have the new approaches you’ve adopted in your project fixed the root causes of your problems?