Should we SCRUM?

It is that time in the life of this industry when something new has passed the horizon and is approaching us at top speeds. Later in the last century, it was CMM, followed by CMMi in the early years of this one. This era of evolution sees the dawn of Agile practices.

Agile practices have been around for over a decade now. The industry just took it’s time shifting gears around it, slowly and steadily now advancing towards top gear.

We are all aware of what Agile practices in software development means, perhaps in its entirety as the authors of these practices intended it to be, or in some corrupt deviant phenomenon. We, as the flock of IT industry, believe this is the silver bullet that will release us from the clutches of software development hell. We also believe this one to be more silvery than its predecessors.

But remember this; this is exactly what the creators of this so-called weapon say it is not. There is not one piece of literature that states that Agile practices (in whatever form) are silver bullets that can magically kill all evils and make your life better.

SCRUM is one methodology that is based on the Agile philosophy. SCRUM, as I see it, is an excellent framework to improve overall project’s performance and provides good practices for Agile Project Management. It talks of well defined roles, limited number of artifacts (for project management and not as a part of the technical package of the project), and clear and concise rules on how each iteration needs to be executed.

It is not difficult to understand SCRUM. It would take less than hour to give a novice enough insight on SCRUM, to enable him/her to understand all its concepts. The difficult part, as with anything else in the world, is implementing it. And moreover, implementing it in services based IT companies.

While I evangelize SCRUM from the deepest corners of my heart, I have to but point out the fallacies of force-fitting SCRUM in places where it is not welcome.

Before we continue, let me lay down in front of you the scenario that I am considering while presenting the counter arguments of the implementing SCRUM in IT services industry.

“An organization, ABC Limited, is dedicated to providing IT solutions to its customers. The organization has many clients across the globe and is making/or has made its presence in the world of highly competitive market of providing services. It is a vision of this company to increase its size by another couple of thousand by then end of Financial Year 2009. It also aims to increase its revenues by 15% year over year for the next five years. The space that it operates in is also occupied by the top IT giants of India and hence has everyone fighting for the same piece of the pie.

“As with CMM and CMMi of yesteryears, the company now faces the demand from the western world to deliver their services in a SCRUM fashion. CxOs of client companies all across the globe have attended at least one conference in the past three years that showcased successful products that were developed in an SCRUM environment. Over the next couple of months, the CxO asks his/her executives to research and provide him/her with details of SCRUM framework and its benefits. The executives attended more seminars that evangelized SCRUM and came to a conclusive report that the organization must ask its vendor ABC Limited to adopt SCRUM.

“As with any wild eco-system, where “survival of the fittest” and “evolution by natural selection” are the ground rules to survival, IT companies, specifically, ABC Limited, changes it processes to incorporate SCRUM’s practices.

“Taking a more optimistic picture, the company ABC Limited, spends valuable resources, to dig deep and clean and modify its processes from the roots, rather than just batch renaming their processes to “agile”-processes. Come launch day, a brand new project (of a customer that demanded SCRUM) is asked to pilot it.

“The project team is trained in the specific workings of SCRUM. They are told:

1. Thou shalt not change thy commitment during the Sprint
2. Thou shalt have Daily Scrums for the team members to update each other on progress and impediments
3. Thou shalt have a ScrumMaster, who shall not manage, but facilitate
4. Thy Product Owner will not interfere on a daily basis (micro-management)
5. Thee and only thee is responsible for estimating and taking ownership of tasks and deliverables
   

“When the project starts the worker ants get busy. All motivated by and enthusiastic of this new framework, they are confident that they will be able to achieve all their targets. All is well until, the customer calls to change a specification and the team is asked to accommodate the urgent request in the Sprint. Next week comes, and the customer has more changes. Slowly, by the last sprint, changes are common, re-work is high and the team’s confidence on SCRUM is low.

“In the meantime, the project manager in his new avatar as the ScrumMaster has been trying to manage and control the team throughout the execution of the project. He ends up estimating and assigning tasks to the team. The Product Owner starts demanding daily status reports on the progress of the team which now becomes the main agenda of the Daily Scrums.

“In time the project fails to meet its desired state and the customer blames the team, who in turn blame SCRUM.”

This is not an out-of-the-blue case study. It is pretty much the fact across all organizations that claim to be Agile but in all practical sense, are not.

Adopting agile practices, in this case SCRUM’s practices, is not about adopting only what is felt beneficial, but all the practices as a whole. It is a package deal. It is not about just renaming processes to hoodwink customers into believing otherwise.

Neither customers nor the teams working on projects are at a liberty to discard or adopt practices as they feel fit.

Adopting SCRUM has a lot of advantages – both for the team as well as the customer. But for it to be successful, it needs to be understood completely by both parties.

Both parties need to understand their respective responsibilities in this game called SCRUM. Customers need to understand that micro-managing, asking for daily status updates and changing requirements on the fly is NOT allowed. Project teams need to understand the severity of their commitments to Sprints. And it is a Catch-22 situation.

Customers do not have confidence in commitments of project teams to go blind for the length of the Sprint and hence feel the need to micro-manage. Since, the project team no longer self-manages itself and the Sprint, the commitment they make is no longer strong.

So, this brings up the most obvious question in our minds. Where can true SCRUM practices be implemented? My most unintelligent guess would be – the Product companies. The teams (including all the way to the VP of the product) in such companies have more control over the features, technology and the execution process than typical service companies. While they still have market pressures, the buck still stops within the organization and that makes all the difference.

To support my argument, I have not come across any presentation or article that has a list of service companies in the list of top users of SCRUM. It may however list a part of the service company that is considered to be, not a vendor or a partner, but an extended arm of the customer’s development team itself. In that case, there is not too much of a difference between the customer and the offshore development center of a vendor that it controls.

Bottom line

For the apparent business reason, it is very difficult for a service company to say ‘No’ to its customers. It is even a bigger challenge to ask them to hold on to the change requests till the end of the sprint. And unless the customers are themselves geared up to speed, this golden rule of SCRUM will inadvertently be broken.

And this is the real reason why SCRUM cannot be implemented in IT services companies; at least not without making real changes in processes of both the vendor and the customer. And until someone comes up with a model that suits this kind of multi-location contract based development, I’d recommend not forcing SCRUM down our own throats and make it another CMMi-like fad.