Scrum

Originally, I asked a Scrum Master to help me write something about Scrum. However, he said it may not worth it because there are already too many documents, books out there and whatever he say will not be authentic. Thinking about what he said, may be 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 start with definition first. This is what Wiki say 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 aim to develop software incrementally. The progress will be reviewed regularly and new features will be created based on current situation. Scrum is one well-known Agile methodology that define 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 are something special about these 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 means writing lost of documents, defining the requirement as precise as possible and spending more time to prepare for implementation before actual implementation. This is what we called Water Fall model.

Water Fall is the norm of the industry in the past and it is still popular nowadays. When I took my degree last decade, Water Fall is the only methodology taught in Software Engineering course. Even after I graduated, job titles in the market reflect Water Fall model with Project Manager, Analyst, Designer and Programmer roles.

Water Fall bases 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 customer and pushing developers to deliver work. If there is anyone else that need to
interact with customer, he/she must be analyst or designer and at most, architect.

The limit and the solution

As most of us know, good ideas does not necessarily be applied successfully in real life situation. 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 a software that no one interested.

However, for anyone that stay 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 factory, software development requires 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 reside in the head of an unhappy person.

But it is unfair if we blame it all to the Project manager. Deadline and schedule are decided by people who does not involve 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 help to put the blame to someone else, not us, for producing crappy software that no one want 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 requirement. To be fair, analyst help them to create the mess too.

3. How people react to failure.

Ancient wisdom say if you do not do it right, you may not prepare well enough. So, what a smart person will do? He spend 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 fly 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 shoot.

That is the point, you shoot first, got initial feedback and improve from there. This is how things should be done in software development. You build something first, see how it look and slowly improve on it.

Creating wonderful application is not easier than learning how to ride 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 represent to 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 team need to apply:

Iteration/Sprint

To constantly review progress and define new work, Scrum team divide 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.

Iteration Planning

Beginning of each iteration, the team spend time to do iteration planning. Iteration planning normally include 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, developer 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 commit to the story with the estimated effort.

Responsible team even plan work for iteration ahead. It cannot be too far and too precise but it help 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 emphasize on information sharing and collaborating. It requires the team to meet up regularly to share difficulties, solutions and share 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

Retrospective meeting normally happen at the end of iteration. It is less important, hence, many teams choose to skip it or do it less often. Still, retrospective 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

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 surprise and no cutting corner to deliver work. It is true that due to business requirement, product need to be launched on time but constantly review progress give product owner early information and more space to manoeuvre when facing blocker.

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 believe more in human more than process 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.