***Draft Version of article
SCRUM seems to be the most light weight method of project management ever. Let’s see what it says:
1. Maintain a prioritized list of things
2. Pick some items and put them in a sprint/ iteration
3. Deliver the items at the end of the sprint/ iteration
4. Revise the list of things to do
Whats it about this that is so difficult to do? Over the last months, we have had difficulty doing this in each and every project.
Difficulty 1 : Drafting a Project Backlog
Project Backlog is not just a prioritized list of things but needs to be prioritized, estimated and also useful/ relevant. Its time and thinking consuming to arrive at a consensus on prioritized list of things or project backlog. It is generally considered a client’s duty to provide the project backlog and keep it useful. The very nature of Agile ensures that he is not the *only participant* in this exercise, nor is this a dump down exercise where product owner just has a field day choosing things. It requires the product owner to answer questions on usefulness and address technical dependencies in the project. It requires the client to be in toes all the time – evaluating usefuless of the items in the backlog and advising the team of business priorities. And importantly it requires the teams to understand this business perspective of the project backlog. For most developers, transition to a business thinking in software development is rare. Software development has generally been considered a technical job, far removed from business and developers/ in most cases even project managers have been shielded from the business side. Hence, arriving at a project backlog that is useful and reflects a common understanding is indeed a difficult exercise.
2. Difficulty 2 : Drafting a Sprint Backlog
Most developers are pretty poor in dividing required tasks for a requirement. It is primarily because they have been fed on a diet of breakdown of tasks already done and specialized people doing specialized work. There is little or no incentive to think about the big picture or overall scenario. Most developers also want to shy away from committments. They would rather have someone else estimate how long it would take and how it should be done. And importantly, most teams are afraid to fail or allowed to fail. SCRUM’s allowance of just enough thinking and ability to add tasks later allows most developers to only think of two-three days at time, giving project managers little by ways of vision of tasks for the sprint. A sprint backlog generally becomes a dead duck document which is passed around in morning email. One day the team is doing 30 hours of work and another only 5 hours.
3. Difficulty 3 : No restrospectives
Most of the problems highlighted above also occur because there is no learning. There is just not enough of committment from the teams side to grow in managing their projects better – not as much as learning a new technology for instance. What is the incentive to estimate better? What is the incentive to divide tasks better? What is the incentive to try an unchartered path, fail and provide a learning of how not to about things? Another problem why teams avoid retrospectives is because most of them do not know how to do retrospectives – what is problem identification and problem solving.
If we do a root cause analysis of each of the above difficulty scenarios – we would reach to one common cause : not enough committment and no focussing on right things. Most of us have difficulty asking questions the right way, analyzing the right way and answering the right way. Most of us are caught up in our day to day working so much that we incorporate only fire fighting element of SCRUM in our project management, leaving the more beneficial – learning and adapting out of window. SCRUM is like driving and swimming – lots of little things to take care of but once you know it, you can do it easily. Unfortunately learning it first time around require : committment and focussing on right things.