After daily coordination events (a.k.a. Scrums, standups or huddles), velocity might be the most misused tool by teams new to agile and the stakeholders supporting them. Used appropriately, it can help a team to understand how much work they can complete in a fixed amount of time and thus could be used to forecast when they might be done with a release. However, being able to do so requires that three critical prerequisites are met. If any of these are not, velocity is irrelevant.
The first requirement is that the team composition and capacity should be relatively stable. You might argue that if capacity has decreased, one could pro-rate velocity based on the decrease. This assumes that we have enough capability (skills and experience-wise) across the remaining team members to complete work items, albeit at a slower pace. In the real world, teams often rely on specialists and if any of those are missing, it might not be possible to complete certain work items.
The second prerequisite is that the team needs to be working on the same product. Change those and there is no guarantee that they can continue to complete work at the same pace unless the two products are very similar.
Finally, the relative uncertainty of upcoming work items should be less than or equal to that of recent previously completed work items. If complexity or uncertainty increases over time, velocity cannot be relied upon.
So assuming these three conditions are met, can we breathe a sigh of relief and freely use velocity?
Unfortunately there are still three ways in which velocity data can be abused by stakeholders.
Just as with any tool, there is usually one right way and many wrong ways to use velocity.
Part of tailoring our approach to delivering a project needs to consider its relative level of uncertainty. While it is not the only determinant of complexity, uncertainty is certainly a key contributing factor. And while there are other dimensions which need to be evaluated when deciding whether to utilize a predictive or adaptive life cycle, higher uncertainty would be a supporting factor for the latter.
But before finalizing a delivery approach, it is important to confirm that all key stakeholders who are directly contributing to or supporting the project are in agreement about the approach. In securing this agreement, it can be helpful to understand individual perceptions about the project's uncertainty as that may affect the stakeholder's opinion.
For example, if a project manager and team believe that the project possesses a high level of uncertainty yet the sponsor does not, it might be a hard sell to get support for an adaptive approach, especially if the sponsor does not have much experience with such life cycles. Even worse, if some team members feel that the project is quite straightforward and others feel it is highly complex, it can be challenging to get consensus on the approach.
Just asking individuals to give you their assessment of uncertainty is unlikely to be too useful. Anchoring and other biases will affect the outcome and understanding uncertainty at an overall level won't really help.
An alternative would be to start by defining specific areas of uncertainty which would influence how the project gets delivered (e.g. commercial viability, solution feasibility, resource availability) and then to use a similar approach to estimating poker by providing everyone with uncertainty poker cards. These cards could have the following pictures on them to represent different levels of uncertainty:
Key stakeholders will simultaneously vote on how much uncertainty exists about a given area. Similar to estimating poker, after voting, if there is agreement on the level of uncertainty you can move to the next area. If there is significant difference in perceptions for a given area, this becomes a good opportunity to discuss those.
Not only might this technique help to get alignment on the delivery approach, but it may also help to surface invalid assumptions and to address individual fears and doubts.
"Uncertainty is not an indication of poor leadership; it underscores the need for leadership." - Andy Stanley
Over the past couple of years I have regularly heard companies, their portfolios and even individual projects referred to as Complex Adaptive Systems (CAS). With a CAS, understanding of the individual components does not convey an understanding of the whole, and reductionist thinking which can work so well with simple or even complicated systems is of limited use.
Given this, I felt it was somewhat timely when I was invited to review Jonathan Sapir's new book, Thriving at the Edge of Chaos - Managing Projects as Complex Adaptive Systems.
In the first half of the book, Jonathan does a good job of covering the challenges we face when trying to apply traditional planning approaches to complex projects. His differentiation between complicated and complex contexts, the importance of systems thinking and his walk through of the Cynefin framework make these sections a good primer on the subject.
Whether it is Ian Malcolm's quote about non-linearity from Jurassic Park, the old joke about the drunk looking for his keys around a lamp post, or the analogy of a fence and treats for a dog as examples of boundaries and attractors, Jonathan provides many quotes, analogies and examples which all help to make a complex (no pun intended) topic approachable for most readers.
A number of the principles he covers in the first half of the book will resonate with both agilists and anti-fragilists including:
I liked his guidance that operating at the edge of chaos is where modern organizations should strive to be as excessive control leads to paralysis and eventual obsolescence whereas a lack of any guardrails will often result in chaos. Uber is frequently referenced in the book as almost a "poster child" for living on the edge, but I found the inclusion of Cemex and how they overcame the challenges they were facing in a traditional industry more appealing to me given that the majority of organizations are not founded to disrupt an existing business model.
The second half of the book covers Dr. Eli Goldratt's Theory of Constraints (ToC) and focuses heavily on its application in Critical Chain Project Management (CCPM).
While CCPM provides good solutions for dealing with common scheduling issues, I did feel that the book could have delved deeper in terms of applying ToC and other models to addressing some of the non-scheduling concerns caused by CAS. There could have also been some guidance provided for leaders who face the challenge where there are multiple resources who are all equally constrained. ToC works well when there is a single bottleneck but with multiple equivalent bottlenecks what should we do?
The following qualifier from the Introduction also raised some concerns: "This book applies primarily to repetitive, as opposed to one-off, never-to-be-done-again projects. It does not apply to software development projects that use agile methodology." I would argue that some of the most complex projects we have to deliver are highly unique. Also, while many of the ideas shared by Jonathan are already incorporated in agile methods, these approaches haven't fully solved CAS challenges and the book could have addressed those.
If we accept that complexity is going to continue to increase in delivery, Jonathan's book provides a solid grounding on the subject and I hope that a future revision will address some of the opportunities I've raised.
(As is often the case, one of the learners in a course I taught this week provided the inspiration for this article, so thanks Maca!).
The PMBOK® Guide, Sixth Edition defines Earned Value as "The measure of work performed expressed in terms of the budget authorized for that work." Notice that the word "value" does not show up anywhere in that definition.
On projects which are following an agile or adaptive life cycle, the expectation is that work items such as requirements or features will be completed end-to-end. This includes meeting the quality requirements of all key stakeholders so that we can be confident that we can ship the work items to a client. If a framework such as Scrum is followed, these work items are batched into Potentially Shippable Product Increments whereas on those projects which are following a continuous flow based delivery approach, we can hand them over as we go.
On these projects, while final business benefits might not have been realized yet by our customers as those will normally lag delivery by days or even months, we might claim that what we've earned is valuable.
However, when we consider projects which are following a waterfall or predictive life cycle, because of the batch, phased manner of those approaches, the time for the first customer handover of capabilities and the time between subsequent handovers is usually prolonged. As such, until we have delivered a project output which will directly enable our customers to realize business benefits from it, have we actually earned any value?
Writing a Business Requirements Document or creating a design might be necessary by-products of the delivery process but if a project is terminated with just those having been produced, its unlikely that a customer would consider they had received anything of real value.
Please don't misunderstand my point.
I believe that Earned Value Management is a valuable, objective tool for both determining a project's performance and for forecasting where we will end up when it is used appropriately. Appropriate usage includes such elements as using an objective, verifiable method for determining how much progress has been made for each work package and that prerequisites such as work package-level budgeting and financial actuals reporting are easily available.
I'm just questioning why we would use the word "value" when referring to what we have earned in the name. Perhaps, for waterfall projects, we should rename the measure to "Earned Delivery Value".
A frequently asked question in the main ProjectManagement.com community discussion group is about the perceived impacts of machine learning on project delivery.
Some contributors worry that sufficient advances in AI will render the role of a project manager obsolete whereas others remain bullish about the prospects for the profession.
A recent Harvard Business Review article by Stephen M. Kosslyn titled "Are You Developing Skills That Won’t Be Automated?" would support a positive outlook on this topic. In the article, the author asserts that roles in which emotion and context play a strong influence will still need to be performed by human beings. We have enough challenges with human leaders struggling to inspire team members or effectively align stakeholders to expect that machines will have an easier time doing so.
I'm expecting that enhancements in current machine learning technology will free us from rote administrative activities which even the most senior project manager finds themselves having to perform from time to time. While such advances might reduce a full-time requirement for project administrators on large, complex projects, it might enable such roles to support a larger number of projects at the same time.
What might projec managers do with all of this extra time?
Being assigned to more projects concurrently is not the answer! If we believe that project management is a strategic role then we should be encouraging greater focus, not less.
Freed up capacity could be better utilized on frequently neglected practice areas such as stakeholder engagement, risk management and knowledge creation. Envision the potential benefits to your projects if you had even 10% more time to devote to such practices.
We could also invest more in our own personal development or giving back to the profession or the community.
Is it possible that at some point in the future, AI will have the ability to independently manage a project staffed with humans?
This seems realistic if we agree with Gene Roddenberry's vision of intelligent sentient machines such as Commander Data, but I'm equally optimistic that the next one or two generations of project managers will have little to fear so long as they continue to invest in developing their soft skills.