An Overview of Scrum
An Overview of Scrum
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
Originally, I asked a Scrum Master to help me write something about Scrum. However, he said it may not be worth it because there are already too many documents, books, and whatever out there that he says will not be authentic. Thinking about what he said, maybe it will be better if I assume that reader can do their own research on Google to find out more about Scrum and I only do my part of sharing personal experience with it.
Definition of Scrum
Let's start with definition first. This is what Wikipedia says about Scrum:
"Scrum is an iterative and incremental Agile software development framework for managing software projects and product or application development."
From my understanding, Agile is a software ware development method that aims to develop software incrementally. The progress will be reviewed regularly and new features will be created based on current situations. Scrum is one well-known Agile methodology that defines the practice to do Agile development effectively. The idea behind Agile or Scrum is embracing changes rather than locking requirements.
Why we need to embrace change
We need to embrace change because it is the reality that we cannot avoid. To understand Agile, we should go back to earlier day of software development. There is something special about those earlier days. It is a big mess.
Early day of software development
Developers of that time did not think the same way as what we think now. Professionalism meant writing lots of documents, defining the requirements as precisely as possible and spending more time to prepare for implementation before actual implementation. This is what we call the Water Fall model.
Water Fall was the norm of the industry in the past and it is still popular nowadays. When I took my degree last decade, Water Fall was the only methodology taught in Software Engineering course. Even after I graduated, job titles in the market reflected the Water Fall model with Project Manager, Analyst, Designer, and Programmer roles.
Water Fall is based on the assumption that if we spend a lot of time thinking, preparing, analysing, we can do it right when we need to do it. Theoretically, this idea is quite cool. Practically, it is still popular in Asia, especially in the conservative industry like banking and finance.
Another point is the important role of project manager. In the traditional development environment, project manager is the most important person. They care about project progress more than anyone else and play the role of negotiating with customers and pushing developers to deliver work. If there is anyone else that need to interact with customer, he/she must be an analyst or designer and at most, architect.
The limit and the solution
As most of us know, good ideas do not necessarily get applied successfully in real life situations. What had happened is the high rate of failure in software industry. There are many kind of failures like failing to deliver, budget overshoot or, less serious, delivering software that interested no one.
However, for anyone that stayed in the industry for a decade, it should not be a big surprise. Here are some common issues why it is so hard to develop software the right way.
1. Pushing does not work well in Software Industry.
Unlike factories, software development requires a developer to spend effort and good will to deliver high quality product. There is no machine that can write code yet. The only source is still human brain and it does not work very well if it resides in the head of an unhappy person.
But it is unfair if we blame it all on the Project manager. Deadline and schedule are decided by people who are not involved very closely to development ,and sometimes, by business requirement. You must be very lucky if got chance to work in the environment that do not OT (over time).
2. Customer do not know what they want
Steve Job knew it and we know it too:
“People don't know what they want until you show it to them.”
Locking requirement is good. It helps to put the blame to someone else, not us, for producing crappy software that no one wants to use.
Still, I feel pity for our customers. It is incredibly difficult to know what they really need before they start using it. But unfortunately, no one let them do that and they continue to produce all kinds of nonsense and unrealistic requirements. To be fair, analysts help them to create the mess too.
3. How people react to failure.
Ancient wisdom says if you do not do it right, you may not have been well prepared. So, what will a smart person do? He spends more time preparing or if we say another way, less time doing. Unfortunately, by doing that, problem is getting more and more severe.
So, what is the real problem here and how should we solve it?
I feel the biggest problem we face here it the challenge of predicting what we need to build. I recall my
personal experience of playing paint ball not too long ago. To summarize, it is a disaster. To elaborate further, I feel it is hard to hide and shoot a person at the same time. After enjoying hitting tons of bullet on my, the pro told me that I shoot the wrong way. They say do not shoot single bullet or waste all your bullets to look like Rambo.
The key point is to shoot 2 bullets at one shot. Why?
Because the bullet flies fast and you need 2 bullets to have enough time to see where the bullets landed. Base on that information, you adjust gun direction and aim a more precise shot.
That is the point, you shoot first, get initial feedback and improve from there. This is how things should be done in software development. You build something first, see how it looks and slowly improve on it.
Creating a wonderful application is a lot like learning how to ride a bicycle. The best approach is to sit on it, ride it, fall down, stand up and sit on it again. For the sake of projects and for the people, do not lock project requirements, constantly review what you have build and add new requirement is the formula to success.
How to apply Scrum
There are 3 roles in Scrum: Product Owner, who represents the customer voice, development team, and Scrum Master. In practice, the Product Owner is played by traditional Project Manager. The Scrum Master role virtually does not exist. Most of the time, developer or manager will play the role of Scrum Master. Here are the activities that Scrum teams need to apply:
To constantly review progress and define new work, Scrum teams divide the project schedule into iterations. Commonly, the iteration length is two weeks. It is the sweet spot because if it is less than 2 weeks, the overhead of management is too high, if longer, then the team cannot adapt to change fast enough.
Beginning of each iteration, the team should spend time on iteration planning. Iteration planning normally includes tasking, estimation of stories that being scheduled to the current iteration.
This is the fun part where we play Poker style estimation game. Each developer will have a stack of cards, each card include the estimated effort for a story. Due to someone's brilliant idea, the number in the card is not random, they follow Fibonacci number. For each story, developers show cards at the same time to voice out their idea of how much effort is needed for the story. After debating and voting, the team commits to the story with the estimated effort.
Responsible teams even plan work an iteration ahead. It cannot be too far and too precise but it helps us to have a quick view of what is going on. They called it T+1 or T+2 planning (means 1 or 2 iterations ahead).
Daily stand-up meeting
Scrum emphasizes on information sharing and collaborating. It requires the team to meet up regularly to share difficulties, solutions, and progress. Effectively, over this super short daily meeting, each team member take turn to elaborate on few things below:
- What did I accomplish yesterday?
- What will I do today?
- What obstacles are impeding my progress?
Daily stand-up makes sense when the team size is small enough and people know what other people are doing. It is better to time-box it (normally 15 mins).
Retrospective meetings normally happen at the end of iteration. It is less important, hence, many teams choose to skip it or do it less often. Still, retrospectives play a great role of generating insight and discussing how to improve performance. There are many ways to do retrospective but you need to stay to its objective, that is to discuss what had happened in last iteration and suggest solutions to overcome issues.
Backlog is for the Product Owner to express what he want to achieve. Basically, it is a collection of user stories. Developers help to estimate each story, note down the dependencies among stories. After that, it is Product Owner role to plan in stories for next iteration from backlog. It should fit team capacity nicely.
The benefit of Scrum
Normally, the life in Scrum team is pretty balanced; no rush, no last minute surprises and no cutting corners to deliver work. It is true that due to business requirements, products need to be launched on time but constantly reviewed in progress to give the product owner early information and more space to manoeuvre when facing blocks.
It is also helps to build better product due to quick feedback and helps to create a more realistic schedule.
I am the guy who believes in humans more than processes, but if the process is wrong, life is more painful than it should be. So, for the sake of developer world, spread out the ideas so that we suffer less and the quality of software can be improved.
Published at DZone with permission of Anh Tuan Nguyen , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.