Quick introduction to SCRUM

Scrum is a well known team management method focused on empowering people's commitment into the project. There is always big problem to switch work perception from involvement to commitment. Do you know what is the difference between "going to the office" and "working"? Take a look at chicken and pig story.

Scrum rules

Scrum is based on people - the process is just an addition to us - engineers. There are few very basic, intuitive and natural rules, rules which obeyed guarantee successful delivery.  The rules are:

• product is divided into pieces that are able to be implemented by short, manageable tasks,
• effort estimation is measured in hours and always done by team members,
• estimates are continuously changed. The estimate may change every day (to be better),
• elements taken to deliver in iteration are selected by the team and the customer, 
• daily meeting is conducted with three simple questions: (a) what you did yesterday? (b) your plans for today? (c) are there any impediments that may perturb your plans?
• only team members are allowed to change iteration plan,
• no one is penalized because of raising problems,
• each iteration is finished with product increment presented to customer,
• each iteration is ended by lessons learned meeting.

Scrum process

Development process controlled by Scrum is started with a list of product elements (high level work specification) called Product Backlog. It is a list of functional requirements that may be presented to customer. 

Before each Sprint (iteration) team together with product owner (customer) selects features for delivery. Initial estimation, updated by everyday re-estimation is taken into consideration to be sure that the promise is realistic and fits into team's capacity. 

Features are being developed with daily progress check conducted by Scrum Master (development lead). Meeting minutes are distributed and Burndown Chart is updated. 

After the Sprint, the materialized promise is presented to the customer who decides if it's what he expected. The sprint is ended by lessons learned meeting. The whole cycle is repeated. 

Customer may add things to Product Backlog, but such change can't influence running sprint. New features will be estimated by the team as usually.

Scrum for project manager

Would  you like to be able to predict project success? I'm sure your answer is yes. Are you always able to do it? Hmm . . . . I'm not sure. Probably it's sometimes like a poker game. Let's take a look at one of Scrum's most important elements: Burndown Chart.

The left burn down char shows risked iteration. Something was underestimated during planning phase. Thanks to this view you have (to be honest it's the team that see it first) early detection of the problem. What to do in such situation? Team with the customer (and perhaps with you) should decide which promises will be postponed to next iterations.  

On the other hand, the other picture shows very desired situation. Team's progress is much better than estimated. In this situation the team may decide to add additional tasks into current iteration. It's possible and welcomed :) But be aware that it's only team allowed to change iteration plan. As a project manager you will be interested in more artefacts created by Scrum. For sure it will be a list of impediments that may be your direct material for risk management. Information form meeting minutes and general team members performance is a great information for configuration of further projects.

Please keep in mind that apart from information presented before there are few more facts about Scrum:

• iterative nature of work - Scrum cycle is repeated every ⩾10 working days,
• manageable team size - up to 10 members,
• cross-functional team able to cover all aspects of the work to be done,
• process prepared for changes.

Scrum for customer 

Typically customers love Scrum, as the method creates honest and open cooperation environment. From very beginning, the customer is very close to the product. He is involved into product planning; after that he see how the sales representative's promises are being continuously materialized by product increments presented after each sprint. The customers are happy to see that team has a problems, as it's very natural. Who has no problems? Do you like people without problems? Are they honest with you or rather just hides something?

Scrum for developers

Typically developers just love it. Scrum creates stable and well defined environment to work what is good enough for most engineers.

###