Quotes on Scrum and Agile Project Management
The Product Owner is a very important role in Scrum. He has the key responsibility to create, manage and prioritize the product development backlog. Can this responsibility always be to a unique person or is there situations where you could have a team of product owners? Kenneth Rubin discusses this topic in his “Essential Scrum” book.
One of the principles of the Agile Manifesto says, “continuous attention to technical excellence and good design enhances agility.” In his book “Implementing Domain-Driven Design“, Vaughn Vernon complains however that adopting Scrum has often led to spend less or no time on good software design practices and he is not the only one in this case.
One of the principles of the Manifesto for Agile Software Development is that you should “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Mickey Mantle and Ron Lichty give some advice in their book on how to facilitate when you are the manager of a self-organized Scrum team.
Agile practitioners are aware that Scrum has three roles: developer, ScrumMaster and product owner. In his book “Executable Specifications with Scrum”, Mario Cardinal also discusses how you can use the role notion in Agile to better understand stakeholders that have a different perspective, a concept that is also named “personas”.
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.
Scrum Expert Copyright © 2009-2024 Martinig & Associates