Quotes on Scrum and Agile Project Management
When you observe a well-knit team in action, you’ll see a basic hygienic act of peer-coaching that is going on all the time. Team members sit down in pairs to transfer knowledge. When this happens, there is always one learner and one teacher. Their roles tend to switch back and forth over time with, perhaps, A coaching B about TCP/IP and then B coaching A about implementation of queues. When it works well, the participants are barely even aware of it. They may not even identify it as coaching; to them, it may just seem like work.
Technical Debt is defined as the eventual consequences of poor or evolving software architecture and software development within a codebase. Sometimes you have to pay it if you want that you can continue to maintain your application. But sometimes it is better to leave the situation unchanged as Ken Rubin wrote in his book.
Sprint lengths should be chosen in relation to project duration; however, they should never be longer than four weeks. Consider a three-month project. If it has four-week sprints, the stakeholders will only get to participate in two demos before the project is released. This is not enough feedback to mitigate the risks. Shorter sprint lengths are a necessity.
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.
