Quotes on Scrum and Agile Project Management
Every Product Owner is different. Every Product Owner needs to work out what is right the right way for them to fill the Product Owner role. Every organization is different. Every team is different, and every individual is different.
We all know that there are three roles in Scrum teams : product owner, scrum master, and the development team. Modern software development can sometimes require some specializations that could be beyond the capabilities of the Scrum team members. UX and Web design, database administration, performance testing are some examples of activities that requires specific expertise only for a limited amount of time. How do you deal with it?
Meetings like the daily stand-up or retrospectives are moments that rhythm the journey of Scrum and Agile teams. Sometimes these meetings are almost religiously considered as rituals or ceremonies that bound participants together and that nobody could miss. Is this true? In his book Forming Agile Teams Workbook, Jesus Mendez discusses if the participation to Scrum meetings is mandatory.
How do you manage software quality in Scrum? In traditional waterfall projects, teams will try to detect bugs in the final software testing activities like integration and acceptance tests. With the short timeframe of Scrum sprints, this approach does not work for Agile projects. In his book Scrum Product Ownership, Robert Galen provides some guidance on how to build quality software with one fundamental tip: you don’t test quality!
We all know the “Definition of Done” used in Scrum for items that should be potentially shippable to the customer at the end of the sprint. In his book Essential Scrum, Kenneth Rubin discusses the “Definition of Ready” that applies to product backlog items that should be ready to be developed before the start of the sprint.
The creation of Agile approaches was also a reaction against huge and useless requirements documents, either textual or using modeling techniques like UML. All the values of the past should however not be discarded in the requirements activity. In his book “Agile Software Requirements”, Dean Leffingwell explains how user stories are different from use cases and software specifications.
The last Agile Manifesto principle states that “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” For Scrum teams, the sprint retrospective is therefore a key meeting for continuous improvement. The results are however not always satisfying. In his book “Essential Scrum“, Kenneth Rubin discusses the most common issues in sprint retrospectives that he has noticed in his Agile coaching experience.
Scrum Expert Copyright © 2009-2023 Martinig & Associates