Organization mostly do an agile transformation for a whole team, project, or organizational unit, given that agile is a team driven approach. But there are also professionals who start using agile practices individually, or who are working agile as a one person team. How can individuals adopt agile, and what kind of benefits can it give them?
The principle of “responding to change over following a plan”, is it a strength or a flexibility that can’t work in practice? For example, what about agile projects that had difficulties managing changes and customers who expect too much flexibility? Can agile not live up to its promises, or is it the way that teams and organizations have adopted agile that is causing the problems?
An exploration on how project management with Scrum and the project management process areas of the Capability Maturity Model Integration for Development are related.
When you have a large backlog with many user stories, structuring a product backlog with story maps or process maps can help to keep an overview and see the bigger picture.
In his recent blog posting “Planning Poker: Avoiding Fallacies in Effort Estimate” Hayim Makabee discusses a common problem of effort estimation called planning fallacy and why planning poker helps to avoid it.
Earlier this week Jim Bird from BIDS Trading Technologies posted a blog article about the differences between Agile and Lean approaches to planning and decision making.
Interruptions are something that every team has to deal with and, if not managed appropriately, they can potentially have a detrimental affect on their ability to deliver. In a recent post on the Agile Advice blog, Mishkin Berteig described seven options that teams could consider to deal with interruptions when using Scrum or iterative Agile approaches.
There are usually multiple things which need to be done before the start of a project. Teams usually use 'Iteration Zero' to put all necessary systems in place in order to start delivering business value in subsequent iterations. Is this the right way?
During planning poker, a product owner should explain the user stories to the development team, but he or she should not try to unduly influence the development team's estimates.
Many Agile teams use the terms Story points and Complexity points interchangeably. Agile teams believe that they are better than hours just because they are based on complexity and relative size. Mike Cohn suggested that it is wrong to use story points to depict the complexity of developing a feature, they are all about the effort.
Michael de la Maza asks the question what exactly is a Story Point? He went looking for an answer and found many: “Story points represent nebulous units of time.” or “Story point is a random measure used by Scrum teams. This is used to measure the effort required to implement a story.”
The traditional agile approach to prioritization is that user stories of higher business value should be implemented before ones of lower business value. The concept is simple, but implementing it well relies on having a mechanism to assess business value. Pascal Van Cauwenberghe has recently described an approach to defining business value, called "Business Value Modeling", which may help.
There is a constant, long drawn debate on the benefits of using either story points or hours for sprint planning. Mike Cohn is big on breaking User Stories down into tasks, which are then estimated in hours. Jeff Sutherland on the other hand suggested that some of the best teams that he has worked with burn down story points.
Elisabeth Hendrickson, A.K.A "testObsessed", presents a thought-provoking stance on triaging bugs in an agile project. She discusses her feelings that problems found during the iteration are not "bugs", that only the Product Owner has the right to call something "bug", and that a healthy agile team might likely have no need for a bug tracking system.
In this presentation filmed during Agile 2008, Wes Williams and Mike Stout share their recent experience with a large distributed team, the planning hurdles they encountered and how they passed them, and their recommendation: avoid large distributed teams.