My experience with Scrum

Scrum so far hasn’t been good for me, and over the course of last 12 months, I have cultivated several negative perception about it.

Scrum implementation in my last project made people overwork, reduced their productivity and created an atmosphere of chaos. It reached a stage where people worked for an average of 12 hours a day and still remained behind schedule. Customer never stopped making changes to requirements and unrealistic sprint duration only added fuel to fire.  User stories were written as the development was happening in parallel and it wasn’t considered to be wrong. Sprint releases happened with P1 & P2 bugs, estimation had to be changed every week, and it was getting harder and harder to manage the situation.

Few months later I decided to attend Scrum training by Pete Deemer (Ex VP Product Management, Yahoo) at Bangalore. I wanted to really find out what went wrong in my last project? What were the mistakes? How much was top management responsible for failure?

After my first day of training I realized Scrum was not just a change in process but a fundamental shift in software development philosophy. Scrum is about trusting more on people than on process, it is about removing the hierarchy and developing self-organized team, splitting traditional project management responsibilities among product owner, Scrum team and Scrum master, more about collaboration and less about power, more about team and less about individuals, you choose your task than someone assigning to you, every team member has a say on estimate.

At the training, I did some good exercises, which made me comfortable in various aspects of Scrum like product backlog management, sprint planning, sprint reviews and retrospection, backlog refinement, sprint and release burn down charts, daily scrum etc

At the end of second day I reconciled my thoughts on why the earlier agile implementation failed in my organization. Here are the key reasons

• Allowing product owner to change feature description during sprints, which completely against the rule of Agile. You can change things between Sprints but not during Sprints.
• Not building a self-organized team but allowing project manager and tech lead to boss the team, assign task and do estimate without consent from team.
• Didn’t retrain the Project Manager to a Scrum Master, so that he can manage process, protect the team and solve problems only.
• At the end of every sprint you are suppose to inspect and adapt, and this was completely missing due to lack of time and process know-how.
• Team was always over-committed by top management and managers to client.
• Sprint duration was wrong knowing the size of the project, it was like one-fit-all projects
• Customer wasn’t trained adequately on Scrum
• Overall insufficient knowledge of Product Owner, Scrum Master and Team about Scrum

While I agree that Scrum is a better way of building software it has its own set of challenges with respect to appraisal in a decentralize environment, finding trust worthy self-organized people, integrating multiple Scrum teams working on a single large project.

My advice to companies would be to implement Scrum in a slow and steady fashion than implementing Scrum across the board without enough time to reflect and adapt from each Scrum project.