ScrumMaster Certification Training

No Comments

For some month we are using Scrum in our internally development projects and at some customer sites. To deepen out knowledge 13 codecentric team members and 2 colleagues of our customer OEV Online have attended the ScumMaster Certification Training at Xebia in the Netherlands. The training was held by Jeff Sutherland one of the master minds behind Scrum. The slides of the training can be downloaded at Jeffs website.

Jeff in Action

The training itself was on of the best I’ve ever attended. Jeff is an excellent coach and story teller. His opinion and methods to software projects are characterized by great simplicity and efficiency and are based on a number of proven best practices which were combined in Scrum.

There are already a lot of good books and articles about Scrum, so this blog entry summarizes my highlights and insights of the training.

What is Scrum?

Scrum is not purely a development process, but a method to organize any kind of projects and tasks. Jeff explained us that he uses Scrum to organize his weekend activities together with his wife on a ScrumBoard in his kitchen. Examples of other people doing such kind of Scrum sessions at home can we found at Flickr. At codecentric we are using Scrum to organize our sales and marketing activities in short 2 week sprints. The velocity and transparency has improved a lot since we introduce scrum for that kind of work. I will personally put a ScrumBoard in my office so that I can plan my tasks in that way.

Jeff recommends to use eXtreme Programming in addition to Scrum for an agile development method – both together would provide maximum value for projects. Especially the XP practices like Continuous Integration, Test-Driven-Development and Coding Standards were recommended by Jeff as a proven extension to Scrum. We are already using XP successfully in all of our projects – Jeffs training approved that we are on the right way and we should extend our agile afforts.

The Nokia Test

Jeff explained that may teams are saying that they use Scrum, but in many cases are just using parts of the whole story. It is essential to use Scrum in a complete manner and not only parts (like Daily Scrum) to see “the lights blinking” as Jeff said. As an example he used Nokia, which has introduced Scrum in most parts of the companies software development projects. They developed the “Nokia Test” to measure if projects are using Scrum correctly. The test includes 8 questions which all team members of a Scrum team have to answer. For each answer you can get between 1-10 points – so a maximum of 60 points is possible. If you are using Scrum effectively, you should have an average of 6 points per question or a minimum of 48 points in total. The test showed me that it is hard work to introduce Scrum in all of our teams and the test provides us starting points for improvement. We are currently evaluating the status of Scrum at codecentric by doing the Nokia test with all of our development teams.

Velocity

Scrum measures the productivity of the team by introducing the velocity of a sprint. During the course I understood how import and useful this metric is. The Velocity is calculated by the sum of Story Points that have been finished by the team or team members during one sprint. After some sprints you should get a stable velocity for a team that helps you estimate the duration of the whole project and gives you a great metric to plan a sprint. It is important to find a velocity that will not over-utilize your team – this velocity is called “sustainable pace”. The velocity can also lead to conflicts as it transparently shows the productivity of each team member – transparency can hurt sometimes. It was also very intersting to see comparisons of projects that are using Scrum and those that are using the classical waterfall model. Based on a study of such projects, Jeff said that Scrum projects have been at least 7 times more productive! So if you have wondered why all the big internet companies like Google, MySpace and Yahoo! are using Scrum, these numbers will give you the answer.

Emergency Procedure

Jeff has been a jet pilot at the U.S. Air Force, which is the reason why he cares a lot about an emergency procedure for troubled projects. In a jet you will be a “smoking hole in the ground” if you don’t have an emergency procedure and the same is true for software projects. If you recognize during a sprint that you are not able to finish all the tasks in time, you should start the emergency procedure. It is important to do this as early as possible, which mean before halftime of the sprint. Otherwise you can not escape being a whole in the ground. Jeff’s emergency procedure is:

  1. Make something different.
  2. Get someone else.
  3. Do less.
  4. Stop the sprint.

The first step means that you search for alternative ways of solving your problem. Jeff said that there are often easier ways to achieve the same business value and you have to try hard to find them with your product owner. The second step is to get experts helping you achieve your goals. It is often much easier for an domain expert to solve a problem than for the team members – e.g. tuning a database is easier for an DB admin as for a developer. The third step is to throw out backlog items if possible. At the end it is important to deliver a working software that delivers business value. If step 1-3 are not helping you to finish the sprint successfully you should stop the sprint. Otherwise your will waste your customers money.

Money for Nothing – Change for Free

According to Dire Straits song Money for nothing Jeff explained a new approach to fix price projects: Money for Nothing – Change for Free. What does that mean? It means that you make an agreement with your customer that they can finish the project after every Sprint if they are satisfied with the given functionality of the software. Jeff said that in many projects a reduced functionality brings almost the same business value as the whole functionality. If you finish the project earlier your customer saves a lot of money and get the same business value as if he had payed for the whole project in the waterfall model. You can fix in the contract that you get some of the saved money: money for nothing and a classical Win-Win situation. “Change for Free” means that a customer can change the requirements at any time of the project. Therefore he has to throw out another requirement with the same story points that is prioritized less. As Jeff said, more than 60% of the requirements will be changed during a regular software project and that approach is the only approach to get real customer satisfaction. In his point of view classical Change Management is a process that prevents projects of delivering what customers want. I think that Jeff’s statement is hard but that he is right and we really have to change our mind how to deal with changes.

Scalability and distributed teams

Jeff provided examples of projects using Scrum with distributed and big teams. I personally thought that Scrum works very well with small and local teams and not so well with big or distributed teams. Jeff imposingly showed us statistics of teams that scaled perfectly, even when they were distributed to Russia or India. Scrum scales up to as many teams as you need by using virtual teams and so called Scrum of Scrums. You can use distributed Scrum an approach were teams work together locally for the first sprints and than distribute to different locations. A proportion of 50:50 (local:distributed) seems to be very efficient for that kind of projects. Xebia showed real statistic of a big project the did with Xebia India which showed no loss in velocity when the team was distributed. An interesting point was that they also measured the quality of the project in terms of bugs/lines of code. After distributing the team to India the quality was stable. It shows that we are on the right way, as we will provide nearshoring services with our branch in Doboj, Bosnien und Herzegowina based on Distributed Scrum.

Beside the good training we also staid in a beautiful place near a Dutch canal, where we could discuss the learned practices during the breaks in a nice atmosphere.

break near canal

Some of our colleagues and customers will attend the next course with Jeff in November and we will definitely try to get more customers doing Scrum with us.

Author

Mirko Novakovic

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Comment

Your email address will not be published. Required fields are marked *