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.
In this article, Gunther Verheyen explains that pair programming is a good software development practice. Even if Scrum doesn’t prescribe specific engineering practices, Scrum fully supports the agile principle that says “Continuous attention to technical excellence and good design enhances agility”.
In this excerpt of their book, Sam Guckenheimer and Neno Loje describes the mechanisms that Visual Studio (primarily Team Foundation Server [TFS]) provides to support the team enacting an Agile process. This article provides an inside-out overview of what makes the enactment of Agle possible in Visual Studio.
In a slightly provocatively titled “Why I’m done with Scrum” blog post, Jimmy Bogard provides four reasons reasons why he decided to abandon using Scrum to adopt a lean approach to software development.In his first two reasons, he discusses the inefficiencies of the iteration system.