In this article, Brian Vanderjack shares 21 ways to engage and retain the product owner in a Scrum project. The Product Owner role is very important in Scrum, because he guide the team on how to add business value through creating, prioritizing and managing user stories. Thus it is a big problem when the Product Owner is only involved and not committed to the project.
In this blog post, Jamie Arnold shares some of the lessons learned and benefits of scaling Agile at the Government Digital Service. It is a presentation about how to scale agile from one team of 12 people to 140 people and 14 teams.
Drawing from his own experience as developer and CTO in the game development industry, Keith Clinton has written a book that provides both an overall vision of the Agile and Scrum approaches combined with a detailed practice of these principles in the specific context of game software development.
Paul Pazderski proposes in this article a scorecard to assess the level of transformation of a project team into a Scrum team. This card could be filled by an independent observer like an Agile coach to check how the team is adopting Scrum practices like Product Backlog management or Sprint Reviews.
In this blog post, Cory Foy explains how he recreated Scrum using Kanban coupled with a set of Explicit Policies. Kanban has less initial rules than Scrum, but the team decides with explicit policies how he wants to manage things like the frequency of the meetings with the backlog owner. The blog post describes the right set of explicit policies needed in Kanban to recreate Scrum. As Cory Foy says, this is a little bit a silly exercise, but it allows also to think about the implicit set of policies that Scrum proposes.
In this article, Mitch Lacey discusses the difficulty faced when trying to provide estimates for software development project. The beginning of a software project is the time when you are the least certain about the final scope project, but it is also when you are asked to deliver precise estimates. Agile tries to move from uncertainty to certainty in as quickly as possible.
In this article, Faisal Mahmood discusses seven reasons why a Scrum team cannot get to done at the end of a sprint. In Scrum, “done” is often defined as producing a potentially shippable product.
Scrum Expert Copyright © 2009-2024 Martinig & Associates