How does Agile help with long term planning?

I’m often involved in discussions about Agile that question its efficacy in one way or another. This is, in my view, a very good thing and I highly encourage this line of inquiry. It’s important to challenge the assumptions behind Agile so as to counteract any complacency or expectation that it is a panacea to project management ills. Even so, with apologies to Winston Churchill, Agile is the worst form of project management…except for all the others.

Challenges like this also serve to instill a strong understanding of what an Agile mindset is, how it’s distinct from Agile frameworks, tools, and practices, and where it can best be applied. I would be the first to admit that there are projects for which a traditional waterfall approach is best. (For example, maintenance projects for nuclear power reactors. From experience, I can say traditional waterfall project management is clearly the superior approach in this context.)

A frequent challenge the idea that with Agile it is difficult to do any long-term planning.

Consider the notion of vanity vs actionable metrics. In many respects, large or long-term plans represent a vanity leading metric. The more detail added to a plan, the more people tend to believe and behave as if such plans are an accurate reflection of what will actually happen. “Surprised” doesn’t adequately describe the reaction when reality informs managers and leaders of the hard truth. I worked a multi-million dollar project many years ago for a Fortune 500 company that ended up being canceled. Years of very hard work by hundreds of people down the drain because projected revenues based on a software product design over seven years old were never going to materialize. Customers no longer wanted or needed what the product was offering. Our “solution” no longer had a problem to solve.

Agile – particularly more recent thinking around the values and principles in the Manifesto – acknowledges the cognitive biases in play with long-term plans and attempts to put practices in place that compensate for the risks they introduce into project management. One such bias is reflected in the planning fallacy – the further out the planning window extends into the future, the less accurate the plan. An iterative approach to solving problems (some of which just happen to use software) challenges development teams on up through managers and company leaders to reassess their direction and make much smaller course corrections to accommodate what’s being learned. As you can well imagine, we may have worked out how to do this in the highly controlled and somewhat predictable domain of software development, however, the critical areas for growth and Agile applicability are at the management and leadership levels of the business.

Another important aspect the Agile mindset is reflected in the Cone of Uncertainty. It is a deliberate, intentional recognition of the role of uncertainty in project management. Yes, the goal is to squeeze out as much uncertainty (and therefore risk) as possible, but there are limits. With a traditional project management plan, it may look like everything has been accounted for, but the rest of the world isn’t obligated to follow the plan laid out by a team or a company. In essence, an Agile mindset says, “Lift your gaze up off of the plan (the map) and look around for better, newer, more accurate information (the territory.) Then, update the plan and adjust course accordingly.” In Agile-speak, this is what is behind phrases like “delivery dates emerge.”

Final thought: You’ll probably hear me say many times that nothing in the Agile Manifesto can be taken in isolation. It’s a working system and some parts if it are more relevant than others depending on the project and the timing. So consider what I’ve presented here in concert with the Agile practices of developing good product visions and sprint goals. Product vision and sprint goals keep the project moving in the desired direction without holding it on an iron-rails-track that cannot be changed without a great deal of effort, if at all.

So, to answer the question in the post title, Agile helps with long term planning by first recognizing the the risks inherent in such plans and implementing process changes that mitigate or eliminate those risks. Unpacking that sentences would consist of listing all the risks inherent with long-term planning and the mechanics behind and reasons why scrum, XP, SAFe, LeSS, etc., etc., etc. have been developed.


Image by Lorri Lang from Pixabay

The Changeability Decision Matrix

Responding to change over following a planThe Agile Manifesto

That’s one of the four values to the Agile Manifesto. It’s also one of the values that is commonly plucked from the context of three other values and twelve principles. Once isolated, it’s exaggerated and inflated to some form of “We can’t define scope before we start work! There’s too much discovery work to be done first! We don’t know what we don’t know! Scope (and requirements) are emergent!” That bends the intent of the Manifesto and disregards the context from which a single value has been extracted.

I don’t believe Agile practices ever meant for software development to be a free-for-all, a never ending saga of finding and implementing better and better ways to code something before a product can be released. Projects run like this never see the light of day, let alone a shelf to languish on waiting for a long since departed market opportunity.

What isn’t in the Agile Manifesto, but is implicit in the Agile methodologies I’ve worked with is the notion of decision points. These are the points around which change, to a small or large degree, is not allowed. At least not for a while. Decision points bring stability to the development process from which Agile teams can move forward with a stable set of assumptions. If subsequent discoveries inform the team that they need to revisit a decision, than they must do so. The key element is that the work subsequent to the decision is what generates the need to revisit the decision. It isn’t done arbitrary, on a hunch, or with minimal information.

There are numerous decision points that exist within Scrum and SAFe, for example. Stories are decisions. “We need to create this thing.” Acceptance criteria, definitions of ready and done, sprint duration, feature and epic definitions, milestones, minimum viable/valuable products are also examples of decisions. Some of these can be quite changeable. Stories, for example, can be refined many times prior to and during sprint planning. The description, acceptance criteria, definition of done, and effort estimation can change many times before a story is committed to a sprint. And there’s the decision point. When the team agrees that a story can be brought into a sprint and they commit to completing it before the sprint is over, they have made a decision and the story shouldn’t change on its way to being completed by the team. (As noted previously, the work on the story may reveal a need to change something about the story – maybe even indicate that work on the story should stop – but that should be an edge case and not part of common practice.)

To help teams understand these distinctions, I’ve developed a 2X2 matrix called the Changeability Decision Matrix. Its purpose is to help teams evaluate the effects of changing work in the queue. The horizontal axis goes from “Small Impact” to “Big Impact.” The vertical axis goes from “Few Changes” to “Many Changes.”

The two questions the team needs to ask when thinking about changing a decision they’ve made (acceptance criteria, story description, MVP, etc.) are:

  • Will this change have a small or big impact? They may consider any number of variables: cost, time, productivity, effort, etc.
  • Will this change require a few or many changes (lines of code, documentation updates, other components that consume the code, budgets, release dates, etc.)

Where the proposed change resides on the grid may be dependent on where the team is on the project timeline. Consider the Epic, feature, and story hierarchy: Early in the project – during the design phase, for example – there may be little more than features in the backlog. As placeholders for ideas, they may be quite volatile as new marketing information enters the conversation or obvious technical issues become apparent. So changing an epic or a feature may have a relatively small impact on the project and involve few changes. Most probably there won’t be any code involved at this point.

As the project progress and backlog refinement continues, epics and features will be broken up into large stories. More detail is added to the backlog and more time and money has been invested in the design so the epics and features are less changeable. If any changes are needed, it is probably that the impact of those changes and the number of things that need to change will be greater than it would have been during the design phase.

Eventually, as the project moves into high gear, the backlog will become populated with more and more smaller stories that can be easily estimated and planned into sprints and increments.

For the duration of the project, it’s likely most of the stories in the backlog can and should be responsive to multiple changes…right up to the point the decision is made to drop the story into a sprint.

The Changeability Decision Matrix is an easy way to evaluate whether or not an Agile team is pondering undoing a small or large decision by forcing the conversation around the consequences of making the change. If either of these two axis are not a good fit for your organization or what you consider important to consider, then change them to something that makes more sense to your project.

Here is a representation of these phases on a hypothetical project timeline:See also:


Photo by Linus Nylund on Unsplash

Teams, Tribes, and Community – 0.1.0

Several months ago, I made bold decision: Take command of the helm for a brilliant tribe of diverse creative thinkers dedicated to helping each other succeed. This is the first of an on-going series of posts – maybe once or twice a month – describing this evolving effort.

For an extrovert, this might not have been a bold decision. But in my case, you should know I designed the card that card-carrying introverts carry. So this decision involved a more thorough application of my already robust decision-making process. On a professional level, this may be the most significant challenge I’ve taken on to date. Will my years of experience with forming and guiding teams help this tribe further their success? Will I be able to find the gravitational force that holds us together and the spark that keeps us inspired? These are open questions. They are also questions that occupy much of my thinking.

We are not dedicated to achieving a single goal or moving in a unified direction. We each have our areas of expertise and independent business goals. We are much more a tribe than a team. As such, I believe we will be guided more by tribal dynamics and models than team rules and policies. The path is not clear, but this much I know…

  • There is no leader of this tribe. Not in the sense of a single person who’s responsible for setting the direction and making all the decisions that impact the organization. There is no “Chief” or “Czar” of anything. I’ll fill the role of Launch Commander and Flight Commander in order to get us organized and moving forward. However, I have been clear from the start about my intention to structure our tribe on principles of self-organization.
  • The emphasis is on simple and accessible technology and easy ways to organize meetings based on Agile principles and practices – lean coffee, for example, has served us well for our initial meetings. What has emerged since then are more involved and interactive meeting formats, such as client role-plays and accountability exercises. Keeping things simple and remaining mindful of barriers to participation is vital. Too many tools with too many logins risks the creation of a Tower of Babel. For now, the weekly video call is the center-point around which we all meet. This in itself is enough of a challenge given the global participation. Other than this, email is the acknowledged primary channel for asynchronous communication.
  • We are not accepting new members. Whether or for how long this remains the case is undecided. We have discussed various ways of introducing new members, but have decided to decide on this issue later. The circumstances that brought each of us together created a unique bond of trust and familiarity with each other’s business interests that makes the introduction of new members a risk to maintaining these relationships. At the moment, we are tipped slightly toward being on the large size and everyone acknowledges if we grow much bigger the meetings may become unmanageable and the interactions less valuable. Since trust is foundational, none of the details related to who we are and what we discuss will be revealed in this space. My writing will be limited to the general case of what I discover from having participated in and helped guide our tribe. It is my hope this may help others with forming and guiding their own teams and tribes.

Whatever the outcome, it’s been more fun thus far than I’ve had in a loooooong time.


Image by Youssef Jheir from Pixabay

Agile and Changing Requirements or Design

I hear this (or some version) more frequently in recent years than in past:

Agile is all about changing requirements at anytime during a project, even at the very end.

I attribute the increased frequency to the increased popularity of Agile methods and practices.

That the “Responding to change over following a plan” Agile Manifesto value is cherry picked so frequently is probably due to a couple of factors:

  • It’s human nature for a person to resist being cornered into doing something they don’t want to do. So this value gets them out of performing a task.
  • The person doesn’t understand the problem or doesn’t have a solution. So this value buys them time to figure out how to solve the problem. Once they do have a solution, well, it’s time to change the design or the requirements to fit the solution. This reason isn’t necessary bad unless it’s the de facto solution strategy.

The intent behind the “Responding to change” value, and the way successful Agile is practiced, does not allow for constant and unending change. If this were otherwise nothing would ever be completed and certainly nothing would ever be released to the market.

I’m not going to rehash the importance of the preposition in the value statement. Any need to explain the relativity implied by it’s use has become a useful signal for me to spend my energies elsewhere. But for those who are not challenged by the grammar, I’d like to say a few thing about how to know when change is appropriate and when it’s important to follow a plan.

The key is recognizing and tracking decision points. With traditional project management, decisions are built-in to the project plan. Every possible bit of work is defined and laid out on a Gantt chart, like the steel rails of a train track. Deviation from this path would be actively discouraged, if it were considered at all.

Using an Agile process, decision points that consider possible changes in direction are built into the process – daily scrums, sprint planning, backlog refinement, reviews and demonstrations at the end of sprints and releases, retrospectives, acceptance criteria, definitions of done, continuous integration – these all reflect deliberate opportunities in the process to evaluate progress and determine whether any changes need to be made. These are all activities that represent decisions or agreements to lock in work definitions for short periods of time.

For example, at sprint planning, a decision is made to complete a block of work in a specified period of time – often two weeks. After that, the work is reviewed and decisions are made as to whether or not that work satisfies the sprint goal and, by extension, the product vision. At this point, the product definition is specifically opened up for feedback from the stakeholders and any proposed changes are discussed. Except under unique circumstances, changes are not introduced mid-sprint and the teams stick to the plan.

Undoing decisions or agreements only happens if there is supporting information, such as technical infeasibility or a significant market shift. Undoing decisions and agreements doesn’t happen just because “Agile is all about changing requirements.” Agile supports changing requirements when there is good reason to do so, irrespective of the original plan. With traditional project management, it’s all about following the plan and change at any point is resisted.

This is the difference. With traditional project management, decisions are built-in to the project plan. With Agile they are adapted in.


Photo by Chris Lawton on Unsplash

Fall Reflections – 2021

Over four years ago, I was in a position to retire early. After some thought, the idea didn’t suit me. I was, in the arc of my life, in an entirely novel position. I could be much more selective about where I chose to exchange my time for money. With nothing to lose and a lot to gain, I sought work with a company that would put Agile principles and my coaching skills to a rigorous test. Did I have what it takes to guide a global legacy corporation into an Agile learning organization? I ran this experiment within the software divisions of two different medical device manufacturers. The first was a 6 month engagement that ended when a better option opened up at a much larger manufacturer with more pay and less commute. I was there for three years until a layoff in the spring.

So it is I’ve come to wrapping up an extremely active spring and summer after having tripped a wire that launched me into a career shift about six months earlier than planned – a span of time I’m affectionately calling an unplanned sabbatical. I’m still not ready to retire, but I’m in an even stronger position then I was four years ago – the silent advantage of a Stoic minimalist lifestyle. Shedding the corporate baggage has opened up a universe of space and time for unfettered thought and exploration. Sabbaticals should be integrated into the work lives of every employee who demonstrates integrity and a strong work ethic.

In the coming months, I’ll be writing more about what this new direction involves. A change in direction doesn’t begin to capture the shift. There’s a multi-leveling up in play, too. This fall and winter – seasons ideally suited for deep reflection and planning – will see a continued pace of activity and preparation. Belying the quite stillness of winter, I will be extremely busy moving fieldstones into position and crafting a renewed foundation for success.

The purpose and mission I declared at the very beginning of 2020 is still in place. When I crafted that mission I was at the very beginning of a grand experiment, full of optimism and yet fully aware of the daunting task ahead. The company I was working for presented me with choice: I could accept a new management role or pursue a stated goal of mine to create an official Agile Coach position within the software group. The organization had just created an official scrum master role in the org chart, but the PMO was strongly resisting the idea of an official product owner role. I was an epic turf battle.

The management path offered greater security but had significant downsides. Not only would I have the decidedly unpleasant task of managing people in a highly regulated and bureaucratic organization, I would also be expected to fill in the scrum master gaps on various teams. This sounded like a good way to end my career as an Agile Coach.

The coach path offered the highly appealing challenge of implementing Agile and SAFe in a 60 year old medical device manufacturer. The known risks included a certain tsunami of resistance. I’d be out on a limb, working to navigate in uncharted and dangerous waters. But I had excellent support. The arrival of a new CEO broke up many of the old ways of organizing software development and opened a window of opportunity. After a rigorous decision process, I chose the Agile Coach path. My 2020 mission reflects the enthusiasm I had for having made this choice.

Then things went sideways. The new CEO brought a much bigger broom than anyone imagined and my key executive support left the organization. Two new senior execs were hired that had a rather stunted understanding of Agile, SAFe, and working with software professionals. Progress stalled as head nods and “Yeah, we’ll get to that.” can-kicking substituted for action. A lot of really good people started to leave the organization, including what was left of my support and allies. A deeply disturbing experience while serving as the Unofficial Official Agile Coach and the effects of the pandemic lock-down sunk the Agile Coach boat. The bubble I placed myself on became more so. I’m surprised I wasn’t laid-off sooner.

The period since separating from my previous employer in early 2021 has been a period of immensely positive growth. The gain in perspective on the prior three years has enlightened me to just how toxic the work environment was. Taking that job was an experiment and in the end the primary failure was not discovering sooner that the experiment was destine to fail. My optimism was misplaced. I trusted untrustworthy people. The greater sadness is that the organization has a wonderful mission and excellent products, each held back from what they could be by a select few and their caustic alliances within the organization. My health and well-being are much the better for having left on their dime.

 I finished my 2020 declaration with “Here’s to moving into 2020 with mind and eyes wide open.” And so I did. Where to next will be on my terms. Free from people who talk inclusion but practice exclusion, talk diversity but practice conformity, talk about change but fight for stagnation, and talk about collaboration while protecting their tiny fiefdoms with vindictive ruthlessness. My tuned purpose and mission for 2022 will reflect this. And a good start will be to conduct business operations in ways that are aligned with the Mission Protocol.


Photo Credit: Original, Copyright © 2021, Gregory Paul Engel

Systems Thinking, Project Management, and Agile – Part 8: Design Changes and Scope

[For this series, it will help to have read “System Dynamics and Causal Loop Diagrams 101.”]

For the conclusion of this series, I’ll look at several other levers that management can control when working to keep their teams in good health: Design and scope changes.

Changes in design can either be tightly or loosely coupled to changes in scope. In general, you can’t change one without changing the other. This is how I think of design and scope. Others think of them differently.

Few people intentionally change the scope of a project. Design changes, however, are usually intentional and frequent. They are also usually small relative to the overall project design so their effect on scope and progress can go unnoticed.

Nonetheless, small design changes are additive. Accumulate enough of them and it becomes apparent that scope has been affected. Few people recognize what has happened until it’s too late. A successive string of “little UI tweaks,” a “simple” addition to handle another file format that turned out to be not-so-simple to implement, a feature request slipped in by a senior executive to please a super important client – changes like this incrementally and adversely impact the delivery team’s performance.

Scope changes primarily impact the amount of Work to Do (Figure 1). Of course, Scope changes impact other parts of the system, too. The extent depends on the size of the Scope change and how management responds to the change in Scope. Do they push out the Deadline? Do they Hire Talent?

Figure 1

The effect of Design Changes on the system are more immediate and significant. Progress slows down while the system works to understand and respond to the Design Changes. As with Scope, the effect will depend on the extent of the Design Changes introduced into the system. The amount of Work to Do will increase. The development team will need to switch focus to study the changes (Task Switching. ) If other teams are dependent on completion of prior work or are waiting for the new changes, Overlap and Concurrence will increase. To incorporate the changes mid-project, there will likely be Technical Debt incurred in order to keep the project on schedule. And if the design impacts work already completed or in progress, there will be an increase in the amount of Rework to Do for the areas impacted by the Design Changes.

Perhaps the most important secondary consequence of uncontrolled design changes is the effect on morale. Development teams love a good challenge and solving problems. But this only has a positive effect on morale if the goal posts don’t change much. If the end is perpetually just over the next hill, morale begins to suffer. This hit to morale usually happens much quicker than most managers realize.

It is better to push off non-critical design changes to a future release. This very act often serves as a clear demonstration to development teams that management is actively working to control scope and can have a positive effect on the team’s morale, even if they are under a heavy workload.


Photo by Ariel Pilotto on Unsplash

Systems Thinking, Project Management, and Agile – Part 7: Taming the Wild Horses

[For this series, it will help to have read “System Dynamics and Causal Loop Diagrams 101.”]

Over the years I have come to regard projects as a boat in the ocean and relationships as the ocean.Michael Wade

Remember the phrases from earlier in the article series? Here they are again.

  • “We’re not moving the delivery date.”
  • “We’ll just have to work harder.”
  • “The team will have to put in more time until we’re caught up.”
  • “We’ll need more people on the project.”
  • “The team will have to work faster.”
  • “We’re to the point of exhaustion.”
  • “I’m losing track of all the pieces.”
  • “There’s no time for training.”
  • “Where did those errors come from?”
  • “We’re waiting on another team.”
  • “Another person quit the company?!?!”
  • “I don’t care. I get done what I get done when I get it done.”

How much more meaningful these are to you now that you understand a little more about the system dynamics that drive projects. Choose just one of these and find where it’s reflected in the model. (Figure 1)1.

Figure 1

Now follow the impact and consequences around the various feedback loops. Reflect for a moment an ask yourself, “What can I do to help keep the system healthy and productive in light of what I now know may be happening?” There’s a lot to consider. We’ll cover several options in this article.

Moving from the outside in, the most visible nodes in the system are also influenced the least by direct intervention. These are Morale, Fatigue, and Experience. “The beatings will continue until morale improves” is, I hope, recognized as a cynical joke. While offering free coffee, Red Bull, and unlimited M&Ms may perk up employees in the short term, the long term health consequences are grim indeed. As for Experience, well, that just takes time and a great deal of effort to fully shape and mature.

Attempting to alter these nodes directly is likely to be wasted effort at best and more probably harmful. Even if some cursory improvement can be made, the underlying systemic influences – the true drivers – will still be present and will exert a far more powerful influence. It’s Conway’s Law, pure and simple. It’s better to thinking of Morale, Fatigue, and Experience as symptoms or indicators to be recognized and tracked rather than root causes to be treated. As indicators, they are incredibility powerful sources of information on whether or not changes made to other parts of the system are being successful. They are to be used, not abused.

We’ll begin by working backward from the disaster that was built up over the last several articles in the series. Let’s imagine we have a demoralized team (or teams) that are exhausted and burdened with an impossible delivery schedule. As it stands, it’s unfixable.  A sprinter has a better chance of breaking the three minute mile than this team has in delivering their project by the stated delivery date.

Let’s also assume the choice is to continue the project. The two major actions for management at the is point are to move the Deadline and reduce the amount of Work to Do in the system. These aren’t choices, they’re actions that need to be engaged thoughtfully.

Simply moving the date to some point in the future that seems “doable” is yet another gamble. Neither will moving the date instantly resolve the other systemic issues. There is a considerable amount of recovery and rebuilding to be completed. It takes time to hire the people needed to rebuild the workforce. It takes time to rebuild trust and morale among the employees that remain. Moving the deadline out will begin to relieve pressure, but it will take time for the inflamed system to cool down and find an optimal working temperature.

The challenge for this first step is: How can you go about finding what is a reasonable date for the deadline? Answering this question is dependent on what is learned by looking to other parts of the system model for data.

  • How depleted is the Workforce and how long will it take to build it back up?
  • How much of the critical talent has remained with the organization (Experience)?
  • Is any compensation (time or money) going to be offered to offset the Overtime put in on the project?
  • How much time will it take to refactor and refine the product backlogs such that work streams can are brought into alignment and Overlap and Concurrence and Task Switching minimized?
  • What tool and process changes need to be made to reduce the Congestion and Communication Difficulties?
  • What’s the Total Known Remaining Work in the system?

Probably, the best thing to do is to declare that for some time boxed period, there will be no deadline date while these and many other questions are explored. This will have a side benefit of signaling to the development teams that management is serious about finding a realistic date. This will help to start rebuilding trust between management and the development teams.

One of the factors to consider in determining whether a new deadline can reliably be set is the Total Known Remaining Work in the system. As has been discussed previously, increasing the Total Known Remaining Work puts pressure on the completion date. Similarly, decreasing the
Total Known Remaining Work by some means will increase the likelihood that the completion date can be met. Actions to take that will allow management to regain control of the work flow include:

  • Revisit the release schedule and take a phased approach with clearly defined minimum viable/valuable product deliverables.
  • Complete a detailed review of the work done to date to get a clear picture of the amount of technical and dark debt in the system.
  • Reassess the sales and marketing strategies so they are in clear alignment with the capabilities of the development and delivery system. What can be eliminated? What can be pushed to future releases? Eliminate “nice to have’s” from this list. Either the feature can be completed in a particular release or it can’t. Those that can’t are bumped to a future release.

It’s been shown that changes in one part of the system will affect other parts of the system, whether by design or not. In this article we’ve discussed how adjusting the Deadline and Total Known Remaining Work can affect each other and the entire system. When adjusted in a way that considers system-wide effects, they can help restore balance and predictability to the overall system.

References

1The core of the model I use to assess team and organization health is based on the work of James Lyneis and David Ford: System Dynamics Applied to Project Management, System Dynamics Review Volume 23 Number 2/3 Summer/Fall 2007


Photo by James Everitt on Unsplash

Systems Thinking, Project Management, and Agile – Part 6: “Abandon All Hope,…”

[For this series, it will help to have read “System Dynamics and Causal Loop Diagrams 101.”]

“…ye who enter here.” So reads the inscription to the Gates of Hell in Dante Alighieri’s epic poem, “Divine Comedy.” Who among us hasn’t felt on occasion that stepping across the threshold to our place of employment is like passing through the gates of Dante’s Inferno? But as the poets have told us, the way to peace is to find the path through our troubles. In this article, we’ll look into just how deeply project system dynamics can adversely affect progress and even whether or not the project is successful.

But I do want to arm the reader with a couple of rays of hope. The concluding article in this series will focus on how this system model1 can be used to good effect, how it can be used to identify problems before they grow out of control. Therein lies the path to peace. Before we get there, we need to understand several more influential feedback loops.

As the Delay to Completion becomes critical, management begins to panic. Not wanting to push the deadline out they work to influence the other three options focused on modifying the behavior of the delivery team. The end result is a team that is caught in the Work Faster, Work More, and Add People loops along with all the other associated downstream loops. The effect is compounded by the emergence of other feedback loops if teams are placed in this position for an extended period of time.

Over time, the shortcuts, hacks, and quick fixes put in place to keep the pace of progress as high as possible settle in as technical debt. They work – for now – so they don’t surface as errors for quality assurance to discover. Down the road, however, solutions hastily put in place as stop-gaps fail when later solutions require existing solutions to be more robust then they are. For example, a software method that doesn’t take advantage of multi-threading may break when a later solution needs that method to scale beyond it’s single thread capacity. The shortcut is now a defect.

Figure 1

If the technical debt remains in place for an extended period of time, it may be covered by several release layers. When it does flip to defect status due to some later stress, it can be much more time consuming and expensive to uncover. The original developer of the code may not be available or even if she is, it could take her quite a bit of time to become reacquainted with the code. This can be thought of as a form of dark debt and is reflected in the Errors Build Errors Loop (Figure 1, J).

As the teams struggle to keep up the pace of progress and reduce the Delay to Completion, work streams start to become out of sequence. One team has an easier time at crafting their solution while another, to which they are dependent on the output, hits a significant snag and is delayed several weeks. In order to stay busy, the first team starts work on something else while the second team finishes their work. When the second team delivers, the first team is not prepared to immediately shift back to their original work stream and so their deliverable is delayed even further. Meanwhile, a third team, that was dependent on the first team’s deliverable has now been delayed by the cumulative delay of the first two teams. Teams and individuals begin to take shortcuts as delivery of interim work products become out of sync with each other. The diminished focus and desynchronization of work streams leads to an increase in the Error Fraction, which in turn leads to a further Delay to Completion. This is the Haste Makes Out-of-Sequence Work Loop (Figure 1, K).

Figure 2

As the effects of the Haste Makes Out-of-Sequence Work Loop build,  team begin switching back-and-forth between work streams depending on who is making the most noise for the completion of any particular deliverable. This is the Thrash and Churn Loop (Figure 2, L). Switching from stream to stream or, in worst cases, task to task, places a tremendous burden on development teams and can do more to slow progress than almost anything else I’ve encountered in team management. Not covered in this model is the type of churn that occurs when parts of the project undergo redesign after work has begun on the existing design. Long term projects are particularly susceptible to adverse impacts from redesign as the changes are often farther reaching. The drivers behind a redesign can range from trivial (a new CTO has a personal dislike for a platform vendor) to critical (a security flaw uncovered in a core technical component.)

If all the loops described to this point in the article series are allowed to run uncorrected the system is likely to crash as the project becomes one massive firefighting effort. A key indicator for when this is happening is employee morale.

Figure 3

The increased Fatigue, the growing burden of Work/Rework to Do, the unsatisfying Task Switching between work assignments all combine to causes a decrease in team Morale. This is the Hopelessness Loop (Figure 3, M). Teams are left with a powerless feeling of being caught on a never ending treadmill. And so, stepping across the threshold to the office is like passing through the gates of Dante’s Inferno.

The ripple effect from a decrease in Morale leads to a decrease in the Workforce as employees leave the organization in search of less stressful, more satisfying work. This is the Turnover Loop (Figure 3, N). The remaining demoralized employees are even less productive and unhappy employees make more mistakes, thus increasing the Error Fraction in the system. The downstream result is that the Delay to Completion increases yet again.

If corrective action isn’t taken the law of diminishing returns becomes evident and the system collapses. The cost overruns become prohibitive and the project is cancelled. Worst case, the organization runs out of resources (money, time, or both) and goes out of business. Those are bad things. In the concluding article to this series, we look at how this model can be used to read the current state of a project’s system dynamics and explore some ways we can intervene such that the system doesn’t run out of control.

References

1The core of the model I use to assess team and organization health is based on the work of James Lyneis and David Ford: System Dynamics Applied to Project Management, System Dynamics Review Volume 23 Number 2/3 Summer/Fall 2007


Image by Myriams-Fotos from Pixabay

Systems Thinking, Project Management, and Agile – Part 5: It Lives! But it’s Out of Control!

[For this series, it will help to have read “System Dynamics and Causal Loop Diagrams 101.”]

In the previous article for this series, I described three options managers could consider if moving the project deadline was out of the question.

  1. Increase employee work intensity
  2. Call for overtime
  3. Hire people

On the face of it, they each appeared to offer a path toward returning a drifting schedule to be on time. Now let’s look a little further down the road to see what happens when the juice is applied to each of these options in turn. If we implement any of these options, what are the likely consequences?

We know that errors in the work flow are unavoidable. If we encourage or pressure the development team to finish more work in less time (the Work Faster Loop1, Figure 1, C) this will result in an increase in the errors along with an increase in the amount of Work Done.

Figure 1

This is the Haste Makes Waste Loop (Figure 1, F). In other words, the increase in Work Intensity will have a concomitant increase in the Error Fraction which means there is an increase in Errors generated. The extended consequence of pulling the Work Intensity lever is an increase in Work to Do in the form of extra Rework to Do.

OK. So Option 1 isn’t a get-out-of-jail-free card. There are strings attached. How about Option 2, call for the development team to work overtime?

Figure 2

By increasing Overtime, the risk of Fatigue increases sharply. This results in yet another increase in the Error Fraction (tired people make more mistakes than rested people) and a decrease in Productivity (tired people don’t work as efficiently as rested people.) Both slow down Progress and increases the amount of Rework to Do in the system. This is the Burnout Loop (Figure 2, G).

OK. So Option 2 doesn’t lead to sunshine and roses. There are dark clouds and weeds in the mix. Let’s give Option 3 a go, hire more people!

Figure 3

So we’ve beefed up the Workforce by hiring a bunch of people to join the team. With all those extra people in the mix we’ve also increased the overall Congestion and Communication Difficulties. The email traffic increases, everyone’s Inbox fills up faster, meeting attendee size increases along with the number of meetings. The signal to noise ratio decreases and miscommunication increases. This increases the Error Fraction, decreases Productive, and decreased Progress. End result: the Too Big to Manage Loop (Figure 3, H).

But that’s not all. By hiring extra people, we’ve activated the Expertise Dilution Loop (Figure 5, I).

Figure 5

All those new hires don’t come in off the street ready to go. They decrease the depth of Experience available to focus on making progress. Experienced employees have to slow down and assist new employees in understanding the technical systems, the architecture, and development standards. New employees will need some period of time to become familiar with the work environment, project objectives,  who’s who, and where the coffee is.

As they work to understand and gain experience with the systems, new hires will necessarily make mistakes and increase the Error Fraction. While there are more workers available to focus on the product backlog, the available expertise is spread much more thinly and is collectively less experienced until such time the new workers are up to speed with what needs to be done and how. So the errors go up and Productivity goes down. The down stream effect is often a further increase in the Delay to Completion. As the saying goes, throwing more people at the problem more often than not makes the problem worse.

OK. So no unicorns and rainbows here either. More like a lot of warthogs and rain.

Looks like the first level effects were negated by the second level consequences. That’s bad enough, but the third level consequences can be even worse in that they are often much longer lasting and much more difficult to resolve. We’ll look at those in the next article in this series.

References

1The core of the model I use to assess team and organization health is based on the work of James Lyneis and David Ford: System Dynamics Applied to Project Management, System Dynamics Review Volume 23 Number 2/3 Summer/Fall 2007


Image by Gerd Altmann from Pixabay

Systems Thinking, Project Management, and Agile – Part 4: Welcome to the Labyrinth

[For this series, it will help to have read “System Dynamics and Causal Loop Diagrams 101.”]

The capable product owners I know have at least an intuitive understanding that the challenge of guiding a project through to completion is more than a bit like Theseus on his way to defeat the Minotaur. The great product owners have a much more present awareness of the labyrinth before them. Depending on the project, the team, and the work environment, the product backlog just might be the easy piece. It’s more knowable then the myriad of ways a system can work against project success.

The purpose of this series of articles is to shine light on those wily ways of the system, to make more known what capable product owners intuit, to help you become a great product owner.1

In the previous article, we covered how a project can end up with a growing delay before completion. The obvious fix was to push out the deadline, thus erasing the delay (The Shift Deadline Loop, Figure 1, B.) Management has a strong dislike for this and often avoids changing deadlines even when faced with minimal consequences. It’s more likely there are other factors that make the consequences significantly greater. Perhaps there are budget constraints or a delivery date that is tied to a major event like the launch of a suite of related products or a conference.

So if management is faced with an unmovable deadline, the Delay to Completion must be resolved by some other means.

Figure 1

With more work to do and less time to do it, there is now a Talent Resource Deficit. X number of employees working 40 hours a week will no longer get the work done on time. Management’s next set of options lie with changing the behaviors of the development team. We’ll consider three of these options.

The first option is to put pressure on the development team to focus on work more during the time they are working. Maybe this involves tightening the work hours people are expected to be available. Or restricting remote work so team members are in close proximity for longer periods of the day in the hope of shorting the delays inherent in remote communication and problem solving. Or working to eliminate distractions in the workplace. There are many possibilities here.

Figure 2

This is the Work Faster Loop (Figure 2, C) – complete more work in less time. If the development team is more focused, the thinking goes, Productivity will increase and in turn drive an increase in Progress. More Progress leads to less Work to Do which leads to less Total Known Remaining Work which leads to less Time Required to Complete Work and a decrease in the Delay to Completion. Eventually, the Talent Resource Deficit is reduced and the development team can relax a bit.

This looks great in principle. Will get to the messy reality in a future article, but for now, we just need to understand how management typically thinks things should work.

The second option is to ask the development team work Overtime.

Figure 3

Officially, management asks. Unofficially, it isn’t presented as an option. If the development team is putting in more hours, the thinking goes, then the amount of Effort being applied to the work stream increases. As with an increase in Work Intensity, this works its way through the system to reduce the Delay to Completion and ultimately, the development team will no longer need to put in extra hours. This is the Work More Loop (Figure 3, D).

The third option is to simply hire more people to work on the development team.

Figure 4

By deciding to Hire Talent, management will increase the Workforce and once again increase the Effort aimed at increasing progress. As with the increase in Work Intensity and Overtime, this eventually manifests as a decrease in the Delay to Completion. This is the Add People Loop (Figure 4, E).

There you have it. Schedule slipping? Flip one or more of the following switches…

  1. Extend the deadline
  2. Increase employee work intensity
  3. Call for overtime
  4. Hire people

…and in short order the system will be back in balance and the project on schedule. Problem solved.

Not so fast there, young Theseus. Remember, there’s a Minotaur on the hunt for you somewhere in this labyrinth. In the next article of this series we’ll begin looking a some of the ways this simplistic machine thinking can go sideways…fast.

References

1The core of the model I use to assess team and organization health is based on the work of James Lyneis and David Ford: System Dynamics Applied to Project Management, System Dynamics Review Volume 23 Number 2/3 Summer/Fall 2007


Image by Daniel Roberts from Pixabay