Make Sure Scrum Fits your Purpose, not Vice Versa. Part 3
It is the third and also last part of the series Make Sure Scrum Fits your Purpose, not Vice Versa. Here are the previous articles: Part 1, Part 2. The key goal of this series is to touch upon the most common critique of Scrum and see if it is viable or not and, if it is, what are the steps to tackle disadvantages and make them your strong sides. As the title mentions, the advice is to use the right tool for the purpose, not the other way around finding a purpose to use a particular tool.
In this part we will discuss if it is too late for you to implement Scrum on your project, rumors about Scrum, metrics being used incorrectly, if Scrum is a religion and if developers are being neglected if you use Scrum!
“It is too late to implement it since the project has already started”
If it serves the purpose and, objectively speaking, helps you add more predictability and better control of what you are delivering, also building up the pace of the delivery of the increments, then the answer is that it is almost never too late. “Almost” because we could all agree that there is no use to add Scrum for one last iteration before the project is closed.
The only point is that you will spend some additional effort to change the already existing habits and processes on your project (collaboration with the customer, how you resolve issues in the team, etc.).
“I worked with Scrum before an it was horrible/I have heard bad stuff about it”
The questions are:
- Can you prove it was real Scrum and not just a parody?
- Did you have the type of work environment where Scrum would add value? (more about the types of work environments in Part 1)
- What exactly do you think was horrible about it? Was it because of somebody’s personal attitude? Was it because it was being used incorrectly?
If you can attest that it was used the way it was made to be, the work environment and the specificity of the project were right for Scrum and it was not related to any personal opinion, then you should consult a professional and ask why it did not work out well. Else, try using Scrum only if the project has the potential to include it (check out Part 1 for more).
“I do not get it”
Get to know it. Start with the basics:
- Manifesto for Agile Software Development aka Agile Manifesto (less than 1 page of text volume)
- The Scrum Guide (10 pages of text)
… and then go to something more elaborate (the list of books you can find in Part 2 of the series)
“Velocity will become the ultimate goal”
Velocity is not part of Scrum in the first place. It can be used within Scrum but it is not essential.
It should not be used as a goal of any sort by any means. If you are a manager reading this, you should avoid using velocity as a goal. It is relative and if you still do decide to make it a priority for your team, the team members will likely start oversizing the tickets and this metric will eventually cease to be objective. Be careful about it. By any means avoid using velocity metrics to charge your client more or less for the amount of work that you are about to do.
At this point you may ask “what is the purpose of velocity then”? The purpose is to approximately understand how much we can deliver as a team in one iteration. Based on that you are able to predict how much you can take and at the Sprint Planning check if you have manageable amount of work. Also you can have the statistics about the previous Sprints and see how many, say, Story Points you delivered.
We should not forget that any estimation is another opportunity to check what effort and complexity this or that task has.
“Decision-makers do not want it”
Here are some questions to help you verify if it is the right attitude:
- What are their motives to not want it?
- Do they realize that Scrum will have positive effects if used correctly?
- Are they aware of what Scrum or any other Agile methodology really are?
- Should any of the stakeholders outside the organisation decide on how you do your job if you deliver on your commitments?
“Scrum is a religion”
Yes, I once was told that.
Any religion is dogmatic.
Dogma is a belief or set of beliefs that is accepted by the members of a group without being questioned or doubted. — Wikipedia
Scrum is not dogmatic. The whole point of this framework is to always inspect and adapt meaning that you constantly need to ask yourself if you are doing the right thing in the given situation and if the chosen way of doing work brings value. It is the core of Agile which Scrum is a part of.
If you do not inspect and adapt including the way you work, then it will eventually become a set of rules that are not questioned by anyone and are simply followed.
“Scrum neglects developers”
It might if you treat your team as an assembly line at an imaginary software development factory. Any kind of personality would be neglected in these circumstances. Make sure the ideas how to improve the product which are coming from the team are taken into account and actually are being followed up on, the team participates in roadmap creation and people are not plain executors.
Software development is not a factory line. The reason why it is not is that the work is highly creative most of the time. This makes it impossible to typify all of the kinds of tasks to later on be able to create an easy-to-follow manual execution of the steps to create a product.
Experiment with the framework, strive to make the way you work more engaging and meaningful.
This has been Part 3 of Make Sure Scrum Fits your Purpose, not Vice Versa. I hope you learned something new from it or it made you look at things from different angles. In any case, please clap, share and subscribe for more good stuff coming up!