Easy in theory, difficult in practice

I've written and spoken frequently about the many issues with holding infrequent lessons learned sessions. The good news is that many practitioners now recognize that it is much better to discuss and implement improvement ideas frequently over the life of their projects than just at the end of a phase or the project as a whole. This applies both to projects which follow a predictive life cycle as those following an adaptive one, with the main difference being the frequency at which such reviews occur.

Retrospectives are an integral part of the Scrum framework but conducting such reviews regularly is core to most flavors of agile.

However, that doesn't mean they are well performed.

To understand why, let's draw a parallel to project risk management.

Teams might do a reasonable job at identifying risks, assessing them and coming up with risk response recommendations for the higher priority ones. Unfortunately, often times those risk responses never get implemented. This might be the result of response owners not understanding how important it is to implement the responses in a timely manner, a lack of quality in the risk or risk response descriptions, a high tolerance for accepting risks, or just a generally low level of organizational project risk management maturity.

The same appears to be the case with retrospectives.

I ran a one week poll in PMI's Project, Program and Portfolio Management discussion group on LinkedIn soliciting feedback from the group members on what percentage of improvement ideas had actually been implemented from the last retrospective which had been held within their teams.

Of the 42 members who answered my poll, just under two thirds of them indicated that fewer than 25% of the improvement ideas were implemented. Not a single member indicated that over 75% of the ideas had been implemented.

There are many possible causes for this including:

• The team comes up with too many ideas and is unable to prioritize which should be implemented
• The team identifies issues but no ideas to address those issues
• The team lacks the psychological safety to run experiments to test the top ideas
• The system surrounding the team impedes their ability to implement ideas
• Most of the ideas fall outside the control of the team and they are unable to convince stakeholders to implement those ideas

Regardless of the cause, given how frequently retrospectives are conducted, if so few ideas are implemented, this is a significant waste of people's time.

Perhaps teams should being to apply the old agile cliché of "Stop starting, start finishing" to the improvement ideas...

If you ever find yourself wanting to inject some energy into a cross-functional gathering of delivery staff and stakeholders, ask for their opinion on estimates. For every person who adamantly insists that estimates are needed to support proper governance, someone else will argue that the inherent wrongness of an estimate and how estimates are abused will wipe out any benefits of defining them.

I'm not here to rehash the #estimates vs. #noestimates debate, but I felt it might be useful to understand what estimation techniques are being used by teams who are using agile approaches for delivering the scope of their projects.

There are numerous ways to estimate effort, cost or duration, but given the limitations of LinkedIn's polling capability, I ran a poll in the PMI Project, Program and Portfolio Management group with only the following four choices:

• Traditional techniques - this covers the range of estimation methods commonly associated with predictive delivery including analogous, parametric and bottom-up.
• Relative sizing - this covered such techniques as story pointing, T-shirt sizing, affinity estimating and others.
• Throughput and Monte Carlo - this refers to the process of forecasting based on an understanding of how many work items of a certain size can be completed within a fixed amount of time as well as using simulations to get a confidence level on how many work items might be completed by a given date.
• #NoEstimates - whereas the original idea presented by Woody Zuill in 2012 really meant not to estimate release cost, effort or duration and to focus on delivering small, valuable work items as quickly as possible to stakeholders, it has evolved since to refer to a more realistic use of estimation only when and where it makes sense.

Given the higher level of uncertainty and complexity present in projects which lend themselves to adaptive approaches, my assumption had been that the votes would mostly be cast in the latter three categories. Traditional estimation techniques work very well when there is reliable historical data or expert judgment which is relevant within the context of the current work being done.

At the end of the voting period, there was a tie for first place between the first two categories, each getting 42% out of the 37 votes cast. Throughput and Monte Carlo received 11% of the votes and #NoEstimates only received 5%.

The low volume for #NoEstimates is not surprising. While it might be the most pragmatic way of handling things, few teams have the support from leadership, customers and governance authorities to work in this manner.

Similarly, while a throughput-based forecasting approach combined with Monte Carlo simulations might be a better empirical approach, it does have a number of prerequisites to be successfully used, and also requires a fairly mature, disciplined team for it to work well.

I was expecting to see relative sizing receiving the majority of the votes, so I was surprised to see that traditional methods continued to dominate.

Just because something is popular, doesn't mean its effective.

In 2003, Barry Boehm and Richard Turner coined the acronym C.R.A.C.K. to remind us of the key characteristics of an effective Product Owner:

• Collaborative - Are they able and willing to negotiate with stakeholders about needs, wants and priorities to come up with an optimal product scope?
• Representative - Are they able to "walk a mile in the shoes" of a given stakeholder to help team members and others understand the context behind a particular need?
• Authorized - Have they been empowered to make the majority of product prioritization decisions without the need to seek approval from higher ups?
• Committed - Have they fully bought-in to the product vision and do they have sufficient capacity to fulfill their responsibilities as a PO?
• Knowledgeable - Do they have sufficient product domain knowledge but also the organizational savvy to know who to engage, influence or persuade?

Having worked with multiple companies who have struggled with Scrum, ineffective POs are one of the more common challenges I've encountered. And while a weak team might release a product late, at a higher cost than expected, or with lower quality than desired, having the wrong PO might result in the wrong product or service being produced which has a much greater negative impact.

I've had the misfortune to witness multiple PO dysfunctions including:

• An unwillingness to consider other perspectives
• Insufficient engagement of certain key external stakeholders
• Not striking an optimal balance between time spent with external stakeholders and with the delivery team
• Having the majority of decisions approved by someone else
• Having more than one PO
• POs who are only available for Scrum events
• POs who don't respect the team's responsibilities over the "how"
• Lacking domain or organization awareness

If I had to pick the most common weakness I've observed, it was a lack of availability. They usually had someone with the right personality, knowledge and authority, but that individual was stretched too thin.

You can't fulfill the obligations of a PO off the side of your desk.

I ran a poll in the PMI LinkedIn Project, Program and Portfolio Management discussion group to learn what others had experienced. I was surprised to see that insufficient capacity did not receive the majority of the 37 votes cast. A lack of decision-making authority was reported in more than half of the responses, with knowledge gaps representing just under a quarter. Insufficient availability and an unwillingness to collaborate both received under 15% of the vote.

But when I reflected on these results, they do make sense.

You can hire someone with the right personality or knowledge. If they are a new addition to the organization, they can be mostly dedicated to being a PO. But if your organization's default decision-making culture is by committee or by escalating to the most senior leader, it takes a lot of effort to change that.

One of the clichés about Scrum is that it is "easy to understand but difficult to master".

The first part of that is obvious with the Scrum Guide is only eleven pages (if you don't count the title page, purpose and table of contents). There are three roles, three outputs and four events (five if you include sprints as an event but I prefer not to as the whole idea of events within events makes me nauseous).

The second part becomes apparent once you try to implement Scrum within an existing system. Only in very rare cases is it possible to introduce Scrum without radically affecting the team's way of working. This, by itself, is not a bad thing as improving delivery outcomes involves a certain amount of change.

However, the immutable design of Scrum is where challenges occur. On the surface, introducing a new set of events or outputs wouldn't appear to be too drastic, but when it comes to replacing existing roles, outputs and events with the Scrum ones, and implementing them as they are intended to be used is where challenges emerge.

Given my personal observations with Scrum adoption issues, I thought it would be useful to poll a larger audience on which aspect of the framework generated the most challenges. A total of 35 members of the LinkedIn PMI Project, Program and Portfolio Management community answered the poll with the following breakdown of votes:

• The events: 31%
• The roles: 31%
• The outputs/artifacts: 17%
• The 1-4 week time box: 20%

This is consistent with what I have observed.

While there might be some quality issues with sprint and product backlogs, and immature teams might not always produce an increment, it usually does not take too long for most teams to get comfortable working with these artifacts. Similarly, while there might be a need to increase sprint duration when dealing with the "real world" constraints of non-software projects, over time, teams do get better at slicing work items such that "something" of value can be produced within a short amount of time.

The biggest challenges I've seen are with the proper adoption of the Scrum events and roles.

Whether it is Daily Scrums which turn into status meetings, psychologically un-safe Sprint Retrospectives, Sprint Reviews where no external stakeholder attends or Sprint Planning which takes days to complete, the purpose behind and prerequisites for successful events get lost in implementation.

While we all want C.R.A.C.K. Product Owners, and cross-functional "whole" teams, we end up with PO's who have no decision making authority or no time, and unpredictable team member allocation from one sprint to the next.

So when we consider the large number of conditions which are required to enable Scrum to be implemented as designed, the probability that they will all be met within a typical organization is quite low.

And this is why "Scrum-but" is the default, not the exception.

There are three commonly referenced approaches for reducing schedule duration: crashing, fast tracking and scope reduction. Crashing is the addition of labor or equipment to effort-driven activities in the hopes of shortening their durations. Fast tracking involves executing activities which had discretionary dependencies in parallel (either wholly or partially). And scope reduction enables schedule compression by eliminating activities or by enabling crashing.

A few weeks ago in one of my classes, when I mentioned that crashing a schedule will generally result in cost and possibly other impacts to a project and might not improve the time lines enough to offset these impacts, a learner challenged this stating that they had worked on many projects where there were no impacts and there had been a reduction in the duration.

I qualified my initial statement by saying that the benefits would outweigh the costs if specific conditions for the activities being crashed were met including:

• They were not optimally staffed to begin with
• They are effort-driven activities
• Minimum onboarding or ramp up time was required by the added team members such that the impact to existing team members was negligible

And costs wouldn't necessarily increase if the work effort remained constant for the activities being crashed.

In the projects I've managed or supported, I've rarely seen all of these conditions met, but would accept that they might be common in certain domains.

The feedback inspired me to post a poll on PMI's LinkedIn Project, Program and Portfolio Management discussion group soliciting feedback on which of the common schedule compression techniques were most frequently used.

With a sample size of 117 responses, it was not a surprise that a combination of techniques garnered 50% of the votes as rarely does a single schedule compression technique suffice to achieve a desired duration reduction. Fast tracking was next at 20%, then scope reduction at 17% and finally crashing at 14%.

I am glad to see that crashing, which tends to be the tactic often suggested by senior stakeholders when a project won't meet a deadline, was the least popular choice. I would hope that this implies that most project managers are aware of Brooks' Law.

However, it is unfortunate that scope reduction was not the favorite option. Fast tracking usually increases the risk of rework or creating other types of waste whereas scope reduction, where contractually possible, usually reduces delivery risk.

As usual, it comes down to understanding a project's primary constraint. If schedule is truly that critical, then we shouldn't be afraid of delivering less.