I have been reading a lot about of the recent group discussions and papers regarding Kanban and Lean Software Development. One of the things I have noticed is that there is not a consistent application of the concepts regarding time. One of the reasons we establish a body of knowledge is to create a common language that helps us communicate based on a shared understanding. This inconsistency in the use of terms around time create a gap in understanding. In an effort to help the conversation here are the appropriate definitions for each type of time.

Durations

Duration is simply a measure of elapsed time.

Lead Time: The average time it takes for one unit to go through the entire process – from start to finish – including time waiting between sub-processes. Lead time can take different perspectives.

Development Lead Time is the time it takes for a unit to go through development from release from the backlog until it is done (which includes analysis, development, test, acceptance, deployment – but maybe not release to production). It is interesting to the development manager.

Order Lead Time is the time that elapses between when the customer places an order and when the customer receives what they ordered. In cases where requests are queued in a back log and releases are decoupled from development completion this can be far longer than the Development Lead Time. This is interesting to customer.

Order to Cash Lead Time is the time from when the customer places the order to the time cash is received by the business. While this is often longer than the Order Lead Time it can be shorter than the Order Lead Time when the customer prepays. This is interesting to the person paying the bills.

Process Lead Time: The time the unit is being worked on in a specific process before it is passed on to the next process. For example, within Development Lead Time this could be analysis, development, automated test, acceptance test or deployment time. This is interesting to the person performing the specific process or activity.

Processing Time: The time the unit is actually being worked on. It would be the sum of all the Process Lead Times. This is interesting to use as we try to improve our Lead Time.

Value Add Time: The Processing Time spent on a unit that transforms the unit in a way that the customer is willing to pay for. Not all Processing Time is Value Add Time – although non-Value Add Time can be necessary due to compliance requirements, to optimize performance of value add resources, and to minimize rework. This is interesting as it has been the subject of much of the lightweight process effort in Agile development. When taken to far it results in increased Rework Time and increased Process Lead Time.

Rework Time: The Processing Time that results from poor quality.  Failure Demand is the amount of resource that is consumed by Rework Time. This is interesting as it is expensive.

Queue Time: The time a unit sits between sub-processes waiting for someone to work on it. This is interesting to us as we try to improve our Lead Time. This is no cost to improving flow to reduce Queue Time but it reduces Lead Time.

Cadences

Cadence is a measure of time per unit.

Cycle Time: The average time between units coming out the end of the pipe. This is interesting because it helps us predict Lead Time.

Takt Time: How often units need to come out the end of the pipe to meet customer demand. This is interesting because it reflects the rate we need to produce to optimize investment against revenue.

You would expect Lead Time to be the sum of Processing Time, Queue Time, and Rework Time – and it is in a purely serial process flow. But in cases where work moves in parallel the sum of Processing Time, Queue Time and Rework Time will be greater than the Lead Time. Lead Time is interesting because it is what we use to make commitments.  Improving Lead Time can be done by reducing Queue Time, shortening Process Lead Time, eliminating Rework Time, minimizing non-Value Add Time, and performing processes in parallel.

The concept of Value Add Time is interesting and has had strong impact on Agile processes. At some point things like documentation, planning, testing, and adding additional features are not adding value in a way the customer is willing to pay for. Reducing these items to the bare minimum time that is necessary to meet the needs of the customer is helpful. Reducing them to the point they increase rework or reduce the productivity of the value added performers is not helpful.

The biggest inconsistency I have noticed is the improper use of Lead Time (a duration), Cycle Time (a cadence), and Takt Time (a cadence). In summary, Lead Time is how long it takes us to build and deliver it, Cycle Time is how often a new one is produced, and Takt Time is the rate of customer demand. In a stable system, Duration and Cadence are related by Little’s Law. The cadence of Cycle Time will equal WIP divided by the duration of Lead Time.

I believe that consistent use of these terms will help us have more meaningful conversations and continue to improve the ways that we deliver software to our customers. Part of my focus over the last decade has been on reducing Lead Time through reducing WIP, Queue Time, and non-Value Add Time, improving quality to reduce Rework Time, and improving architecture, automation, and shared understanding to reduce Processing Time. Having a shared understanding for each type of time leads to productive conversations around specific techniques and improves the teams ability to focus on the right types of improvements.

There continues to be discussion about Scrum (as a brand) vs. Kanban (capital K) vs. Crystal vs. FDD, etc. If fact, I received a comment today on a March post discussing the Scrumbut test. My comment became to long and is so relevant to recent discussions that I turned it into a blog post. From my perspective these method wars tend to fall into “How Trap” discussions. How Trap discussions are not about specific outcomes you are trying to achieve and developing a situationally specific approach to achieving those outcomes.

Take a look at the Scrumbut test I learned about from Jeff Sutherland. Whether you are doing (or even like) Scrum – when viewed through an outcome lenses, these questions lead to discussion regarding clearly important outcomes. Below, I list the question category from the Scrumbut test, then the outcome that is desired from the practices described in the Scrumbut test, then a hopefully clarifying description.  The practices are detailed at the Scrumbut link.

Question 1 – Iterations: Limit Work in Process – don’t start anything you can’t finish

Question 2 – Testing within the Sprint: Maintain Code Quality – Shorten quality feedback loops to zero to maintain code quality and reduce the waste of rework

Question 3 – Agile Specification: Communicate Business Needs to Development – Ensure developers understand outcomes while minimizing coordination and transaction costs, maintain traceability to business need

Question 4 – Product Owner: Maintain Product Roadmap – The business communicates a plan of what is being built

Question 5 – Product Backlog: Prioritize Investments Based on Return – the business prioritizes work based on a current understanding of business value

Question 6 – Estimates: Provide Meaningful Effort Estimates – Understand rate the team can produce work to support planning, investment decisions, and customer commitments

Question 7 – Burndown Chart: Communicate Release Schedule – Be able to predict content and timing of future releases. This clarifies corrective action, next most valuable investment decisions, marketing decisions and customer commitments

Question 8 – Team Disruption: Maintain Productive Work Environment – Management understands and supports the focus on rapid delivery. Trust is established that the team will be able to meet current and future commitments.

Question 9 – Team: Develop an Empowered Team – The team feels empowered to make decisions about how to move forward. Management has provided sufficient guidance and direction that they trust the team will make operational and tactical decisions aligned with the best interest of the business.

Yes, Jeff has a brand he is protecting. If you think you are doing Scrum and you aren’t achieving these outcomes then you aren’t doing what was intended. Bad Scrum and Scrumbut hurts the Scrum brand. In fact, since Scrum is a dominant Agile brand, it hurts all of us trying to move Enterprises towards improved software agililty.

But, Scrum isn’t the only way to achieve these outcomes. I can map these outcomes to mature implementations of XP, DSDM, FDD, Crystal and Kanban (etc.). Now the interesting conversations sound like –

• In what situations does Kanban reduce transaction and coordination costs more than Scrum?
• In what situation does one method lead to better adoption over another? Why?
• In a specific organization, what approach to developing empowered teams and upstream trust will be most likely to succeed?

The outcomes described in the Scrumbut test can be achieved by applying specific strategies that are consistent within an organization’s environment. When these outcomes are adopted development teams tend to become more mature, better at delivering software (many times dramatically), and improve their work environment. Regardless of method, you need to be focused on the outcomes that result in improvements in productivity and find the way that works in your organization to adopt and sustain the outcomes.

Something I find interesting is the push back I hear from agile developers that process discipline will inhibit their creativity. They say, “Software development is a creative activity. If you put process rigor around it you will inhibit our creativity.” I have heard others complain about applying Lean concepts to software development. “This isn’t manufacturing,” they say, “There is no place for standard work in what we do.”

Non Sequiturs in Software Development

These statements are examples of the non sequitur fallacy. A non sequitur fallacy is where the argument is false because the conclusion (rigor will inhibit creativity) does not follow from the initial premise (software development is a creative process). We see examples of non sequitur’s every day. We see them in advertising. For example,

“Buy this car and you will be more appealing to the opposite sex”

This isn’t a true statement. The car won’t make you more appealing to the opposite sex. We may want to be –  so we believe it. But this is a logical fallacy because the conclusion (you will be more appealing) actually has no cause and effect relationship with the initial premise (Buy this car).

In fact, it is because software development is a creative process and because it isn’t manufacturing there there are a whole set of processes that must exist to drive value. It is important to focus creativity where it adds value. It is also important to create an environment where creativity can be harnessed. You may not be able to create standard work around domain specific problem solving, but I contend that the higher the level of process discipline in the team, the more reliably developers will  deliver value. Further, I believe that the lack of discipline in the following process areas is the key contributor to poor performance – particularly in new agile teams.

Areas Where Process Discipline will Drive Value

To make my point, I am going to discuss four processes areas where process discipline to the point of standard work will improve the delivery of software. “Standard Work” is defined as a simple written description of the safest, highest quality, and most efficient way known to perform a particular process or task. It is agreed by the team to be the only acceptable way to do the process it describes. It is expected to be continually improved.

This is not an exhaustive list of the processes areas where discipline is required. These are process areas that are critical to teams, regardless of your flavor of agile: quality, learning and feedback, collaboration processes, and flow management.

Quality: The purpose of Quality processes is to create an environment where it is safe to pursue creativity in domain specific problem solving. Quality processes ensure the resulting product meets the needs of the customer and supports the goals of the development team. Effective Quality processes result in a net improvement in time to value delivery. Test Driven Development, Continuous Integration, Use of Patterns, Configuration Management, and Coding Standards are examples of Quality processes. Quality processes don’t hinder creativity. Just as in manufacturing they enhance the ability to leverage creativity to deliver value.

Feedback and Learning: The purpose of Feedback and Learning processes is to inform the team about how they are performing and to identify where constraints to their performance exist. Armed with this information, the team takes corrective action to avoid problems and overcome impediments. They also identify improvements that increase their ability to deliver value. Feedback and Learning processes include maintaining Burn-down Charts, Cumulative Flow Diagrams, and Kanban Boards and performing Retrospectives and Operations Reviews. Because software development isn’t manufacturing, constant feedback and the resulting learning is necessary to ensure the Agile team is improving (or at least maintaining) its ability to deliver value to the organization. Feedback and Learning processes also provide the ability for teams to creatively improve their performance.

Collaboration: The purpose of Collaboration processes is to ensure the team has a clear understanding of what they need to deliver and have a shared understanding of the dependencies within the team. Effective Collaboration processes will dramatically improve the teams ability to create value. Sprint Planning, Daily Stand Ups, and Story Reviews are examples of Collaboration processes. Clearly, adherence and process discipline are necessary to ensure a team if performing effectively. Strict adherence to Collaboration processes does not restrict creativity.

Flow Management: The purpose of Flow Management processes is to prioritize work for the team to optimize value and to throttle the amount of work that is active within the team to optimize productivity. Management also uses Flow Management processes to understand where the business stands on commitments to stakeholders and customers. Setting Milestones, Iteration Planning, Backlog Grooming and setting WIP policies are examples of Flow Management processes. As we learned from manufacturing, following these processes with discipline can dramatically improve the rate and amount of value the team is able to produce. None of these processes restrict creativity.

Process without Purpose is the Culprit

When pursued with the appropriate purpose, process does not inhibit creativity – it enables creativity. Many of the processes and techniques that have proven to be valuable in manufacturing have also demonstrated tremendous benefit in software development organizations. The “bad-taste-in-your-mouth” feeling that developers get when discussing process discipline and standard work is the result of process for the sake of process. Don’t let that feeling sway you from putting appropriate process rigor into place. Remember, “Software development is a creative process. If you put process rigor around it you will inhibit our creativity” is a logical non sequitur. Process discipline and standard work are not inhibitors to creativity, they are enablers.

In the Agile Manifesto it says, “We are uncovering better ways of developing software by doing it and helping others do it.” I have been paying attention to the conversations between the BUFD traditionalists, the Agilists, and now the Kanban communities. This conversation has not always been friendly – and some members of each community certainly aren’t looking to learn about better ways of developing software. In fact, the contentious debates are creating obstacles to helping others do it.

I find that there are valuable capabilities in each of the practice areas. Agile was never completely different than BUFD. It was 20-30% different. And that difference, when done well in the right context, dramatically improved the value of the software being developed and the velocity that it was delivered. Kanban is probably 10-20% different than Scrum, the most prominent instance of Agile. XP doesn’t really come into the discussion because XP practices will be applied in both of the situation. In the right context, Kanban will deliver dramatically improved value and velocity over explicit Scrum. After all, some companies have moved to single-unit engineer-to-order flow over small batches and realized dramatic improvements.

As I have been wrapping my brain around the distinctions and benefits, I keep coming back to Gerald Nadler’s book from the mid 1990’s, Breakthrough Thinking: The Seven Principles of Creative Problem Solving. Nadler had developed a meta-model for problem solving (solution finding) that has consistently delivered dramatic results. I am going to share the seven principles with you and then use them to talk about why I think the principles in Kanban can deliver results that are better than teams doing Scrum.

1. Uniqueness: Every problem is unique. You can’t directly copy a solution from elsewhere. Only if the context of the purposes shows it is useful should some available solution be considered.

2. Purposes: Always and continually ask the purpose. Then ask the purpose of that purpose. Expand as far as possible with this exercise. Focusing on purpose lets the uniqueness of the situation become clear and strips away nonessential aspects of the problem context.

3. Solution-after-next: Find solutions today that achieve the focus purpose, based on what might be the solution of the future. Having a target solution I the future gives direction to near-term solutions and infuses them with larger purposes.

4. Systems: Employ a format that includes all elements and interrelationships that the target solution will entail. Every solution or system is part of a larger system, and solving one problem inevitably leads to another. Understanding the elements and dimensions that comprise a solution lets you determine in advance the complexities you must incorporate into the implementation of the solution.

5. Limited Information Collection: Before taking the time and wasting the effort to collect and analyze extensive data, determine what purposes would be achieved by gathering the data. Study the solution, not the problem.

6. People Design: Throughout the process of finding a solution, give everyone who will be affected by that solution the opportunity to take part in its development. People are willing to explore purposes and solutions-after-next, rather than to gather data about what is wrong with the current system. Those who carry out and use the solution should be intimately and continuously involved in its development. Also, the proposed solution should include only the critical details, in order to allow flexibility for those who must apply the solution.

7. Betterment Timeline: Even as you design today’s solution, schedule future changes necessary to its continuous success. The only way to preserve the vitality of a solution is to build in and then monitor a program of continual change. A sequence of purpose-directed solutions and knowledge of the solution-after-next are bridges to a better future.

Scrum explicitly calls out several of these principles, particularly uniqueness, purposes, and people design. It provides direction that you should be looking for a way to remove impediments. It doesn’t explicitly provide guidance for doing that and a good, experienced manager is already applying many of the other principles. As I was telling Mike Cottmeyer this morning, a Scrum team in the right context will (and have) evolve into (many of) the Kanban practices.

Kanban explicitly calls out the rest of these principles. The Kanban itself becomes a framework for understanding the System and focusing on just enough information. The operations review is specifically in place to establish a betterment timeline and the solution after next.

Most of the Scrum teams dislike management and the other functional groups they interface with. The concept of pigs and chickens and the common perception that management causes obstacles for the team lead to conflict and distrust. Kanban focuses on how the development team can work better across the organization. From a purposes focus and people design standpoint, the Kanban perspective leads to greater trust and a shared focus on the solution-after-next.

Finally, many Scrum teams struggle with how to schedule defects and rework into their iterations. In the iteration world, QA gets the release after the end of the iteration for acceptance testing – this creates delay in feedback. This delay leads to all the relearning problems that we all have discussing. The enforced reduction in work in process and the single-unit flow reduces rework and shortens the time to feedback on defects and acceptance issues.

According to most reports, we still aren’t great a reliably delivering technology. No one has an answer yet that works for everyone. There is a lot of room for improvement and I believe we need to keep an open mind as we uncover better ways of developing software by doing it and helping others do it.

I spent last week in Miami at the Lean & Kanban conference. There was discussion (and twitter chat) about why Lean was better than Agile for the enterprise and how Lean and Kanban are different than Agile. But many of the distinctions were debatable because you can find Agile practioners that have adapted and inspected to include many of the Lean Software practices, including Kanban. I personally don’t see Lean and Agile as competitors. Lean is about improving flow through a value stream and Agile is about writing better software. Lean can help Agile teams perform better and realize benefits from agility at the Enterprise level. What was notable at the Lean & Kanban conference was the level of sophistication and maturity of the practioners that attended. These were experienced professionals focused on improving their organizations (and clients) ability to rapidly and profitably deliver value to their customers.

Big Agile Practices Survey

I gained some insight into the discussion about the distinction between Lean and Agile as I reviewed the results of Jurgen Appelo’s survey http://www.noop.nl/2009/05/the-big-agile-practices-survey-report-part-1.html into Agile practices. Agile is considered risky or even a pejorative by many Enterprises. Many executives don’t trust it as a mature or viable approach. The lack of trust that corporations have in Agile teams is not a reflection of “management’s” ignorance. It is a reflection of software teams failing to reliably deliver the software organizations and customers need. I have decided that the problem is not with Agile itself, it is in the level of process immaturity followed by many Agile Practioners.

For example, here are the practices that are not considered Agile in the Survey. The percentage reflects the number of practitioner’s who selected the practice as an Agile practice. Less than 50% means that the majority of the community does not consider it an Agile practice.

• Configuration Management: 25.2%
• Issue Tracking: 27.4%
• Use Cases: 28.2%
• Risk Management: 29.5%
• Design by Contract: 32.2%
• Software Metrics: 32.5%
• Usage Scenarios: 37.9%
• Code Reviews: 42.3%
• Root Cause Analysis: 42.6%
• Move People Around: 42.5%

The ones that jumped off the page to me were Configuration Management, Issue Tracking, Risk Management, and Software Metrics. Building Enterprise or commercial software without caring deeply about these items is problematic. An Agile team, who is interested in continuous delivery of valuable software pretty much has to care about these items. You can’t inspect and adapt without metrics and an understanding of your issues. You can’t continue to deliver the next release without configuration management. And Agile is all about Risk Management.

In fact, you hear people who believe that Agile is a no documentation, no planning, no requirements, and no control free for all. Apparently, many of these are Agile practioners themselves.  This is incorrect. Agile is a disciplined process that, when done correctly, helps companies improve their ability to reliably deliver valuable software to the business. So how does the immature implementation of Agile become so common? There are a lot of forces at work here.  I think the lack of “maturity” in many agile teams is the result of two different forces – the reaction to bad process and the local optimization problem.

A Reaction to Bad Process

Agile, at least partially, arose as a reaction to bad process. I think the pendulum has swung too far away from responsible software practices in response to costly and painful implementations of traditional big ceremony around things like risk management, issue tracking, requirements management, and configuration management. As a reaction, some Agilists believe that just enough, just in time documentation means no documentation. It doesn’t. Or that responding to change means no planning and no requirements. Not accurate. I got a tweet today that “By definition, agile programming dispenses with process.” What? One of the things that Agile is supposed to do is to eliminate the pain of big ceremony for its own sake and embed the purposes of these processes into your daily work. But a failure to understand the principles behind the practices leads to a large community (according to the survey – a majority) who don’t build software responsibly. Agile is a high discipline, introspective, continuously improving approach focused on delivering customer value. A reaction to bad process is not an excuse for no process, it is a basis for figuring out other ways to achieve the right purpose.

Local Optimization

Local optimization is the second major force. Local optimization is where one group focuses on improving its ability to do its job at the cost of the organization. Development organizations, like most functional groups, operate within their sphere of control. They can fall into the trap of believing that the business revolves around them. In an effort to improve development performance, Agile teams implement practices they have read about or experienced without understanding how they fit into the overall value stream. Gaps arise (i.e. configuration management) when there is a lack of clarity on responsibility across the value stream. Agile teams also don’t recognize the additional strain on other parts of the organization when they implement new Agile practices.  The only time you should subordinate one functional area for another one is to elevate or eliminate a constraint.  The goal of the organization is to improve the organization’s ability to profitably deliver value to the customer, not to get better at software development.  

Agile Practioners are Solving the Wrong Problem

When implemented maturely, Agile works to improve quality, fit, reliability, and responsiveness. The forces of reaction to bad process and local optimization result in Agile teams implementing not enough process or focusing on the wrong processes. The difference in (many) Agile practioners and Lean practioners is the problem they are solving. Immature Agile practitioners are focused solely on writing code better. This is important, but not a worthy goal in and of itself. Lean practioners (and mature Agile practioners) look at the overall value stream. They strive to identify the right process (and amount of process) while focusing on eliminating waste in the value stream.  The problems with Agile are not a problem with the principles and practices of Agile. It is a problem with the perspective and purpose on the part of many Agile practioners.

Mike Cottmeyer has also been talking about scaling Agile. In his recent post on Second Order Agile Scaling he talks about how important it is to reduce the number of active projects in the portfolio. In other words, the goal is to focus on finishing projects as fast as possible, not on starting them faster or keeping your resources busy. When the organization has too many active projects at a time, it overloads the system and actually slows down delivery. You will see this when you have too many applications open on your computer. One application runs fast. Two probably still run well. But if you open ten or more applications, all of them slow down.

 In the last year I have seen a company with almost as many active projects as IT resources. Another company had the philosophy to start projects early so they wouldn’t get cut when the budgets were revisited. Not surprisingly both of these companies are late and over budget on almost every project. This is not a talent or process problem, it is a scheduling problem. When you overload the system, the resources start multi-tasking. My friend Steve defines multi-tasking as the intentional stoppage of ongoing work to transition focus to another task area. This is a bad plan. You want to avoid overloading the system with multi-tasking.

I have written about Multi-taking before. Several of my favorite bloggers have also discussed multi-tasking. Reforming Project Management, Focused Performance, and Clarke Ching often explain the dreadful impact of multi-tasking. Multi-tasking is bad for a number of reasons. I am drawing on my post at http://blogs.synaptus.com from March 2007 to discuss four of them here in the context of the current conversation.

One: Starting sooner doesn’t mean you will finish sooner.

Let’s say you have three people that want you to do something. To simplify this example, each thing takes three days to perform. You want to make everyone happy so you start working everything as soon as possible. You switch between them each day to continue to show progress on each thing. So your work looks like this.

Scenario 1: ABCABCABC

You deliver “A” on day 7. “B” on day 8. And “C” on day 9.  In trying to make everyone happy, you pushed A and B back and didn’t do C any favors. If you had worked on these things in sequence, your work would look like this.

Scenario 2: AAABBBCCC

You deliver “A” on day 3. “B” on day 6. And “C” is still delivered on day 9. Starting sooner didn’t get work done sooner.

Two: Sometimes work needs to be expedited.

It just happens. In Scenario 2 above, you could just drop the expedited work into the queue as the next thing to do. You don’t interrupt other work in progress, and you will finish it just as fast as possible. Remember, starting it as soon as possible isn’t what’s important. Finishing it as soon as possible is what’s important. Mixing expedited work into the middle of the flow will slow everyone down. Because it takes an incremental approach and working software is delivered at the end of each iteration, Agile development enables this much better than BUFD projects.

Three: Customer requirements change over time.

When you take longer to deliver work, you raise the risk that the customer requirements will change.  You want to have the shortest amount of time from when the work starts to when the work is delivered to the customer. This will reduce the risk that the customer requirements will change on work in progress. When customer requirements change on work in process, it creates rework. Rework is extremely expensive.

When you run in an Agile fashion, you will schedule epics (or big features or capabilities) into the pipeline well in advance. You have an Order of Magnitude estimate of time and cost, a general idea of what problem it addresses, and a perspective on the value of the epic (or big feature or capability) that you use for prioritization. You don’t do the detailed requirements and design until just before you drop it into the pipeline to be built. This shortened time reduces the risk that the customer will change the requirement.

Four: Task switching is expensive.

As this NY times article points out, we are not effective at getting back to productive work when we are multi-tasking. One of the tenants of lean is to eliminate waste. There are Eight Wastes defined in Lean. Multi-taking directly contributes to six of these wastes. We create Defects from forgetting what we were doing. We create Inventory from work piling up when we switch away. We create additional Processing from having to put away work and then find it again. We create Waiting (interruption of flow) and then the customer forgets what they asked for or their requirements change. We create Overproduction because we have more work started then the system can efficiently process. Finally, we create Non-Utilized Talent through the stress that is created for the developer who is always behind and having switch between tasks. Multi-tasking is a bad investment.

Following an Agile approach increases productivity because it specifically focuses on reducing these wastes. This is not accidental. When I took the Certified Scrum Master class from Jeff Sutherland he said that among other things they had intentionally drawn on proven concepts from Lean. 

Excessive multi-tasking derails productivity.

Our work lives are probably impacted by most of these issues – often in combination. The multiplying effects of multitasking are devastating to performance in organizations. You can have the right people, the best processes, and a solid strategy. Multi-tasking can derail the productivity of the group. Fixing this problem can double the productivity of a work group. In reality, you can’t eliminate multi-tasking completely. This is a complex problem to address but it is worth the investment. Taking an Agile approach to work, prioritizing completion of work over starting work, and intentionally coordinating work across functions with the intention of reducing multi-tasking are the first steps.