Starting with the Startup - Educating the Team

In the previous post I have explained why we have choose agile approach or more directly Scrum. But before you start using agile approach it is very important to explain what is agile and Scrum to the whole team and of course to the management.

In our case we are lucky because we have full support from the management. It means there are no "artificial" obstacles in implementing Scrum. The only real obstacle are we. So before going on I made presentation about Scrum, team members did some reading and then we discussed about the whole approach.

So when you are educating team do not forget to explain to them:

• Cores of the agile and the Scrum

And especially take care to explain:

• Why everything in Scrum is time-boxed
• What is user story and what are the differences between user story and use case
• What means DONE
• What is goal of the sprint
• What is velocity and why it gives better estimation when things will be done than "classical" approaches
• Why testing is so important in the agile approach
• What is burndown chart and how it helps the whole team

It may be clear why these points are important but I will shortly explain why I think it is important to take care there is full understanding of them.

Time-boxing - very often developers are used to implement some tasks as long as they want. Even after deadlines. In Scrum everything is time-boxed because this way everybody have to be focused that features have to be finished in proposed time. So it is not possible to change architecture forever. In one moment you have to decide and do implementation.

User story - in lot of companies and even in schools developers are used to thing in use cases. While use cases are good very often they put limitation that need not to be set in given moment. Classical examples are: then user clicks the button.... How the use case knows there is .... button. User story explains functionality that user wants to achieve without too much details.

Done - Done must mean: I am confident that feature implemented can go online. It is tested, written in good quality and I believe there are no bugs. This should be approach for all features that are marked done. You should not return back to this feature.

Goal of the sprint - you have to set goal if you want to have good feeling at the end of sprint. How could you know if your sprint was success or failure without clear goal?

Velocity - velocity is number that based on the experience (yesterday's weather) tells you how much team can implement in the given period of time. Velocity is better than "classical" approaches because it covers meetings, phone calls, unexpected bugs and everything that is happening more or less regulary.

Testing - if there are no tests how can you change the code and be sure that you didn't break any of the existing functionality. Well you cannot and you have to check everything after each change. If you have lot of tests you just run them and find out immediately if you have broke some existing functionality.

Burndown - is great tool that tells you without mercy you current status. It will tell you if you are doing good or if you are doing bad. Just have it in front of eyes.

Conclusion: If you have decided to take agile approach do not forget to educate developers what is agile. It is better to do it at the beginning then fixing problems in the middle.