If you are agile, you might spend some time estimating. If you’re using Scrum, you estimate what you can do in an iteration so you can meet your “commitment.” But estimation is a problem for many agile projects. The larger the effort, the more difficult it is to estimate. You can’t depend on ideal days. Do your estimates provide value? To whom?
Many teams think they're agile. They might work in iterations and have a ranked backlog, but they don’t see the value they could be seeing. Usually that means they have a number of false impressions about agile. Read on to have three common misconceptions debunked and to learn what you need to do to make your agile transition successful.
The fable of stone soup is often told as a lesson about cooperation in times of scarcity. Mike Edwards has used an approach based on this allegory to help teams make steps toward improving themselves and the way they work, especially when it comes to shifting to new methodologies such as agile and Scrum.
Traditionally, the project manager or ScrumMaster is responsible for evaluating a team's performance. But peer feedback, when each member of a team picks another member, observes him or her, and then shares thoughts and suggestions about that other team member’s work, can also be very valuable to continuous improvement.
People will ask, “Can you use agile outside software development? In real business, not just in software teams?” Most experienced agile practitioners will instinctively want to shout, “Yes! Of course!” But intuition apart, where is the evidence? Allan Kelly found some examples and shares how agile works in environments outside software.
Contrary to popular belief, agile projects require as much planning as any other project type. It is the timing of this planning and how we attempt to minimize wasted effort that is different from other approaches. This article attempts to explain the different levels of agile planning and how we utilize them in an ongoing project.
Agile pods are small custom agile teams, ranging from four to eight members, responsible for a single task, requirement, or part of the backlog. This organizational system is a step toward realizing the maximum potential of agile teams by involving members of different expertise and specialization, giving complete ownership and freedom, and expecting the best quality output.
A good product owner should be collaborative, responsible, authorized, committed, and knowledgeable. But what do you do if yours doesn’t exemplify these characteristics? This article aims to showcase mitigation plans that can be effective for overcoming Scrum violations due to the fact that you’re not working with a typical product owner.
Many engineering leaders and agile coaches believe that transitioning to agile is simply a matter of process training and expert advice. But frequently, it means that deeply ingrained habits need to be changed. This article identifies eight steps that address the wider organizational shifts implied by agile and will help create buy-in from your team.
ScrumMasters don't like to talk about their own troubles or failures, even though they say it’s good to fail. They don’t like to admit it happens to them, too. Sometimes it just creeps up. If you've started relaxing your Scrum principles and feel yourself slipping into ScrumBut, take hope: You and your team can recommit.