Responsibility and Improvement

Feral chickens on the Hawaiian Island of Kaua’i are ubiquitous. And they can be aggressive, particularly when they are roaming around common outdoor eating areas.

While the vast majority of visitors to the island honor the signs that say “Don’t Feed the Chickens,” all it takes is a couple of noob’s to put the operant conditioning in motion and keep it going with each new planeload of first-time and unaware visitors.

I watched the consequences of this play out during a recent trip to the island. I was enjoying a cup of coffee and a blueberry scone at The Spot in Princeville. (Side Bar: GO HERE! The food and coffee is FANTASTIC!) A young couple, obviously new to the island, collected their breakfast order at the service window, selected a table, and then went back to the service window to get utensils, napkins, and whatever else. Left unattended for less than 5 seconds, the chickens were on the table and a sizeable rooster had made off with a croissant.

I can only describe the woman’s response as upset and indignant. She promptly returned to the service window and asked – expectantly – for a replacement. To which The Spot employee directed her attention to the sign above the service windows that said, “DO NOT LEAVE FOOD UNATTENDED. Chickens are aggressive and will attack your food if not guarded. WE ARE NOT RESPONSIBLE FOR THE CHICKENS AND CANNOT REPLACE DAMAGED FOOD FOR YOU.”

There are two (at least) lessons to be learned from this. One by the patron and one by the owner of The Spot.

First, the patron. Five bucks (or whatever a croissant costs on Kaui’i) is a very cheap price to pay for a valuable lesson about not just the chickens on Kaua’i, but the very fact that the Rules of Life from wherever your point of origin was have changed. I’ve camped on this island many time over the years and if you are not mindful of the dangers and keep the fact you are not in Kansas any more foremost in your mind, it’s easy to get into trouble. It’s a stunningly beautiful part of the planet with many hidden dangers. Slip and fall on a muddy trail, for example, can be deadly. Lack of awareness of the rip tides and undertows at the beaches can be equally deadly.

So stay alert. Be aware. Read every sign you see. Study what the locals do. Ask questions. And do a little research before traveling to Hawai’i.

For the owner of the Spot, I have this suggestion: The chicken warning sign is written in black marker on brown paper. It’s also placed high in the service window where patrons collect their order. If there is a line out the door, it typically bends away from the service window. Patrons don’t come to the service windows until their name is called. When they do, their natural line of sight is down, looking at the super scrumptious food. It is certain their attention will be drawn away from the warning sign about the chickens (#1 in the picture below) as they focus on gathering their food (#2 in the picture below.)

Fine to keep the sign in the service window, but lower it so there’s a better chance the patrons will see it. Also, put it on white paper. Even better, put a duplicate sign on the inside of the shop viewable from where customers are paying for their food. While they are standing in line waiting to place their order and reading the menu on the wall for the 12th time they are more likely to read the chicken warning sign. Maybe include a cartoon image of a rooster running off with a croissant.

This won’t “fix” the problems the unaware types bring with them onto the island, but I suspect it will cut down on the number of self-entitled noob’s demanding compensation for their lack of awareness. I’d like for The Spot to do everything they can to succeed, which means controlling costs and satisfying customers. I’d also like for the noob’s to gain some self-awareness and take that back home with them.

Win-win.

(I dropped a note to the owners of The Spot with these suggestions. They replied that they liked them and plan to implement these simple changes. If you’re in the area, send me a note, maybe with a picture, as to whether or not the sign has changed. If so, ask if the the changes made any difference! Always good to know the results of any experiment.)

Center Point: The Product Backlog

If a rock wall is what is needed, but the only material available is a large boulder, how can you go about transforming the latter into the former?

Short answer: Work.

Longer answer: Lots of work.

Whether the task is to break apart a physical boulder into pieces suitable for building a wall or breaking up an idea into actionable tasks, there is a lot of work involved. Especially if a team is inexperienced or lacks the skilled needed to successfully complete such a process.

Large ideas are difficult to work with. They are difficult to translate into action until they are broken down into more manageable pieces. That is, descriptions of work that can be organized into manageable work streams.

We choose to go to the Moon in this decade and do the other things, not because they are easy, but because they are hard; because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one we intend to win, and the others, too.President John Kennedy

That’s a pretty big boulder. In fact, it’s so big it served quite well as a “product vision” for the effort that eventually got men safely to and from the moon in 1969. Even so, Kennedy’s speech called out the effort that it would take to realize the vision. Hard work. Exceptional energy and skill. What followed in the years after Kennedy’s speech in 1962 was a whole lot of boulder-busting activity

A user story is a brief, simple statement from the perspective of the product’s end user. It’s an invitation for a conversation about the what’s needed so that the story can meet all the user’s expectations.

In it’s simplest form, this is all a product backlog is. A collection of doable user stories derived from a larger vision for the product and ordered in a way that allows for a realistic path to completion to be defined. While this is simple, creating and maintaining such a thing is difficult.

Experience has taught me that the single biggest impediment to improving a team’s performance is the lack of a well-defined and maintained product backlog. Sprint velocities remain volatile if design changes or priorities are continually clobbering sprint scope. Team morale suffers if they don’t know what they’re going to be working on sprint-to-sprint or, even worse, if the work they have completed will have to be reworked or thrown out. The list of negative ripple effects from a poor quality product backlog is a long one.


Boulder image by pen_ash from Pixabay

Crafting a Product Vision

In his book, “Crossing the Chasm,” Geoffrey Moore offers a template of sorts for crafting a product vision:

For (target customer)

Who (statement of the need or opportunity)

The (product name) is a (product category)

That (key benefit, problem-solving capability, or compelling reason to buy)

Unlike (primary competitive alternative, internal or external)

Our product/solution (statement of primary differentiation or key feature set)

To help wire this in, the following guided exercise can be helpful. Consider the following product vision statement for a fictitious software program, Checkwriter 1.0:

For the bill-paying member of the family who also uses a home PC

Who is tired fo filling out the same old checks month after month

Checkwriter is a home finance program for the PC

That automatically creates and tracks all your check-writing.

Unlike Managing Your Money, a financial analysis package,

Our product/solution is optimized specifically for home bill-paying.

Ask the team to raise their hand when an item on the following list of potential features does not fit the product/solution vision and to keep it up unless they hear an item that they feel does fit the product/solution vision. By doing this, the team is being asked, “At what point does the feature list begin to move outside the boundaries suggested by the product vision?” Most hands should go up around item #4 or #5. All hands should be up by #9. A facilitated discussion related to the transition between “fits vision” and “doesn’t fit vision” is often quite effective after this brief exercise.

  1. Logon to bank checking account
  2. Synchronize checking data
  3. Generate reconciliation reports
  4. Send and receive email
  5. Create and manage personal budget
  6. Manage customer contacts
  7. Display tutorial videos
  8. Edit videos
  9. Display the local weather forecast for the next 5 days

It should be clear that one or more of the later items on the list do not belong in Checkwriter 1.0. This is how product visions work. They provide a filter through which potential features can be run during the life of the project to determine if they are inside or outside the project’s scope of work. As powerful as this is, the product vision will only catch the larger features that threaten the project work scope. To catch the finer grain threats to scope creep, a product road map needs to be defined by the product owner.

Assessing and Tracking Team Performance – Part 8: Taming the Wild Horses

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 (click to enlarge)

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.

Previous article in the series: Assessing and Tracking Team Performance – Part 7: “Abandon All Hope,…”

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

Assessing and Tracking Team Performance – Part 7: “Abandon All Hope,…”

“…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 (click to enlarge)

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 (click to enlarge)

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 (click to enlarge)

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.

Previous article in the series: Assessing and Tracking Team Performance – Part 6: It Lives! But it’s Out of Control!

Next article in the series: Assessing and Tracking Team Performance – Part 8: Taming the Wild Horses

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

Assessing and Tracking Team Performance – Part 6: It Lives! But it’s Out of Control!

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 (click to enlarge)

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 (click to enlarge)

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 (click to enlarge)

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 (click to enlarge)

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.

Previous article in the series: Assessing and Tracking Team Performance – Part 5: Welcome to the Labyrinth

Next article in the series: Assessing and Tracking Team Performance – Part 7: “Abandon All Hope,…”

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

Assessing and Tracking Team Performance – Part 5: Welcome to the Labyrinth

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 (click to enlarge)

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 (click to enlarge)

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 (click to enlarge)

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 (click to enlarge)

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.

Previous article in the series: Assessing and Tracking Team Performance – Part 4: Let the Interactions Begin!

Next article in the series: Assessing and Tracking Team Performance – Part 6: It Lives! But it’s 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

Assessing and Tracking Team Performance – Part 4: Let the Interactions Begin!

In the previous article we learned how to read an important feature of system diagrams. Namely, the interactions – the direction and whether or not 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 (click to enlarge)

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 (click to enlarge)

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 (click to enlarge)

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 (click to enlarge)

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.

Previous article in the series: Assessing and Tracking Team Performance – Part 3: System Dynamics and Causal Loop Diagrams 101

Next article in the series: Assessing and Tracking Team Performance – Part 5: Welcome to the Labyrinth

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

Assessing and Tracking Team Performance – Part 3: System Dynamics and Causal Loop Diagrams 101

In the previous post, I introduced the work loop1.

Figure 1

Anyone familiar with systems dynamics will recognize the stocks and flows in this diagram. A stock is something that can increase or decrease over time. Work to Do, for example, is a stock that will decrease as work gets done and will increase as new or rework is added back into the stock. Flows are the rate at which each of these possible events change. With a high rate of progress and a low rate of error generation, the amount of Work to Do rapidly decreases while the amount of Work Done rapidly increases. if the rate of error generation is also high the amount of Undiscovered Rework increases. If the rate of discovery for rework is also high (as would be the case with a skilled and capable quality assurance team) than the amount of Rework to Do also rapidly increases which in turn feeds into an increase of the amount of Work to Do.

That’s the narrative version of the diagram in Figure 1.

There is another feature to system diagrams that will be important to understand as it will be key to understanding the dynamic quality of the model we’ll be building in subsequent posts. That feature is the interactions between the various elements and the effects of that interaction on stocks and flows. It is typically represented by an arrow.

Figure 2

“A” has an interaction with “B” and that interaction is in the direction of “A” to “B.” But what’s the effect of “A’s” interaction with “B?” To display this effect, a green open head arrow or a red closed head arrow is used to describe the type of interaction between the two elements.

Figure 3
Figure 4

A green open-head arrow (Figure 3) is a direct relationship. A red closed-head arrow (Figure 4) is an inverse relationship.

To help understand these relationships, consider the analogy of being in the driver’s seat of a car. Imagine the car has a constant speed of 40 miles per hour. The car has been designed to go this speed with your feet off the peddles. (Not a particularly useful design feature, I’ll grant. But this is a thought experiment. So ride along with me for a little while.) Now, when you increase (↑) pressure on the gas peddle the car’s speed increases (↑). If you decrease (↓) pressure on the gas peddle the car’s speed decreases (↓) . If you remove all pressure on the gas peddle, the car returns to the constant 40 mile per hour speed. That’s the direct relationship illustrated between “A” and “B” in Figure 3. As “A” increases, so does “B.” As “A” decreases, so does “B.”

Now for the brake. If you increase (↑) pressure on the brake peddle the car’s speed decreases (↓) – it slows down to something less than 40 miles per hour. Increase the pressure on the brake enough and the car will stop. However, if you decrease (↓) pressure on the brake the car’s speed begins to increase (↑). If you remove all pressure on the brake peddle, the car returns to the constant 40 mile per hour speed. That’s the inverse relationship illustrated between “A” and “B” in Figure 4. As “A” increases, “B” goes the opposite way and decreases. As “A” decreases, “B” goes the opposite way and increases.

Back to Figure 3 – more of “A” results in more of “B” (↑↑) while less of “A” results in less of  “B.” (↓↓) In Figure 4 – more of “A” results in of less of “B” (↑↓) while less of “A” results in more of  “B.” (↓↑)

That’s all the system dynamics you’ll need to understand the subsequent posts that begin to build out the model. The power of the model is in understanding all the various interactions and recognizing the patterns within an organization or on a team that reveal the effects of those interactions. In the next post in the series we’ll see how a few soon-to-be-named elements interact with the work loop.

Before you go, however, read through the following phrases and make a mental note of those that resonate with you – either because you have heard them before or perhaps because you have uttered them yourself while working on a project.

  • “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.”

Previous article in the series: Assessing and Tracking Team Performance – Part 2: Work, Work, Work…

Next article in the the series: Assessing and Tracking Team Performance – Part 4: Let the Interactions Begin!

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

Assessing and Tracking Team Performance – Part 2: Work, Work, Work…

…work, work, work. It’s what we do.

“I have to go to work.”

“What do you do for work?”

“OK, team. Let’s get to work.”

“Where do you work?

“Is that working for you?”

“That’ll never work.”

“Let’s work together.”

“Time to roll up our sleeves and get to work.”

The notion of work is so pervasive it underpins my belief that Agile principles and practices can be applied to a variety of human endeavors beyond the narrow focus on software development. In fact, the case can be made that Agile principles and practices have been around for millennia and only very recently were codified for a software development context. Agile simply feels more natural, more aligned with how humans think and interact to solve problems. From the way we explore and learn as children to the way we solve problems at home as adults, it’s much easier to recognize Agile patterns than waterfall patterns. Somehow, when we go to work we’re subject to the behaviors and measures of machines and Taylorism.

It doesn’t have to be that way. Agile has been shown to more effective at increasing productivity and decreasing costs in contexts beyond software. So why isn’t it practiced everywhere all the time?

I can think of a couple of broad generalizations that answer this question. First, Agile isn’t a panacea. Nothing is. To paraphrase Winston Churchill, Agile is the worst form of project management, except for all the others. Second, in the light of Conway’s Law and Shalloway’s Corollary, the systemic monster pushing back on change is a formidable one.

I have no aspirations of making Agile a panacea and will never claim it to be one. But until something more promising comes along, I can work to improve the practices for applying Agile values and principles. As for the systemic monster, that’s what this series of articles are about.

Monsters are scary because we don’t know them, we can’t see them, they’re hidden from us, they’re “out there, somewhere.” We’ll begin the process of understanding the systemic workplace monster by shining a light on work. What is it? How do we define it?

With each new day, in one form or another, we face a newly filled box of Work to Do. On the far side of the day, there is an empty box of Work Done.

In a perfect world, by the end of the day, Work to Do is empty and Work Done is full.

This transition doesn’t happen by itself. Magic won’t get work moved to done. There’s effort involved. More effort means more progress. Less effort, less progress. On Agile software projects, Work to Do is described in the product backlog and Work Done manifests as a deliverable product or service.

Typically, there is some form of measure on progress toward the goal of getting work to done. In scrum, this might be story points completed or business value delivered.

But we don’t live in a perfect world. Whatever the endeavor, errors and mistakes are part of the work effort. Instructions were unclear or incomplete, time constraints caused the work to be rushed, the person doing the work was apathetic or otherwise unfocused – there are thousands of reasons for why some of the work fails to meet expectations.

Since our efforts to complete work are always less than perfect by some percentage, part of the effort that creates progress is also an effort that generates errors. Anyone managing a project – especially a technical project – should expect that there is a box of Undiscovered Rework hiding somewhere. How big that box is or how fast it’s filling are unknown. All we know at this point is the box of Undiscovered Rework exists. In software development, the contents of this box are referred to as defects or bugs.

We know the box of Undiscovered Rework is there somewhere. So now we need a deliberate effort aimed at discovering that rework. This is the job of quality assurance and testing professionals. Their efforts at rework discovery bring the defects and errors to light so that they can be documented and added to the flow of Work to Do.

This is the work loop.1 Human interactions and behaviors aimed at achieving some larger goal provide the energy for driving this loop. The quality of those interactions determine how fast work moves through this loop.

In subsequent posts, we’ll begin to explore several specific human interactions and behaviors the can either support or inhibit the flow of work through this loop. But first, a sidebar to learn how to read the diagrams that follow. We’ll cover that in the next post of this series.

Previous article in the series: Assessing and Tracking Team Performance – Part 1: The Revenge of Frankenagile

Next article in the series: Assessing and Tracking Team Performance – Part 3: System Dynamics and Causal Loop Diagrams 101

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