Posts Tagged With: agile project management

Influencing the eternal optimism of a delivery team

When I teach agile fundamentals classes, I frequently emphasize the importance of inspection and adaptation. Teams which don’t use feedback loops with their products and their processes should not consider themselves to be very agile.

For those teams which use an iteration-based cadence for their delivery such as those who have implemented the Scrum framework there have multiple feedback loops to help them improve. A common example is comparing how many product backlog items they were able to successfully complete during an iteration with how many they had forecast that they would be able to complete at the beginning of the iteration.

For stable teams using fixed duration iterations, a reasonable assumption is that over time the volume of work which they can complete should become progressively more predictable which in turn should improve forecasting.

So what happens when a team consistently misses their iteration forecasts by a significant margin?

If it is a team which regularly completes more work than was forecast, this could be the result of traditional management oversight causing team members to act very cautiously when estimating their work. Letting the team know that it is normal that they might miss their iteration forecasts on occasion and spending effort on making the team feel safe might help them to start making more aggressive forecasts over time.

But what about the team who is frequently completing a lot less than they had forecast?

It would be very easy to write off such teams as undisciplined or immature but such judgments won’t help the situation.

There could be many factors causing the team to fall short including:

  • Underestimating work item effort or complexity
  • Insufficient dependency identification
  • Poor risk management
  • A lack of focus caused by multitasking or other sources of distraction

A retrospective provides a safe place to identify the situation and to come up with improvement suggestions which the team can take into their next planning session.

This might also provide a good opportunity for the product owner to express some sadness that the team wasn’t able to meet their forecast and to help them understand how this could reduce their credibility in the eyes of key stakeholders.

Regardless of the cause, understanding why the team is over-forecasting is an important step as that information can then be used to create a sense of urgency regarding this behavior.

 

 

 

 

Advertisements
Categories: Agile, Project Management | Tags: | Leave a comment

Just because you have information radiators doesn’t mean senior stakeholders will review them!

Information radiators are a great idea.

After all, who wouldn’t want to reduce the effort involved in keeping stakeholders up-to-date about a product or project or increase the consistency in messaging to all stakeholders?

But convincing executives to use information radiators as a primary means of staying current is not an easy task. Yes, there might be a few early adopters who are open to trying a different way  but most are likely to prefer to receive these updates the way they’ve always got them through one-on-one or steering committee meetings using status reports. So project managers or Product Owners spend time harvesting and curating information from the radiators into traditional status reports or presentation decks.

This introduces a few challenges:

  • The activity of creating these reports or presentation decks is non-value add
  • The information shared is likely to be somewhat stale
  • There is an increased likelihood of reduced transparency as the “warts & all” information available in radiators might have been redacted or modified to fit the spin which the publisher wished to portray

So how can we help executives through the transition to using information radiators?

Start with why – if they don’t understand how traditional reporting approaches hurt them, they are unlikely to have any sense of urgency about adopting a different approach. Whether it is reducing delivery costs or improving the quality of information presented, find out what concerns them and use that as a lever for change.

Second, you will want to ensure that the information radiators being published are relevant to senior stakeholders. Taking the time to understand what they need to support their decision making should help in creating dashboards which they will actually want to use.

Finally, rather than asking them to make the significant leap from a meeting-based approach to a self-service model, consider continuing the meetings, but use information radiators as the supporting materials for the discussions in place of traditional presentation decks. This should spark your stakeholders’ curiosity as they are likely to ask questions based on their interpretation of the information published which will provide you with an opportunity to provide live “color commentary” about the project or product’s status.

If you want management to change, you need to apply effective change management.

 

 

Categories: Agile, Facilitating Organization Change | Tags: , , , | 1 Comment

What’s the right sprint length for your team?

The Scrum Guide calls sprints the “heart of Scrum” and also indicates that they should be one month or less. The Guide also cautions about setting sprint durations longer than a calendar month to ensure that inspection and adaption is happening frequently which will reduce the risk of wasted team effort or of building the wrong product. This aligns with the third principle from the Agile Manifesto which encourages teams to deliver value frequently, from a couple of weeks to a couple of months.

A research survey conducted by Scott Ambler+Associates found that the most common duration used by teams following a sprint-based delivery model is two weeks, but how should a team decide what is the optimal sprint length for them?

Their decision should consider a number of factors including:

  • How “new” the team is
  • Their delivery process
  • Constraints on their being able to complete product backlog items
  • The maturity or capability of the team to disaggregate work items to a small enough size so that they can complete multiple items in a sprint
  • Expectations from the stakeholders who will participate in sprint reviews

For teams which have just formed or are working with technologies or a product which is new to them, too short a sprint duration may prevent them from being able to complete anything meaningful. This could cause them to get discouraged and might frustrate the stakeholders who are expecting to see progress every sprint. On the other hand, if the team is new to flow-based delivery approaches and they start with a long sprint duration, they could revert to traditional behaviors where they complete batches of work items in phases over the life of the sprint.

When in doubt, it is usually better for a team to choose a shorter sprint duration as this should encourage them to identify, elevate and eliminate the real constraints which limit their ability to deliver. With the longer duration, while they might be aware of the constraints, their sense of urgency may be less.

The team should not change sprint lengths on an ad hoc basis, but if they have identified triggers which suggest that they need to increase or decrease duration then such changes might be done after a major product release. Improvements in the team’s productivity or a high degree of volatility in the product backlog are two possible triggers. Another example is if the stakeholders attending sprint reviews consistently feel overwhelmed with the content of the product increment being demonstrated to them.

Sprint duration is another case of Goldilocks and the three bears – finding out what’s “just right” will take some trial and error!

 

 

 

 

 

 

Categories: Agile | Tags: , , | 2 Comments

Blog at WordPress.com.

%d bloggers like this: