Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Viewing Posts by William Krebs
Organizational Views of Agile Maturity
Categories:
Agile
Categories: Agile
| The desire for organizational agility is on the rise, according to PMI's 2012 Pulse of the Profession. The survey found that more than 25 percent of respondents now use agile project techniques frequently, and that number is likely to keep moving up. The survey also found that in successful organizations, 68 percent of projects meeting original goals and business intent often used agile project management. But how does agile apply not just to teams but to organizations as a whole? When an agile adoption is new, the focus is on training. When teams have been trained, shift your emphasis to fostering a community of agile practice in your organization. As agile matures, the metrics will expand beyond how many people use agile. The metrics will start to verify that agile benefits are beginning to be realized. These tips can help an organization assess the strengths and deficiencies of its agile teams: 1. Instead of asking about one team's remaining work at the end of an iteration, look at the amount for unfinished work for all teams in your organization. This can tell you who needs more coaching. Graph the remaining work for each team every two weeks, for example. Can you see which teams need more help? Can you find the average slope for both successful and unsuccessful iterations? Ideally, we start at 100 percent work planned on day one, reach 50 percent in the middle and have 0 percent left at the end of the iteration. 2. Determine if all of your project teams are adding requirements. This can tell you if you are implementing the letter of agile, but not the intent. Strong agile teams will capture some competitive advantage of timely requirements, but will control scope change to not lose focus. 3. Get a pulse on impediments and retrospective actions for all teams.This can tell you if teams are implementing continuous improvement and facing risks head on. Asking these questions at an organizational level may not be natural at first. But when encouraged, it can reveal a new perspective on which teams are actually leveraging agile as they mature on their path to adoption. What are your thoughts on organizational agility? To discuss Pulse of the Profession on Twitter, please use #pmipulse. See more on the Pulse of the Profession. |
Estimate Time for Agile Estimation
Categories:
Agile
Categories: Agile
| Agile estimates and planning are essential to a project. But a common mistake during rough release estimating is forgetting that the opportunity for a greater level of detail comes later. If that point is missed, teams may struggle during the initial high-level estimates. To avoid that problem, I suggest that at the beginning of a project, teams do a rough estimate of each requirement. One common estimating technique includes "planning poker," also called Wideband Delphi. In planning poker, each team member secretly picks a number representing how much effort or complexity they think is involved in a given requirement. The numbers then are revealed. The person with the highest value explains to the team why it is hard. The person with the lowest value explains why it is easy. After no more than two minutes of discussion, the team votes again. This process is repeated until the team reaches a consensus or it discovers there is not enough information to estimate this requirement. The problem arises when teams blur the focus between the low-level estimates for a two-week iteration and high-level estimates for the release. Low-level estimates are more precise because they split a requirement into several tasks, estimated in hours. By contrast, the high-level estimates are in more abstract relative "points." Some teams incorrectly attempt to identify predecessor dependencies in high-level estimates. They can also spend too long trying to refine the estimate or silo work between sub-teams to make two estimates for the same requirement. This detracts from the goal of being able to estimate a large pile of requirements quickly and at the beginning of your project. Remember, there is plenty of time to deep dive later. How long does it take you to estimate your project? |
Improve Burndown Charts for Your Projects
Categories:
Agile
Categories: Agile
| Agile teams use burndown charts to show the amount of work completed over time to monitor their progress. There are three common patterns to look for in a burndown chart. When progress stalls, the line becomes flat. When work is added, the line shoots up. And sometimes, the rate of work slows and floats above an ideal trend line. Let's look at some baseline data, reflect on the meaning revealed by the charts and see where teams can improve. The following burndown charts show how many task hours are left for the team. The goal is to drive the remaining work down to zero by the end of the time-box. We'll start with a graph of three iterations completed by one team in two weeks. Sprint three is still underway, which you can tell because the line for it is unfinished. But what happened in these other iterations? In sprint one, there is a catch-up pattern. The team stalled in its progress from days 8 to 11, and then made a push to finish. As a result, the team signed up for fewer hours in sprint two. This is common, as teams plan for more work than they can get done at first to help them plan for the next sprint. In sprint two, the team faced a different problem. A bubble of work formed at the beginning because the team didn't plan the sprint process correctly and had to add work. Both of those issues in the normal rate of work can confuse efforts to forecast the rate of progress based on the first few data points, allowing for improvements down the line. Instead of looking at the trend from the first day's allocated work, for example, take the maximum amount of work anticipated and plot that from day one. Ideally, the maximum amount of work will be accomplished on the first day. But in the case of "bubble" sprints where work is added mid-course, drawing a line from the sprint's maximum workload as though it were known on day one will give a better presentation of the ideal trend line. The next problem is a plateau every few days. The graph originally provided data for 14 days including weekends, not just the 10 working days in the sprint. It looks like the team is unproductive every few days, but it is simply a reflection that they took the weekend off. Adjust the burndown chart, as I've done below, by accounting for added work and masking non-workdays and your team will have a clearer picture of its iteration's progress. What adjustments do you make to burndown charts to ensure an accurate depiction? |
Make the Most of Your Agile Project Coach
| During your project management career, you may encounter an agile coach -- someone who helps you or your project team adopt and improve agile approaches. Let's look at four types of coaches and how to best utilize them: Fly in, fly out This is usually a consultant who comes for a one-time session. He can provide a fresh perspective from having worked with several organizations. Be sure the session is long enough for the coach to assess the state of your organization. Let his input be uninfluenced by your existing perceptions. Deploy the coach's suggestions in your own way or get him back for more extended consulting. If the coach's observations seem extreme, don't be surprised -- it may be necessary to get to the issues in a short amount of time. Continuous outsider This "contract coach" typically spends a few months advising a team or an individual. This arrangement offers more continuity, as the coach can observe the flow of the process through all stages and still maintain her independent view. To get the most of your contract coach, be sure to include her in most meetings of the teams being helped. Do not think of these coaches as separate from your team just because they are not regular employees. One insider Some agile coaches will work alone, as a full-time employee. This situation is advantageous because the coach can set clear direction for an agile team without a potential conflict of interest among his and the proper organizational strategy. While this arrangement assists in quicker implementation of decisions, it may not allow for as many fresh ideas. It can also be hard to scale the coaching effort to more agile teams as organizational needs grow. Team of insiders Some organizations employ an entire team of coaches, which is effective when working with difficult teams because the teams and coaches can support each other. For example, a team may have trouble adopting key practices, but pointers from another coach may help get the team unstuck. Multiple agile coaches can also balance the workload of coaching multiple teams so no one is overloaded. The hazard is that the coaches may splinter into competing ideas on how to execute agile. Establish a process for when the gurus do not agree on which agile practices should be emphasized. Strive for a balance of standards and the ability to evolve as new practices emerge from the profession or successful teams. In general, make sure there is synergy between your agile coaches, tools team, education people, and corporate governance or process definition body. How do you best work with an agile coach? See more posts on agile. See more posts on teams. |
4 Metrics to Help Spot Trouble for Agile Teams
| In coaching several agile teams and sifting through long lists of metrics, I've observed a core set of metrics that can help distinguish successful teams from teams headed for schedule slips: Juggle Many teams have multiple team members who split time between projects. In most cases, it is better to have fewer people full time on a project than more people part time. For example, instead of having eight people working part time, try having four people work full time. Why? We lose 20 percent efficiency each time we multitask, according to Mike Cohn's book Succeeding with Agile. Count the average percent of time each person is allocated to the project. Averages less than 80 percent should be looked at to see if the team is being pulled in too many directions. Plan leak This is the ratio of work planned compared to potential capacity. In theory, people could allocate up to 54 task hours per two-week iteration, but the team only plans an average of 30 hours. Then there is a problem with planning. Fill your plan until you have 70 to 80 percent of the team's time accounted for. Eighty hours for a two-week sprint is not ideal because other important work is not represented by tasks (such as mandatory training, email, unexpected maintenance work). In addition, have the team own its total task hours and let them "pull" work when they are ready. Assigning work to individuals may create silos and is based on imprecise estimates. Execution leak Compare the number of task hours left at the end of the iteration to the total planned. There should usually not be any hours left, but if the team meets this goal every time, it may not be planning aggressively enough. It's healthy for teams to have a small number of hours, say 5 percent, left over on a small number of their iterations (10 percent or less). Jelly This shows how much unplanned work was added during the iteration. In my experience, it is okay to add up to 15 percent because planning is based on approximate estimates and technical execution of the project may reveal new subtasks. But if more than 15 percent has been added, it's a sign the team is either not planning enough or they never say no to new requirements. Either way, they lack the ability to plan with enough diligence or to pause new work until future sprints. What do you think? Have you used these metrics? What metrics do you use to help spot trouble? |