Voices on Project Management

By Soma Bhattacharya

The entire purpose of creating a process is to ensure that the roadmap is followed. Everything is supposed to unfold as planned and predicted. 

But following the status quo has always been a problem for me, because we should have the courage to break it when we know it can be done better. In most cases we don’t, because that’s how we are mentally wired. 

Why do we follow the regular path? Why do we never think of breaking the process? I recently read the book The Pathless Path: Imagining a New Story for Work and Life by Paul Millerd, and that led me to believe that there are people who are questioning the status quo (of course, the percentage is very low, but still there). 

Process in most organizations or teams is something that, once determined, is just part of the routine. Numbers and reports come up every month, but no one takes the time to actually look at and question them. When that’s the path we take, the meaning of every ceremony or sync-up or meeting gets lost. Now we just do them because we are supposed to. 

So, does the process really lead you anywhere? Self-discovery? Team bonding? Dynamic teamwork? Better thinking? If the answer is no, it’s time to change the process.

Process for me triggers thinking. So instead of looking into the “tasks to get done” every day, do you want to replace it with something else? Maybe look at team deliverables with detailed data? When you run a team survey, do you want to include sensitive questions like, “Are you experiencing burnout?” And instead of pushing back the evitable, we try to create a system that allows everyone to develop insights into their own (and the team’s) performance. 

Here are some things to think about:

1. Replace the standard three daily standup questions with better questions, so the work you do is acknowledged. Focus on the work done as much as you focus on what needs to get done.

2. Team retrospectives can be done with anonymous surveys to bring out better inputs that actually improve team health. Remember, happier teams = better outputs.

3. During planning, look at how much churn happens every sprint, and why. What can be done to reduce it? Is any rework taking a toll on teams?

4. Encourage everyone to question the planning, and come up with better plans (especially the newcomers—they need to feel engaged and listened to).

5. Don’t be afraid to bring in a new way of thinking or planning if it works for everyone. 

Agile is for everyone, not just for team leads and domain experts. When everyone participates, they feel included and acknowledged—and the process brings out the best.          

By Christian Bisson

Within the realm of agile project management, the composition of a team greatly impacts its success. While all team members play a vital role, the inclusion of an external product owner (as opposed to an internal one) poses challenges that can hinder teams’ potential to deliver value to users. 

In this post, I will highlight four potential pitfalls of having a product owner external to the team, with real-life examples underscoring the benefits of an integrated team approach.

1. Misalignment and Unclear Vision

When a product owner is external to the team, misalignment and an unclear vision can arise. The absence of direct day-to-day collaboration stifles the shared understanding of project goals, priorities, and user needs. This lack of alignment makes it difficult for the team to make informed decisions and deliver a product that meets customer expectations.

Example: Imagine a software development project where the product owner is external and has limited interaction with the team. This separation hinders effective communication and prevents the product owner from gaining in-depth knowledge of the project domain. As a result, misaligned priorities and a fuzzy vision emerge, leading to a disconnect between the team's efforts and the desired outcomes.

2. Inefficient Prioritization and Decision Making

An external product owner often leads to inefficient prioritization and decision-making processes. Without a direct line of communication, the product owner's expertise and insights may not reach the team effectively. As a result, crucial decisions regarding scope, timelines and trade-offs may be delayed or misinterpreted, leading to project inefficiencies and missed opportunities.

Example: In a marketing campaign project, an external product owner who lacks real-time interaction with the team may struggle to grasp the evolving market trends and user preferences. Consequently, delays in decision making occur, preventing timely adjustments to the campaign strategy, ultimately impacting its effectiveness and return on investment.

3. Communication Gaps and Feedback Delays

With an external product owner, communication gaps and feedback delays become commonplace. The limited availability and reduced involvement of the product owner hinder continuous communication and the timely exchange of information. This results in a slower feedback loop, preventing the team from promptly addressing concerns, adapting to changing requirements, and delivering high-quality increments.

Example: In a mobile app development project, an external product owner may have competing priorities and limited availability for sprint reviews. As a result, feedback on delivered iterations may be delayed, preventing the team from incorporating valuable insights—and potentially leading to inefficient use of development resources.

4. Detached from User-Centric Mindset

When the product owner is external, the team risks losing touch with a user-centric mindset. The direct contact between the product owner and end users diminishes, inhibiting the team's understanding of user needs, preferences and pain points. Without this critical insight, the team may struggle to develop solutions that truly resonate with the target audience.

Example: Consider an e-commerce project where an external product owner has limited interactions with actual customers. The team, lacking direct access to user feedback and insights, may fail to anticipate user behavior, resulting in an e-commerce platform that falls short of meeting customers' expectations and inhibits business growth.

Conclusion

In the agile realm, the inclusion of an external product owner introduces several pitfalls that can hinder project success. Misalignment, inefficient decision making, communication gaps, and a detached user-centric mindset are among the challenges an integrated team approach aims to mitigate. By recognizing the drawbacks of an external product owner, agile teams can foster collaboration, transparency, and a deep understanding of customer needs, ultimately leading to more successful project outcomes.

The above points assume there is one external product owner for the team. However, if there are multiple external product owners in a team, all the challenges mentioned earlier become even more significant. It not only amplifies the existing issues, but also adds to the tension and confusion within the team.
 

By Dr. Lynda Bourne

The generally accepted way of assessing progress on a project, and predicting its completion, is to use a critical path method schedule. However, the CPM paradigm does not work across a wide range of projects where there is no predetermined sequence of working that must be followed. There may be a high level “road map” outlining the desired route to completion and/or specific constraints on the sequencing of parts of the work but in most agile projects, the people doing the work have a high degree of flexibility in choosing the way most of the work is accomplished.

The focus of this post is to offer a practical solution to the challenge of assessing progress, and calculating the likely completion date in agile projects.

WPM as an Alternative to ES and CPM
Work performance management (WPM) is designed as an alternative approach to project controls. It uses the same concept as earned schedule, but offers a simple, practical tool that uses project metrics that are already being used for other purposes.

The function of WPM is to assess progress and calculate a predicted completion date in a consistent, repeatable, and defensible way by comparing the amount of work achieved at a point in time with the amount of work planned to have been achieved at the same point in time. Then based on this data, you calculate an expected completion date.

The Theoretical Basis of WPM
WPM has been designed to fill an identified gap in the current controls systems used on agile projects. It is based on the same premise used in earned schedule and earned duration, and is expected to achieve a similar level of reliability by comparing the amount of work planned to be accomplished to the amount of work actually achieved in the period through to a data date (time now). However, unlike ES and ED, WPM focuses on the core elements of the work.

WPM Terminology
The terminology used for the data points in WPM is:

• WP = Work Planned               measured in an appropriate unit – cumulative over time
• WA = Work Accomplished     measured on the same basis as WP
• PC = Planned Completion     project duration in time units (days, weeks, months)
• TN = Time Now                       the number of PC time units to the date of assessment
• TE = Time Earned                   the number of PC time units to the point where WA = WP

From this information, the work performance measures are calculated as follows:

• WPV = Work Performed Variance TE - TN,
  negative values show the schedule slip in PC time units
• WPI = Work Performed Index         TE/TN,
  values less than 1.0 show less work has been accomplished than planned
• EC = Expected Completion            the expected project duration in PC time units calculated by                                      PC/WPI = EC
   

Applying WPM to a Project Using Scrum
Scheduling the work should be as realistic as possible, but in many situations a straightforward pragmatic approach will suffice. Take for example a 20-week software project that has 27 stories of various size, a total of 86 story points, and the resource planning to use two scrum teams. In the absence of any other information, you could assume:

• The first two weeks are needed for team development, planning and other start-up processes
• Sprints are expected to take two weeks each
• The last two weeks will be for contingencies, bug fixes and other finalization work

This leaves 16 weeks for productive work; therefore, the first stories should be delivered at the end of the first productive sprint, Week 4, and all stories by the end of Week 18.

This means the rate of planned production between the start of Week 2 and the end of Week 18 is 86/16 = 5.375 story points per week. Based on these assumptions, at the end of Week 4 (two weeks of production), we can expect 10+ story points to be complete, and at the end of Week 18 all 86 story points complete. The rest of the planned distribution is simply a straight line between these two points.

We know sprints will not take exactly two weeks every time (some will overrun, and occasionally some will finish early), and we also know the number of story points generated in each sprint will vary. But on average, if the two sprint teams together are not completing a bit over 5.3 story points per week, every week, the project will finish late.

Once this basic rate of production has been determined for the project, WPM measures the actual work delivered (WA) and shows the time variance at time now (TN) and uses this information to predict the expected completion (EC).

For example, at the end of Week 8, three sprints should have been completed by both teams, and we are expecting 30 story points complete. But only 23 have been delivered. Velocity calculation will indicate more sprints will be needed, and the burndown chart will show the work is behind plan. But what does this mean from a time perspective?

A look at the planned rate of production will show 23 story points should have been finished during Week 7 (the actual fraction is 7.3). Therefore, the work is 0.7 weeks (3.5 working days) late. The work performance index (WPI) is 0.9125.

Dividing the original duration (20 weeks) by the WPI suggests the revised duration for the project is 21.9178 weeks; the variance at completion is -1.9178 weeks, or 13.4 calendar days late.

If these calculations look similar, they are based on the well-tried formula used in earned value management and earned schedule—all I’ve done is shift the metric to a direct measure of the work performed.

Conclusions
WPM is designed to be a simple robust performance measurement system that will provide an accurate assessment of the project’s status from a time management perspective. It can assess how far ahead or behind plan the work currently is—and based on this information, the likely project completion date based on the assumption work will continue at the current rate

The two requirements to implement WPM are:

• A consistent metric to measure the work planned and accomplished
• A simple but robust assessment of when the work was planned to be done

The metric used can be a core deliverable (e.g., 2,000 computers replaced in an organization), or a representation of work such as “story points,” or the monetary value of the components to be delivered to the client.

Peripheral and support activities can usually be ignored when establishing the WPM metric; they rarely impact the project delivery independently. Failures in the support areas typically manifest in delays to the primary delivery metric.

Questions?
Has anyone seen or used something like this in the “real world”? I would love to hear if you have.

When facing a challenge in a project or during the evolution of your product, it's natural to look for quick solutions that can help you move forward. However, this approach can lead to "patching" the symptoms rather than addressing the root cause of the problem. 

In the context of agile software development, a good example of patching that I see trending is relying too much on the Scrum Master as a "Swiss army knife," where any problem is fixed by expecting them to compensate in some way.

While it's true that the Scrum Master is a versatile member of the team, it's important to remember that their primary responsibility is to facilitate the Scrum framework, not to be a jack-of-all-trades.

Instead of treating the Scrum Master as a catch-all role, it's crucial to find the core problem that's causing the challenge and address it directly. This may require some investigation, analysis and collaboration among the team members, but the payoff can be significant. By identifying the root cause, you can avoid repeating the same issue in the future, improve the overall quality of the product, and increase the team's productivity and morale.

So, how can you find the core problem when facing a challenge? Here are some steps that can help:

1. Define the problem. Start by clarifying what exactly the challenge is that you're facing. Is it a technical issue, a communication problem, a misalignment of expectations or something else? Write down a clear and concise description of the problem that everyone can understand.

2. Collect data. Gather information about the problem by talking to stakeholders, reviewing documentation, analyzing metrics or conducting user research. The goal is to get a holistic view of the problem, its impact and its potential causes.

3. Analyze the data. Once you have collected the data, you need to make sense of it. Look for patterns, trends and insights that can help you identify the root cause. This may require some critical thinking, brainstorming or hypothesis testing.

4. Validate the hypothesis. Once you have a working theory of what's causing the problem, test it by gathering more evidence, conducting experiments or soliciting feedback from the team. The goal is to confirm or refute your hypothesis and refine your understanding of the problem.

5. Address the root cause. Finally, once you have identified the core problem, take action to address it directly. This may involve implementing a new process, fixing a bug, improving communication or changing the team's dynamics.

Conclusion
By following these steps, you can avoid the temptation to patch the symptoms and instead focus on solving the core problem. This not only benefits the current project/product, but also builds a culture of continuous improvement and learning that can help the team succeed in the long run. 

So, the next time you face a challenge, resist the urge to rely on the Scrum Master as a Swiss army knife and instead use their expertise to facilitate the process of finding the root cause.

How do you deal with challenges?

By Lynda Bourne

Agile in its various forms is becoming mainstream, and this means an increasing number of commercial contracts are being delivered by contractors who either choose, or are required, to use an agile methodology to create their contracted deliverables. While this is probably a good thing, this shift in approach can cause a number of problems. This post is a start in looking for practical solutions to some of these issues.

Two of the core tenets of agile are welcoming change to add value, and working with the client to discuss and resolve problems. While these are highly desirable attributes that should be welcomed in any contractual situation, what happens when the relationship breaks down, as it will on occasion?

The simple answer is that every contract is subject to law, and the ultimate solution to a dispute is a trial—after which a judge will decide the outcome based on applying the law to the evidence provided to the court. The process is impartial and focused on delivering justice, but justice is not synonymous with a fair and reasonable outcome. To obtain a fair and reasonable outcome, evidence is needed that can prove (or disprove) each of the propositions being put before the court.

The core elements disputed in 90% of court cases relating to contract performance are about money and time. The contractor claims the client changed, or did, something(s) that increased the time and cost of completing the work under the contract; the client denies this and counterclaims that the contractor was late in finishing because it failed to properly manage the work of the contract. 

The traditional approach to solving these areas of dispute is to obtain expert evidence as to the cost of the change and the time needed to implement the change. The cost element is not particularly affected by the methodology used to deliver the work; the additional work involved in the change and its cost can still be determined. Where there are major issues is in assessing a reasonable delay.

For the last 50+ years, courts have been told—by many hundreds of experts—that the appropriate way to assess delay is by using a critical path (CPM) schedule. Critical path theory assumes that to deliver a project successfully, there is one best sequence of activities to be completed in a pre-defined way. Consequently, this arrangement of the work can be modeled in a logic network—and based on this model, the effect of any change can be assessed.

Agile approaches the work of a project from a completely different perspective. The approach assumes there is a backlog of work to be accomplished, and the best people to decide what to do next are the project team members when they are framing the next sprint or iteration. Ideally, the team making these decisions will have the active participation of a client representative, but this is not always the case. The best sequence of working emerges; it is not predetermined.

There are some control tools available in agile, but diagrams such as a burndown (or burnup) chart are not able to show the effect of a client instructing the team to stop work on a feature for several weeks, or adding some new elements to the work. The instructions may have no effect (the team simply works on other things), or they may have a major effect. The problem is quantifying the effect to a standard that will be accepted as evidence in court proceedings. CPM has major flaws, but it can be used to show a precise delay as a specific consequence of a change in the logic diagram. Nothing similar seems to have emerged in the agile domain.

The purpose of this post is twofold. The first is to raise the issue. Hoping there will never be a major issue on an agile project that ends up in court is not good enough—hope is not a strategy. The second is to see if there are emerging concepts that can address the challenge of assessing delay and disruption in agile projects. Do you know of any?