Is Scrum the Project Management Silver Bullet?

It seems that like many things in the “standards scope”, there is always a flavour of the year. In this case I think in the recent years I have been hearing the buzzwords agile, scrum, Kanban and many things. Now, I call these buzzwords as the methodology has existed for many years. In fact, the Kanban  system has been around since 1953 when it was implemented by Toyota (http://en.wikipedia.org/wiki/Kanban). It’s just that now people are starting to think that being agile through the use of Scrum will deliver projects faster.

So today I’m going to tackle some points that I think will challenge the perceptions that Scrum is the silver bullet to successful project management.

We All Want to be the Best

As team members and project managers, we yearn to find the best methodology to deliver projects on time and at the right time. Many methodologies has been tried such as PMBOK, PRINCE2 and now Agile methodologies. In some degrees, at time they worked and sometimes they don’t.

I myself have been using Scrum methodology for a while now and have experienced some positive and negative things. The best thing about it is the fact that there are more communications within the team and there are more “consensus” in regards to prioritizing stories (items) within the team. It can almost be said that Scrum is a democracy in full force. There is almost no hierarchy and each and every one of the members of the team are accountable on their own.

Each sprints are planned by the entire team and each items decided by the entire team as well, while the product owner drives and requirements and the Scrum master writes all of the stories. It seems so far involvements are good and morale should be quite high for the team. In addition, the everyday stand up meeting does add visibility within team members of what everyone is currently doing.

So, is this going to speed up every single projects? Keep on reading if you wish to know.

What About Customer Expectations?

In any projects, your customer is your project sponsor. Basically those who has put their money in the project and trust your team to deliver. Like most customers, they don’t really care how you manage your project to completion. The most important thing for the customers are: when the product is going to be delivered and if the product going to be delivered as per specified on schedule.

Let’s use ordering a custom car as an example. If I want to order a custom Nissan GTR with completely different specifications such as titanium lamination, out of this world on board computer or something exotic, then I want to know the following:

1. How much money is this going to cost?
2. When am I going to be able to drive this car?
3. Can I get an accurate progress report every months?

With pure Scrum methodology, I found answering the above before project commencement can be difficult. That is especially true when the team being put to task has completely new members. This means the team’s “maximum points per sprint” isn’t calibrated yet and therefore doesn’t matter how complete the specifications is, we cannot answer how long and thus how much money the project is going to cost.

As far as I understood, the team’s “maximum points per sprint” only becomes more accurate after 2 or 3 iterations. Which means the project already start by then. However for a new project like the above it’s not possible to start the project without knowing the 3 fundamental questions. No one is going to start a project worth millions of dollar without any sort of answer and commitments to the end date.

We all know that being agile means that we continuously improve and no one should expect a perfect results on each iterations. However we also know that as a customer, we want to know the exact date the project is going to finish, otherwise why bother? Can you imagine what happen if I invested $1M to build the car and the team that I approached gave me the end date of “when it’s finished”? That’s right, I will take my business elsewhere, to the other team that would give me a definite end date with full commitments.

Therefore, with these scenarios in mind, I think that the best way to avoid losing customers is by doing the initial estimation with non-agile methodology. That is, construct the project’s products breakdown and dependencies, estimate all the products at higher level by dates and come up with an estimated end date fo the customer. As for accuracy, we all know that the end date itself is an estimate, therefore should be communicated to the customer as well.

In this regards, I do not think and pure Scrum estimation would work in this scenario. As usual, if you do not agree, feel free to start a discussion on the comments section at the end of the article. I’m happy to be challenged and who knows we might all learn new things.

Is it All About Points?

In many circumstances during the project work, Scrum members think of points a lot. While this is good, which means that each of the members are committed into gaining tractions. On the other hand, over commitment to the points are not good as well. There will be time where stories would be marked completed for the current iteration (if they are blocked or something) to gain the required points. It is true that the current sprint gains more points but what’s the point? It’s almost like lying to ourselves that the project is fine but in reality not so much.

In other methodology such as prince2, this situation warrants escalation to the team leader which then leads to the item being moved to the next stage for further work. Yes the current iteration would look like it has less points done, but tracking remains accurate.

So, again, I think actual honest progress tracking is more important than the points.

Discipline is Mandatory

Another thing that comes to mind when using the Scrum methodology is personal discipline. As previously mentioned everyone is practically equal within the Scrum team. This means that each and everyone of the members should remind themselves again that there are actual due date that the customer wants. It’s very easy to either get lost in perfections and lost track of time or be too concerned about the points that quality is abandoned. These are the balances that each team members must apply discipline.

Of course, to keep discipline inline, each team members can watch each others and discuss when the project is starting to fall behind.

Humility and Tolerance

I have written previously, software engineers are almost equal to artists. They take pride in their ability and the work they produce. In a team like Scrum where the entire team is practically unregulated, this can be an issue. Each team members must maintain respect with each others. As soon as one of the members think that they are better than every one else, there will be issues.

Again, this comes down to the assumption that everyone is equal in the team. If interpreted correctly, this can be good as this means everyone must respect each others. However if interpreted as a license to over criticise (without constructive feedback) and to look down at other people’s work; then the team will spend more time arguing over different solutions than working.

Total Organisation Support or Nothing

This one is pretty much true for most methodology. When implementing something like Scrum, total support from the entire project stakeholders is very important. Those includes all developers, project sponsors, project managers and anyone else involved.

As soon as some of the developers use Scrum to complete the project and some does not, the project will fail. Dysfunction and miscommunication will happen and everyone will be burned out before you know it. Therefore if you want to use Scrum for a project, make sure you have all the support and involvements that you need.

Does Scrum Means Coding Straight Away?

I think there are actually some perception that with Scrum, development can happen straight away with minimal technical specifications. The argument is that with Scrum it’s continuous refactoring, therefore the codes can be fixed later.

The above is a very dangerous thinking in my opinion, it encourages “cowboy” programming mentality and even laziness. It does not matter what sort of software development methodologies are in use, we must always do things properly and prepare a technical specifications before writing codes. Do the usual class diagrams, pseudo code and the usual software development design processes.

In fact, writing specifications should be factored in within the story points or be written as a separate story.

Conclusion

In conclusion, Scrum is an Agile methodology that can work but by no means a silver bullet to successful project management. There are numerous projects that had implemented this and were successful. The most important thing to consider when using Scrum is to manage customer expectations and estimate using both Scrum method and other methods such as he usual waterfall estimation or using product dependencies chart and then estimate based on those dependencies.

Scrum is not all about points too, actual progress tracking is more important than the sprint points. In addition team discipline and respect are important for successful project completion. With the two qualities, everyone will work better and less likely to get burned out. Furthermore, total organisation support is also required.

Lastly, being agile with Scrum does not mean “cowboy” programming. Do things properly, write technical specifications, spend some time thinking and then start developing your code.

Let us know in the comments section below if you disagree or have better understanding of Scrum and agile methodology, I can assure you that any comments will be beneficial to all the readers out there.

Categorised in: Business Process