During Scrum adoption, people tend to get away from tasks and activities that they don’t like in traditional projects like documentation or writing proper code comments. In this article, a ScrumMaster shares his experience with a “no documentation” approach. He learned the hard way that minimal documentation is better than no documentation in Scrum projects. The team can decide on a case-by-case basis what level of documentation for which components and code logics is needed.
Should you track individual performances in Scrum and how do you do it? Nanda Vivek says that there is only one answer and this is “No”. Measuring individual productivity is against the spirit of Scrum and the article discusses the importance of being helpful and collaborative in teams. The author however does not give guideline on how to deal in this case with the individual review that is a common practice in many large organizations.
Pair programming is an extreme programming technique that should help Scrum teams to build better software: two heads are better than one, they say, and thus two heads will usually produce a higher-quality system. This article presents the benefits of this technique for the team, the developers and the managers that will appreciate the value of a true team that works well together, collaborates and continuously improves the code base.
This article presents the IBM perspective on top five lessons learned about scaling Agile in a leading insurance provider. These lessons were that a team-by-team, incremental approach is best. Measurement and management tools can help you get and sustain executive buy-in and improve the development process. Mentoring and coaching should be provided for the process first and for the tools second. Integrated tools help demonstrate value. Retrospectives are essential for continuous improvement.
Companies that transition to Agile often adopt the analogy that sprints are just mini waterfall. This article provides five reasons why Scrum sprints are not mini-Waterfall. Each argument is illustrated by a diagram that provides a clear visual evidence of the difference between the Agile approach and a traditional process.
Planning Poker is an Agile practice that harnesses the “wisdom of the crowd”. The goal of planning poker is not to derive an exact and accurate estimate that would stand all future scrutiny, but rather, to obtain a group estimate in a fast, cost effective and collaborative way.
As Agile and Scrum are adopted by an increasing number of companies, this book from Craig Larman and Bas Vodde provides important thinking tools to remind us that it is more important to “be agile” than to “do agile”. Scrum or Lean are frameworks that we can use for continuous improvement of our software development process and not tools that should be applied blindly like cooking recipes.