When Collaboration Becomes Clobber-ation

I was new on site and agreed to co-create a working session with the company Agile coach for developing the skills needed to split large stories into smaller stories. The plan was to develop the skills of the company’s scrum master pool so that they could then deliver this presentation to their teams. Given the diversity of the team projects involved, I proposed that it might be helpful to open the session with a short segment on how to size stories, just to be sure everyone had a baseline understanding. To this end and in the interests of time I offered to leverage a 10 minute presentation that I’d used successfully for several years.

“Great,” she said. “Let’s see it.”

Thirty minutes and an uncounted number of interruptions later to interject what I should do different here and where I was wrong there, I stopped trying to get through my short deck of slides. The interaction had all the feel of turf posturing and a clear need for the company coach to be the sage in the mix. I don’t mind getting thrashed by sharp or well placed feedback from a curious novice or a proven master. These insights are often the most valuable and important to learning and growth as an Agile coach. But if anyone deploys a tear-you-down-to-build-me-up strategy in the name of collaboration I’ve learned it’s best to cut my losses and walk away.

And that’s what happened here. The co-creation dissolved and the working session never occurred. Weeks later, the company coach emailed the approved deck of slides to the scrum masters with instructions to present the deck to their teams. How to do that was “in the notes.”

There were a lot of things wrong with this interaction and, indeed, with the company’s Agile implementation. But the lack of co-creation and collaboration was a core issue. Healthy and productive collaboration includes all of the following:

  • Asking many questions
  • Careful attention and listening to answers
  • Making few statements
  • Setting aside the limitations of “or” and embracing the power of “and”
  • Understanding the goals of the collaboration
  • Understanding the purpose of the collaboration
  • Respect for everyone as professionals
  • Communication that is open and uncontaminated by back channeling and triangulation
  • Patience

Photo by Ashley Jurius 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

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

Improving the Signal to Noise Ratio – In Defense of Noise

[This post follows from Improving the Signal to Noise Ratio.]

All signal all the time may not be a good thing. So I’d like to offer a defense for noise: It’s needed.

Signal is signal because there is noise. Without the presence of noise we risk living in the proverbial echo chamber. When we know what’s bad, we are better equipped to recognize what’s good. I deliberately tune into the noise on occasion for no other reason than to subject my ideas to a bit of rough and tumble. Its why I blog. Its why I participate in several select forums. “Here’s what I think, world. What say you?”

Of course, noise is noise because there is signal. Once we’ve had an experience of “better” we are then more skilled at recognizing what’s bad. I remember the food I grew up on as being good, but today I view some of it as poison (Wonder Bread anyone?) And there are subjects for which I no longer check out the noise. The exposure is too harmful.

There are subjects for which I seem to be swimming in noise and casting around for any sort of signal that suggests “better.” I’m recalling a joke about the two young fish who swim past an older fish. The older fish says to the younger fish, “The water sure is nice today.” A little further on, one of the young fish asks the other, “What’s water?” I’m hoping to catch that older fish in my net. He knows something I don’t.

To understand what I mean by noise being necessary it is important to understand the metaphor I’m using, where it applies and where it doesn’t.

Taking the metaphor literally, in the domain of electrical engineering, for example, the signal to noise ratio is indeed an established measure with clear unit definitions as to what is reflected by the ratio – decibels, for example. In this domain the goal is to push always for maximum signal and minimum noise.

In the world of biological systems, however, noise is most definitely needed. One of many examples I can think of is related to an underlying driver to evolution: mutations. In an evolving organism, anything that would potentially upset the genetic status quo is a threat to survival. Indeed, most mutations are at best benign or at worst lethal such that the organism or it’s progeny never survive and the mutation is selected against as evolutionary “noise.”

However, some mutations are a net benefit to survival and add to the evolutionary “signal.” We, as 21st Century homo sapiens, are who we are because of an uncountable number of noisy mutations that we’ll never know about because they didn’t survive. Even so, surviving mutations are not automatically “pure” signal. There are “noisy” mutations, such as that related to sickle cell anemia. Biological systems can’t recognize a mutation as “noise” or “signal” before the mutation occurs, only after, when they’ve been tested by the rough and tumble of life. This is why I speak in terms of “net benefit.”

For humans trying to find our way in the messy, sloppy world of human interactions and thought, pure signal can be just as undesirable as pure noise. I’ll defer to John Cook, who I think expresses more succinctly the idea I was clumsily trying to convey:

If you have a crackly recording, you want to remove the crackling and leave the music. If you do it well, you can remove most of the crackling effect and reveal the music, but the music signal will be slightly diminished. If you filter too aggressively, you’ll get rid of more noise, but create a dull version of the music. In the extreme, you get a single hum that’s the average of the entire recording.

This is a metaphor for life. If you only value your own opinion, you’re an idiot in the oldest sense of the word, someone in his or her own world. Your work may have a strong signal, but it also has a lot of noise. Getting even one outside opinion greatly cuts down on the noise. But it also cuts down on the signal to some extent. If you get too many opinions, the noise may be gone and the signal with it. Trying to please too many people leads to work that is offensively bland.

The goal in human systems is NOT to push always for maximum signal and minimum noise. For example, this is reflected in Justice Brandeis’s comment: “If there be time to expose through discussion the falsehood and fallacies, to avert the evil by the process of education, the remedy to be applied is more speech, not enforced silence.” So my amended thesis is: In the domain of human interactions and thought, noise is needed by anyone seeking to both evaluate and improve the quality of the signal they are following.

A final thought…

If we were to press for eliminating as much “noise” as possible from human systems much like the goal for electrical noise, I’m left with the question “Who decides what qualifies as noise?”


Photo by Jason Rosewell on Unsplash

Improving the Signal to Noise Ratio – Coda

In a Scientific American column delightfully named “The Artful Amoeba” there is an article on a little critter called the “fire chaser” beetle: How a Half-Inch Beetle Finds Fires 80 Miles Away – Fire chaser beetles’ ability to sense heat borders on the spooky

Why a creature would choose to enter a situation from which all other forest creatures are enthusiastically attempting to exit is a compelling question of natural history. But it turns out the beetle has a very good reason. Freshly burnt trees are fire chaser beetle baby food. Their only baby food.

Fire chaser beetles are thus so hell bent on that objective that they have been known to bite firefighters, mistaking them, perhaps, for unusually squishy and unpleasant-smelling trees.

This part is interesting:

A flying fire chaser beetle appears to be trying to give itself up to the authorities. Its second set of legs reach for the sky at what appears to be an awkward and uncomfortable angle.

But the beetle has a good reason. It’s getting its legs out of the way of its heat eyes, pits filled with infrared sensors tucked just behind its legs.

A strategy suggested by the fire beetle life cycle is if you want to maximize a signal to noise ratio, iterate through three simple things:

  1. Work to develop a super well defined signal/goal/objective.
  2. Remove every possible barrier to receiving information about that signal – mental, emotional, even physical – that you can think of or that you discover over time.
  3. Repeat

Also, the “Way of the Amoeba” is now the “Way of the Artful Amoeba.” Update your phrase books accordingly.


Photo by Marco Zoppi 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

Systems Thinking, Project Management, and Agile – Part 3: Let the Interactions Begin!

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

In a previous article we learned how to read an important feature of system diagrams. Namely, the interactions – the direction and whether the effect of the interaction was direct or indirect. With that understanding in hand, we can begin to look at real-life interactions. Well, real in the sense they are reflections of real-world interactions. These are interactions that take place outside the Work Loop but nonetheless affect the performance of the Work Loop.

By the time we’re done building out the model, you’ll be aware of just how many brake and gas peddles there on in this project management automobile (building on the metaphor used in the previous post for this series!)

Revisiting the Work Loop1 (indicated by the icon)…

Figure 1

We see there are several things that can interact with progress: How productive an individual or team is and how much effort they apply to their work. The green open-head arrow indicates that the relationship between each of these interactions and progress is direct. An increase in Productivity, applied Effort, or both will increase progress. Decrease Productivity or applied Effort and progress slows down.

That seems straightforward. But it isn’t all good news. Being more productive and applying more effort will also generate an unknown increase in Errors. Consequently, the amount of Undiscovered Rework will also increase.

Figure 2

This means that more effort needs to be applied toward discovering the Undiscovered Rework, so the relationship between Undiscovered Rework and the effort to actually discover the rework is direct (the green open-head arrow.) An increase in the amount of Undiscovered Rework results in an increase in the effort needed to actually discover all the hidden rework.

There is an inverse relationship in the mix here, too (the red closed-head arrow.) As the time it takes to discover defects and bugs increases, the rate of rework discovery decreases. This is particularly true with dark debt issues and defects that have been hidden in the system for months or even years. Finding gnarly bugs often takes a lot of time and effort. UI typos and misaligned text box labels, not so much.

So far, so good. But what affect does the additional work from the Rework to Do bucket have on the project schedule?

Figure 3

The system as it stands can only handle so much throughput. (Later in the article series we’ll cover ways to influence this throughput.) Adding Rework to Do to the flow of overall work that needs to be done will also slow down the rate at which original Work to Do gets to Work Done.

If project life is good the amount of Work to Do and Rework to Do decreases so that the amount of total Known Remaining Work decreases. If the amount of Work to Do and Rework to Do are increasing, the amount of total Known Remaining Work increases and project life is bad. (Figure 3)

There could be any number of causes driving the project down the bad road, hopefully only for a short while. Since we don’t know what we don’t know,  after work begins on a project discoveries are made about additional work simply by working on known work. It could also be that additional work is added to the project intentionally. Perhaps marketing has discovered a feature that could place the end product in a stronger position or an existing feature needs to be strengthened to help close a sale or a planned approach turns out to be technically unfeasible or…the list is endless.

With the increase in the amount of Known Remaining Work, and all other aspects of the project remaining unchanged, at the very least the Time Required to Complete Work will increase. This in turn pushes out the projected delivery date and therefore increases the Delay to Completion. It’s at this point management starts getting grumpy.

Call out any project management methodology devised by man and it’s a safe bet that it drives toward establishing a predictable completion or delivery date. Agile methodologies are no different. Delivery dates are the interface between work teams and management. When faced with the news that a scheduled delivery date is at risk, management has two basic choices available to them. Either change the delivery date to match the performance of the delivery team or change the behavior of the delivery team such that the originally scheduled delivery date can be met. (A blend of the two is certainly possible but not particularly common in practice.)

The most obvious choice is to make changes that directly impact the Delay to Completion. That is, change the delivery date to accommodate the delivery team’s performance.

Figure 4

This introduces our first feedback loop – the Shift Deadline Loop (Figure 4, B.)

Let’s say the amount of Total Known Remaining Work has increased such that the Delay to Completion has grown to four months. If the decision is made to push the Deadline out by four months the effect is to increase the amount of Time Remaining which in turn decreases the Delay to Completion to zero. (Savvy Agile team members recognize that the shelf life of a zero completion delay is something less than 24 hours.)

But remember, schedule delays make management and other stakeholders grumpy. They’re loath to choose this path unless it is forced upon them by having exhausted all other options. And those options usually involve putting pressure on the system at other points.

If management chooses to follow the path of changing the delivery team’s behavior, the effects can be as far reaching as they can be significant. Depending on the choices made, the effects could be either very good or very bad. Very good results are hard. Very bad results are easy and therefore much more common. We will begin to explore these in the next article for 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