A personal opinion. These days and for some time now, a very popular method of software implementation in either mid-size or large-scale projects is the Agile methodology and SCRUM in particular. What Scrum tries to do is to simplify the process on the one hand and also boost efficiency on the other. A very specific process though, has to be followed to fully and correctly implement Scrum. More on scrum.org.
What’s it about
Scrum and Agile are great, they work and the take off some of the burden from the developers and also reflect a more real-life situation where the client cannot tell you or does not know to tell you the full spectrum of his/her requirements prior to implementation. The problem comes when Scrum is misused, in the way of implementing some of the Scrum elements and processes whereas leaving some “out”. The reason why this happens could be bad knowledge of Scrum. It could though be, a very “polite” way to misuse Scrum towards pressure to the team in order to produce more in less and at the same time feel parts of something very competitive.
In short, when a client comes to you for a project, Scrum “says” that first you have to set up a Product Backlog, which, in layman’s terms, is a prioritized list of the individual requirements of the deliverable. The list items are descriptions of the requirements, more abstract than specific and detailed requirements. The list’s priority is something the client does and in some cases takes into account the Scrum master’s opinion or ideas.
Who’s the Scrum master?
So the second part of Scrum is that there is a Scrum master, this person can be a dedicated one as a Scrum master or can even be one of the development team members. Its pretty obvious here that there is no point really to talk about Scrum and Scrum masters amongst a development team of… one. The Scrum master is the coordinator and the liaison to the client. He has to prioritize, organize, monitor and coordinate.
Then you have the development team. The way the process works, in simple words is that starting with the Product Backlog, the team, along with the Scrum Master, but mainly the team, decides on the first Sprint’s Backlog, which is a prioritized list of some of the items from the Product Backlog. The First Sprint Backlog is what will be implemented during the first Sprint. A Sprint is a short development period of usually one to two weeks where the dev team sits down and implements the items in the list of that Sprint, a list which is called the Sprint Backlog. There are times when the Sprint duration is set to just one day, which is not very logical in most cases but it happens.
The misuse
No Product Backlog, therefore no Sprint Backlog, the Scrum Master being either the 1-man development team him or herself or the Scrum Master being busy with other projects. Even so, the Sprint is desired along with a requirement for a daily progress on… well… some kind of list.
The dev team sits down and has to sort a rather large amount of requirements and some more requirements that come from those requirements and so on. Once they do, they start developing and giving a status report.
In all of this “mess”, the only thing that is official and required tends to be for the dev team to do the Sprint and provide the progress report. See where I’m getting at? No pressure right? Nope, this kind of approach puts almost the full burden upon the dev team, prioritization, clarifications, client-communications and many more tasks which would have normally been tasks of the Scrum Master. Put that into a more clear perspective by having the dev team be just one person.
Oh captain my captain
Not only has the situation already been entangled so much even from the start of this “hybrid” Scrum-Sequential labyrinth but it will gain more and more complexity every time the client passes along one more requirement. You see, the way this would work is that the Scrum Master would tell the client that this new requirement would have to wait to be included in the next sprint’s backlog. But what happens when there is no sprint backlog or even a Scrum Master to coordinate this? Here is maybe the very first time a rather calm and professional dev team would start screaming for help.
Wishing on a star, or an array of bits
Either if you are a client or an intermediate contractor, you must avoid two mutually-exclusive scenarios :
- do not mention sprints and Scrum if you are not to fully, 100%, correctly and diligently implementing it all the way in your project
- if you are to implement Scrum, make sure you assign roles that can be supported, have a team of more than one developers, have a Scrum Master that can do it and does not have to do the development as well, stick to Scrum and put boundaries to both the client and the individuals included.
Asking your dev team to do sprints without all the rest of the Scrum items and rules in place, is like asking a race driver to hop into a car, run as fast as possible and when the pit stop has to happen, to hop out of the car and change the tires himself, pump some gas, hop back in and drive and at the same time expecting him to win that race…
Regards.
