As Agile and Scrum are adopted by an increasing number of companies, “Thinking Tools for Large-Scale Scrum” 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.
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.
This article discusses estimation techniques for teams that are adopting Scrum. The authors recommend to use story points during the release planning phase, but initially to switch to hours to estimate tasks during the sprint planning. Then the team will gradually move to using story points to estimate complete stories that members will commit for in next sprint.
Introducing Scrum in organizations is not always easy as there is always resistance to change. This article presents the implementation of an hybrid approach to make the transition to Scrum easier in a German context. After having identified the lack of requirements documentation as an obstacle to Scrum adoption, the author proposes different workarounds that allow to minimize this fear. Even if there is a risk that teams might stick with the hybrid approach, he considers that this is a valid alternative to the “total Scrum” adoption road and that this is the challenge of Scrum consultants to bring the teams to the next level.
When properly implemented, the Scrum framework enforces simple constraints that lead a team to self-organize into a state that achieves 5 to 10 times performance improvement versus traditional approaches. However, the majority of Scrum teams is unable achieve this objective.
Scrum Expert Copyright © 2009-2024 Martinig & Associates