Quotes on Scrum and Agile Project Management
Positive sprint reviews increase customer confidence in the team and the team’s confidence in itself. If the review goes badly, the trust will degrade, just as we saw in the story. At the same time, don’t forget that the main purpose of the sprint review is not a round of applause for a job well done. The real goal of a sprint review is to stop and ascertain whether the project is on the right track.
Any framework worth using is built on principles and values. Each of the original agile practices – XP, Scrum, DSDM, Crystal, and FDD – as well as Kanban and Lean, has a set of core values. These values guide us, provide clarity in times of ambiguity, and, most importantly, help us understand why we do what we do. As you read in the story above, the team was attempting to go through the motions of Scrum, but they did not understand why.
Upfront Modeling is fine, documents describing the intended architecture are fine, and so forth. But the architecture, and our learning about it, can improve. Speculative software architecture should be made concrete and not of concrete.
“An adequate ScrumMaster can handle two or three teams at a time. If you’re content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation at your organization, and probably nothing catastrophic will happen.
“If the team is uncertain about how to achieve the sprint goal or if experimentation or prototypes need to be done, then the sprint should be shorter. Uncertainty implies that the work eventually required for the sprint might be significantly different from what was anticipated at the start. If this is the case, it’s better to change direction after two weeks than four.”
It’s important for people to believe that openness given can lead to openness received. This openness must extend to admitting mistakes when necessary. […] When people admit to mistakes, others in a group are more apt to do so as well. It’s always better to know about mistakes earlier than later. Being open about them has the added benefit of giving critics less ammunition.
“After working for some years in the domains of large, multisite, and offshore development, we have distilled our experience and advice down to the following: Don’t’ do it.” “Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum”, Craig Larman & Bas Vodde, Addison -Wesley
Scrum Expert Copyright © 2009-2024 Martinig & Associates