Articles on Scrum and Agile Project Management
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.
The Scrum Burndown chart is very simple tool to monitor the project status. It is easy to explain, easy to understand. But this metric also put in evidence some pitfalls observed in many agile workshops and adoptions. This article discusses how to build a Scrum burndown chart and what should be included in it. It also presents guidelines on how to assess the project status using the burndown chart and what could be done when problems are detected.
This article focuses on the obstacles to using Agile in a distributed team environment and recommends how to counter them with what is called “de-Agile.” De-Agile is tailoring Agile to fit your team by taking out processes that don’t make sense and tweaking those that need to be modified to suit your needs. In a distributed team environment, de-Agile is mostly about removing the sense of being distributed. You need to educate each team member about the additional communication responsibilities required when working with remote team members and emphasize the importance of being open and available.
Does the term “documentation” have any place in an agile environment? The goal on agile projects is to keep documentation as simple as possible, relying on roadmaps, overviews and concepts rather than enterprise-focused details. But what happens when using an agile approach on more complex projects? For example, what if the team that writes the software is different from the team that must maintain it? Or what if auditors come calling? In these instances, basic agile documentation based on user stories alone may come up short. This article provides insights into how teams can take an agile approach to documentation in more complex environments.
Scrum Expert Copyright © 2009-2023 Martinig & Associates