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.
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.
How do agile projects accurately forecast their budget when they are typically just a bunch of hippies coding without requirements or documentation? Waterfall projects are obviously much better at budgeting with all of the traditional up front design and planning, right? Anyone who has been on a waterfall project can see that this is a complete fallacy.
Scrum Expert Copyright © 2009-2024 Martinig & Associates