Course Transcript

[Course title: Agile Key Exam Concepts. The presenter is Barbara Waters, PMI-ACP.] Agile Methodologies emphasize value-driven delivery, which strives to increase efficiency and reduce waste. This course covers the key exam concepts of Kanban, work in progress or WIP, lead time, cycle time, and Little's Law. You'll also learn about Agile Team Spaces, sharing the product vision, and identifying and reducing defects.

Back to top

1.

[Topic title: Waste Types. The presenter is Barbara Waters.] In Lean project management waste, or the Japanese term Muda, is defined as any activity or process that doesn't add value to a product, but does add cost. Lean's original Seven Forms of Waste include transportation, inventory, motion, waiting, overprocessing, overproduction, and defects. The new eighth form of waste is skills or non-utilized talent.

If you take the first letter of each of these wastes it actually spells out the name Tim Woods. This is one way to memorize the eight types of waste.

Identifying waste in your processes makes it possible to eliminate that waste and increase efficiency. What are the activities that don't add value? Let's start with transportation. Transportation waste involves unnecessary movement of goods or moving goods to different areas to complete tasks. It's the waste associated with moving these items between the various tasks. For example, in the service sector, it might be receiving the mail, opening the mail into piles, pulling out the forms, putting them into other files, and then pushing those off to be put into a computer somewhere. These are all forms of transportation delay.

Inventory is another form of waste. There are a lot of costs associated with the storage of raw materials, work in progress, and finished goods. In the service sector inventory could be a backlog of calls in a call center or requests backing up behind a department that has to approve them.

Motion waste consists of unnecessary movements, such as extra walking. This is typically a result of poor workspace design. If a worker has to make multiple trips between two workstations several times a day, it might make sense to move those workstations closer together. Waiting waste is time spent waiting for a process to finish before the next one can start.

If a department is understaffed this may create a bottleneck where work is not effectively moving through the system to the next department. Staffing too many specialists and not enough generalists can cause this problem because workers are not flexible to move between tasks. Poor staffing and scheduling issues can contribute to waiting as a form of waste.

Overproduction goes against just-in-time or JIT processing. Production should match demand. If you produce too many components and then have to store them they don't add value. Only the finished product adds value. And if the product design changes then all of that inventory may become obsolete. Stored items are therefore considered wasteful.

Overprocessing is waste due to extra steps or extra handling, overly complex designs, or excessive documentation. For example, making something perfect when good enough would've kept the operation moving along while still meeting requirements. Overprocessing can include over engineering product designs to the point that they are too complex.

Finally, it's a common complaint that some contracts or employee manuals contain far too much documentation, making it difficult to find the relevant information.

Defects are another type of waste. They may include flaws in products or a service, scrapping or rework, and unrecoverable costs. Defects are the specific flaws in the product or service that you need to deal with. And the cost of poor quality can be very high.

Skills are yet another form of waste. If employees are not working to their full potential or their talents are underutilized this is wasteful. The same is true if an organization doesn't pay attention to its people, doesn't engage them, or doesn't empower them. By underutilizing employees and not being attentive to them, an organization may fail to capitalize on the talents available to meet business goals and objectives.

Once you've identified waste in its many forms the next step is to eliminate it or reduce it significantly. Lean project management relies on employee involvement to reduce waste. Employees generally know their jobs better than anyone, and can recognize waste in their activities.

Therefore it is beneficial for management to train their employees in the concepts of lean, and to readily receive feedback, ideas, and suggestions. The goal of lean project management is to reduce waste, leaving only the activities that add value to the final deliverables.

Back to top

1.

[Topic title: The Kanban Pull System. The presenter is Barbara Waters.] In a Pull-based system, the customer demand creates what is called pull. Production or development relies on pull rather than on complicated market forecast to determine how many products to deliver.

With a pull-based system there is no wait time, and no stock is kept on hand. So if a customer wants five units, production is started once the units have been ordered, and the output is precisely five units. This allows production and the amount of work in progress to be both efficient and lean. Though it started in manufacturing, the concept of pull can be applied to almost any industry.

Kanban is based on the concept of a pull-based system. Material and information from suppliers flows into production or development, and then products flow to the customers. Once a customer makes a request the production or development begins. This is known as work in progress, and the end result of completing this work in progress is delivering the product back to the customer.

There is ongoing communication between production and development and the suppliers to ensure that the flow of material and information from suppliers matches the customer demand. The organization must work in close conjunction with its suppliers to match the pull system of units with the quantities the customer is requesting. So the whole process works in one continuous flow.

There are a number of opportunities and challenges that relate to the Kanban pull system. Some of the opportunities include reductions in areas like inventory, the amount of unnecessary work in progress, cycle time which is the amount of time between when work is started on a task and when the end result is delivered, turnaround time, and machine downtime.

Another opportunity is the increased visibility of any quality issues. Responding directly to customer demand makes an operation more efficient in every aspect, resulting in faster delivery to the customer.

There are also potential challenges with the Kanban or pull-based system. Variations in material or information, flow rates, and cycle times can make it difficult to deliver consistently. Also, any fluctuations in the market can cause a pull-based system to range from being heavily taxed at one given point in time, to underutilized at other times.

Kanban systems are often used in the real world, along with tools such as visual signs and visual control. Visual cards or visual queues indicate what needs to happen next in a system flow.

In the airline industry, for example, an airline ticket and boarding pass are both ways of indicating what needs to happen next. The boarding pass is a visual cart that indicates the gate number and at what time passengers will be loaded on to the plane. The passengers may be considered inventory, and once they are loaded on to the airplane they are considered work in progress. The airlines work very carefully to control the inventory, and pull specific quantities into the workflow in order to make the process as efficient as possible. Airline travel is much more controlled than, say, a highway, which may overload at rush hour causing inefficiencies throughout the system.

Another real-world example of Kanban is a coffee shop. Once a coffee order is placed, the cup is placed in line in the order in which it was received. There are visual queues on the cup for the person preparing the coffee so that they know what needs to be produced. No coffee is produced until it is ordered, reducing wasted inventory.

There are a number of real life Kanban examples which combined visual display and control. For example, in a checkout line at a supermarket, one of the visual displays may be a light that indicates that the register is open to serving customers. This is a visual display that is also utilized as a control, or a way of knowing what needs to happen next.

Another example of visual display in control is in a hospital. A visual display may be a whiteboard that shows the operating room schedule. It's a very clear way of showing the names of the doctor on duty, the incoming doctor, and who is available to substitute if someone is absent. Visual control may also be used throughout a hospital, including signs for the various departments or arrows on the floor indicating where to go.

In summary, visual information systems provide a means of conveying information in a simple way about the flow of processes. Signs, labels, markings painted on the floor, boards that show us what tools we need, indicator lights, and Kanban cards are all ways for you to convey information in a very visual way, without the need for verbal descriptions.

Back to top

1.

[Topic title: Kanban Boards. The presenter is Barbara Waters.] A Kanban board is a tool that agile teams often use to visualize workflow through a system. While Kanban principles are often used in IT and software development, they can be helpful in any industry.

[The Kanban Board displays. The board contains five columns and the column headers are: Customer Order Received, Payment Received, Development/Produced, Dispatched, and Delivered.] Kanban boards are an effective visual tool, and are also referred to as a visual information system. They can be used to quickly capture and display information on the status of work and tasks going through a system or a workflow. Whether created using a wall, whiteboard, or even an electronic version that may be shared with remote team members, the Kanban board is the single biggest application of Kanban in software development today.

Around the workspace of an IT or a software development department sticky notes may be displayed on the walls, depicting information visually for the team on a certain project. The individual sticky notes on the slide, also called cards, depict tasks that progress through the stages of workflow.

A team's workflow may be depicted using a table of columns and rows. The header of each column represents a stage of the workflow. For example, a team's workflow stages could be backlog or new request, design, development, testing, approval, and deployment. As cards are moved from one column to another team members as well as stakeholders have a quick way to visualize the status of each task. Many teams use color coded sticky notes to depict different categories of information. For example, yellow sticky notes may depict a new feature, a red sticky note may depict a bug or issue, and so on. Teams usually come up with their own color coding that's meaningful to them.

Creating a manual Kanban board is simple, and starts with creating a visual flow of the work. Starting with a sheet of paper or a whiteboard, a certain number of columns are created that will represent the stages of the workflow. Then the process steps are written down in order, one per column. These steps can then be used as the headers of the column. The steps can be as simple and generic as To do, Doing, and Done. Or they can be more specific. A more detailed Kanban board may include more categories, including customer order received, payment received, then developed or produced, then dispatched, and finally, delivered.

An additional option to customize a Kanban board is to create rows, also known as swim lanes that are specifically set aside for a certain category of work. For instance, one swim lane can be dedicated to bug fixes, and then another swim lane for new development work.

There are a number of software tools available that allow agile teams to create electronic Kanban boards. [The Electronic Kanban Board table displays. It contains six columns and the column headers are: New Request, Design, Development, Testing, Approval, and Deployment.] Some teams have even developed their own version of an electronic Kanban board that fits their needs.

Kanban boards may be tailored to a team's preference. For example, some teams may decide to divide each stage of the workflow into the subcategories in progress and Done to further specify the exact status of work. An item that is done is ready to be pulled into the next stage of the process, while work that is in progress is actually being worked on. By analyzing work that is sitting in a Done column, teams may be able to identify bottlenecks within the process flow and work to reduce them.

Visually organizing a team's workflow into columns to depict stages, and using sticky notes to depict tasks that move through the process is a great starting point for implementing Kanban. However, Kanban can be much more elaborately utilized.

There are a number of lean tools that can be used along with Kanban boards to introduce continuous improvement into workflows. These include the theory of constraints or identifying constraints or bottlenecks in the system and removing them; Muda or waste analysis and removal; the visual workplace which includes depicting information visually beyond the Kanban board, value stream analysis, and creating more of a pull-based system of a team's workflows.

Back to top

1.

[Topic title: Determining Lead Time and Cycle Time. The presenter is Barbara Waters.] In lean project management, one of the key concepts is process improvement. Lead time and cycle time are two important metrics that help determine how lean a process is. In other words, how much of the time dedicated to creating a product is value added.

[A flow chart displays.] Lead time is defined as the amount of time it takes between when a customer makes a request until that request is finally fulfilled and delivered to the customer. Lead time includes any delays or waiting times in-between tasks until the ticket or the request is finally delivered.

In one example of a process flow, a request is created by the client. There is a wait time or a lag time from when the ticket is created until the priority of that ticket has been set. Then there is another lag after the ticket is prioritized, until resources are available to start working on the request. Finally, the request is fulfilled and delivered to the customer. This completes the lead time for the process, from request to delivery.

The concept of cycle time is different than lead time. The cycle time is the time for when the work actually begins until the work is complete. Cycle time does not consider any of the activities leading up to the start of the work.

A comparison of lead time versus cycle time can be made using the example of an online publishing project. Online publishing includes a series of tasks, including meet with the author, read and approve the manuscript, proofing the document, the final proof read, and finally, the published document is released. Each of the tasks in the project takes a certain amount of time to complete. Adding up all of the productive time that is dedicated to doing the tasks will give you the cycle time. For example, meeting with an author may take a cycle time of one day. Reading and approving manuscripts may take three days. Proofing the documentation may take two days. The final proof read may take two days, and then posting to the internet may be a two-day process. This results in an aggregated cycle time of 10 days.

However, there are inefficiencies, wait times, and delays within the process that cause it to take far longer than the cycle time of 10 days. When these wait times are included the result could be a lead time of 30 days. Understanding cycle times and lead times is very important when determining the efficiency of a process or exploring opportunities for process improvement.

There are many benefits to reducing cycle time. One of those benefits is waste reduction. The identification and removal of waste in a process ensures that the activities being performed actually add value. This is also known as value stream mapping.

An example of value stream mapping is in a manufacturing environment. If a worker performs one specific task using a machine, it would be helpful if that same worker could be trained to maintain their own machine. If the worker needs to stop work and contact another worker from another department to make what should be a quick and easy repair, there is a lot of wasted time in waiting and delays. By training workers to maintain their own machines the cycle time can be reduced.

Another benefit to cycle time reduction is a significant cost reduction. Reducing cycle time means using fewer resources in terms of working hours, machines, or equipment. This also increases productivity. More tasks are being completed in the same amount of time.

Another benefit is quality improvement and less rework. The product time to market decreases as more product can be delivered in the same amount of time or less time. And finally, customer satisfaction is improved by setting an expectation with customers on how quickly or how much can be delivered in a given amount of time.

Many organizations have the goal of reducing their cycle times by 30% to 70%. If they are able to achieve that goal they will also see a positive financial impact on their organization. Some process improvements may translate back to the improved financial performance of the organization. By reducing cycle time by anywhere between 30% to 70%, an organization may see a better return on assets anywhere from 20% to 105%. And the time to market can be improved anywhere from 20% to 70%. Cycle times and lead times are an important measure when implementing Kanban and a pull-based flow system. [A flow chart displays. The material and information flows from supplier to production or development. The work in progress or the final product goes from production or development to the customer.] They can be used to identify where an organization can gain efficiencies and benefit financially.

Back to top

1.

[Topic title: Process Cycle Efficiency. The presenter is Barbara Waters.] Lean manufacturing is a management philosophy that focuses on reducing waste and implementing a flow-based production line rather than a batch and queue method. It's aimed at reducing costs and improving overall customer value.

Process Cycle Efficiency or PCE is a lean metric used to improve processes by measuring process efficiency. PCE answers the question how lean is your process. Finding a processes PCE involves using a formula to find out how much time in the process cycle adds value for the customer. To get a PCE value, you compare the value added time to the lead time or overall time it takes to complete the process from start to finish.

Value-added time is the time in the process that a customer would consider necessary to create the product or service. In a car manufacturing plant, the value-added time would be represented, for example, by the time spent on assembling and adding a high-end navigation system in the car. Value-added time refers to the time when the product is being worked on rather than the time spent on such activities as human resources, administration, or marketing. All the other time involved in the process can be thought of as wait time. By using Value Stream Mapping an organization can reduce the waste in a process, and focus only on those activities that are considered value added.

There's usually a gap between the actual PCE values in a given industry and the desirable cycle efficiency rates that can be achieved. These desirable rates, known as World-class Levels of Leanness vary by industry and process.

When an organization uses benchmarking to compare its PCE values to the best practices in its industry the organization can identify how much more efficient its process cycle can potentially become. In one example of process cycle efficiency, a Six Sigma team at a soft drink bottling company is calculating the process cycle efficiency of the mixing process. The team would like to have the process cycle efficiency or PCE reach a relatively lean level of 20%. The team must start by determining the current PCE.

From customer feedback the team members determine a value added time of three minutes by adding up the required time to actually mix up the ingredients. They do not include time spent monitoring and recording the process for the organizational database. That time adds no value for the customer. This means that the numerator in the PCE formula is three.

The time it takes to mix the raw ingredients and prepare them for bottling is 26 minutes. To calculate PCE, the team takes the value-added time of three, and divides it by the lead time of 26, to get a resulting PCE of 0.115. They express this as a percentage by multiplying by 100. The result of 11.5% indicates that the mixing process is not sufficiently lean and certainly has room for improvement.

Opportunities for cost reduction exist in any process with a low PCE. Reducing work in progress or WIP and shortening lead time can increase a processes efficiency by increasing the relative proportion of value-added activities. Value-added time cannot be increased for the same product, so the only way to increase the ratio is to lower the overall lead time. This increases the relative amount of value-added time.

There are other opportunities as well, such as reducing queue time and other delays, and eliminating waste. Teams can also work to increase the proportion of touch time, which is that portion of the cycle time where an operator adds value while handling the product.

Another tool that can be used to increase efficiency across processes is a cumulative flow diagram. A cumulative flow diagram is a visual tool that shows the relative amount of tasks that are complete, the number of tasks that are in the approval stage, and in the remaining stages of testing, development, analysis, design, and backlog.

Using a vertical cross-section of the graph each of the areas can be compared. Those areas which are larger than others can indicate a bottleneck or an inefficient amount of work in progress. For instance, a cross-section may show that the development stage has been growing steadily over time. This indicates that the development work in progress is backing up before analysis is beginning.

There may be an opportunity to either move generalists to other tasks or identify waste that may be occurring along the value stream. Teams sometimes hesitate to acknowledge some of these metrics for fear of judgment.

A positive attitude should be enforced towards the use of metrics within teams. Metrics should be approached as a way to assess processes, not people, and to determine whether changes to the processes bring the intended results and improvements.

Back to top

1.

[Topic title: Little's Law. The presenter is Barbara Waters.] In order to maintain a stable process with minimal chaos organizations should attempt to minimize work in progress or WIP in their processes. One way to do this is by setting WIP limits. WIP limits help to reduce bottlenecks, improve the rate of throughput, and control the workload levels of project team members. This may be counterintuitive since it suggests that by working on less a team member will actually accomplish more. In fact, trying to multitask and handle too many activities at the same time actually results in inefficiencies. Little's Law proves this concept to be true, and it is best demonstrated using queuing systems.

Little's Law states that each process has three characteristics that are interrelated. By changing one of the characteristics the others will change. The three characteristics are inventory or WIP, throughput, and lead time.

Little's Law can be demonstrated in an example of customers waiting in line to pay for their purchases. The inventory would be the number of people waiting in line. That inventory is also the work in progress or WIP. The wait time is how long it takes from when a customer enters the line until they are served.

For simplicity, the wait time in this queuing example is being used interchangeably with lead time as it is described in the traditional Little's Law formula. And the throughput is the speed of service or the number of customers who are served every minute. Throughput can be measured in minutes, hours, or whatever increment of time is meaningful for a team's process.

In one example, there are 10 people waiting in line, so the inventory is 10. Two customers can be served every minute, therefore the throughput is two. By dividing the number of customers in line, or 10, by the throughput or two, the wait time equals five minutes per customer.

If an organization wants to reduce the wait time of its customers it can do so by reducing the queue size. For example, a store could implement a 15-items-or-less policy, which would result in fewer customers who are eligible to enter that line. If the 15-items-or-less queue size is only half the size of the regular line, or five people, the wait time will also drop by half, from five minutes to two-and-a-half minutes. By controlling the inventory organizations can reduce the chaos in the system and create a more stable process.

Since inventory, throughput, and lead time are all interrelated, what if instead of reducing inventory an organization can increase throughput. Perhaps a store adds two self-service lanes where customers can ring up their own purchases. One cashier is available to answer questions and provide assistance on both of the registers simultaneously. With this new option, five customers are served per minute, instead of two. If there are 10 customers waiting for the self-service registers, the wait time will only be two minutes. Again, as one of the interrelated characteristics of Little's Law changes, it results in a change to the others. In this case, increasing throughput results in lower wait times.

Reducing WIP helps avoid problems associated with running at peak capacity by ensuring WIP never reaches levels that require emergency measures and extraordinary expenses. If warehouses are already full periodic peaks may mean purchasing costly temporary storage. Or if a large number of projects are already going on then meeting periodic high demands can require overtime, expedited shipping, and extra personnel. Reducing WIP also reduces overhead, such as the cost of storage space for idle inventory, wasted employee time and talent, and idle machinery.

Additional costs, many of them hidden are incurred because all of these items must be managed. The excess inventory may need to be relocated from time to time or counted. Idle personnel may need to be temporarily reassigned. Maintenance may be performed on machinery that isn't producing. These are all non-value-added activities. And the longer the excess work or inventory stays in process the more it costs.

Excess WIP generates hidden costs in overhead, rework, and scrap, while trying up resources and capital. It wastes human effort, and it risks customer dissatisfaction without any possibility of adding value for the customer.

[A graph displays. X-axis shows work in progress in terms of number of projects in process and Y-axis shows lead time in terms of days.] Little's Law proves that the relationship between work in progress or WIP and lead time is a simple positive linear correlation. That is, the more WIP in the system the longer it will take for all projects to be completed.

When the number of simultaneous projects an organization is working on is decreased from 30 to 20, the lead time is reduced from six days to four days. Reducing WIP reduces lead time. Reduced lead time means that value-added time represents a relatively greater proportion of the overall time it takes to complete a process.

As a comparison of value-added time to lead time is the basis for calculating process cycle efficiency or PCE, a reduction in WIP has the end result of a higher PCE.

Back to top

1.

[Topic title: Communicating the Product Vision. The presenter is Barbara Waters.] Stakeholder engagement is a fundamental part of project management. It's important to be able to express the product vision to stakeholders in order to gain support in common understanding about the product requirements. The product owner often collaborates with other key stakeholders to develop a product vision.

Two activities that can help stakeholders formulate an appropriate product vision are designing a product vision box, and generating an elevator test statement.

A product vision box is sample packaging that visually describes the product. Stakeholders are divided into cross-functional groups of four to six individuals who design a product vision box. For the front of the box, you think of a product name, a relevant graphic, and bullet points summarizing the key benefits that the product can provide. For the back of the box, you provide a detailed product description and product requirements.

An elevator test statement is a brief description of a product, including its target customer, the need it meets, the product's name and purpose, and the benefits it can have for the customer. This statement is referred to as an Elevator Test Statement, because it shouldn't take longer than a short elevator trip or less than two minutes to explain.

Stakeholders may use a brainstorming session to generate a suitable elevator test statement which helps in defining a product vision. Stakeholders who participate in creating a product vision typically come from different functional areas. These stakeholders may include the product sponsor, who is interested in the project's return on investment, and members of the customer organization's marketing department who are familiar with the market demand that a product should meet.

They may also include end users who can provide information about what features they expect in the product. The stakeholders also specify a high-level scope for the project which may be adjusted later in planning.

It's important to manage stakeholder engagement throughout the project. This includes setting a realistic expectations, and maintaining strong communication. After the product vision has been agreed upon, there still may be differing ideas about the product and how it will look and function. This gap between what the stakeholder wants and what the project team plans to build is known as the Gulf of Evaluation. This gap is not intentional, and there are tools to help reduce it, like wireframes.

Wireframes can include page schematics or screen blueprints. Wireframes provide a visual guide, and define information hierarchy on a page. Wireframes also make it easier for user-experienced designers to plan the layout of a page. And with wireframes users can interact with the interface before anything has been developed. By using tools such as wireframes, project teams can solicit valuable feedback from stakeholders, and ensure that the product will meet expectations.

Another important concept in agile projects is the concept of definition of done. This may also be referred to as done-done. The definition of done is a clear and concise list of requirements that, if fulfilled, means the product is now potentially deliverable. The product owner is responsible for ensuring that the definition of done has been documented, and then the team is accountable for fulfilling that list of requirements to ensure that their deliverable meets the definition.

A definition of done can be created at various levels in projects. There may be different definitions of done for a feature, a sprint, and a release. The criteria for something to be done will differ at each of these levels.

The benefits of having a clear and concise list of criteria to consider something done is, that it guides the planning activities of an agile team. Having a definition of done also helps to limit misunderstandings and conflict that could arise between the team members or the team members and the product owner by not having a clear and communicated list of criteria from the very beginning. It also limits costs of rework, for example, as it leaves no room for surprise because some criteria is missing that wasn't discussed or documented in definition of done.

In summary, project teams may best engage stakeholders by working together to develop and communicate the product vision, using wireframes to reduce the gulf of evaluation, and creating a definition of done. This will ensure that expectations are properly set, and that all participants agree when the requirements have been met.

Back to top

1.

[Topic title: Defining the Agile Team's Physical Space. The presenter is Barbara Waters.] With today's modern technology there are a variety of tools to bring teams together virtually.

Grandparents meet their new grandchild for the first time via video chat, friends text each other to catch up and make plans, and people share their experiences and likes on social media sites. Despite all the different ways that people can get together virtually, with agile teams, the accepted best practice is to work together in person. This is stressed through the first value in the Agile Manifesto, which states that we value individuals and interactions over processes and tools. This means having individuals interact in ways that bring out the best ideas. And one of the 12 agile principles states that face-to-face communication is the most efficient and effective method of conveying information to and within a development team.

Face-to-face communication supports the quick transfer of information. So how can the ideal agile team space be described? Agile teams often rely on collocation. This means locating development team members close to one another or in the same workspace, such as a single open-plan office with no cubicles or partitions between desks. This environment encourages team members to communicate with one another as they work, and to discuss any obstacles they encounter.

Working in isolation should be an exception. A separate area may be designated for briefly stepping away to conduct personal matters.

Collocation is essential for certain software development techniques, such as pair programming. Pair programming is like as the name would suggest that a couple or two programmers would sit next to each other, one entering the code, the other ensuring that the code is accurate. Communication is face-to-face, information is free-flowing, and rapport and trust is essential. In pair programming, the communication and learning is direct and purposeful. However there are some indirect benefits of collocation which also benefit agile teams.

Osmosis is the process by which a substance seeps from one system into another through a separation barrier. In agile teams, the concept is that team members in the same space benefit by unconsciously taking in information from one another. This happens because in a shared environment individuals are exposed to various sensory experiences, even when they aren't consciously paying attention to them. For example, team members take in sounds in the work area even when they're not actively listening. This is evident when two people are having a conversation, and a third turns around only when his or her name is mentioned. Although the third person wasn't actively listening, the content of the conversation filters through.

Osmotic communication isn't restricted to sound alone. It also includes visual information, such as body language of colleagues on the other side of an office.

Osmotic communication helps ensure that questions and ideas flow naturally between team members. It also reduces the time and costs associated with having team members update one another in other ways. For example, through time-consuming meetings or conference calls.

In one example of osmotic communication in an agile team environment, Mica, one of the team members turns to ask his coworker, Lenard, a question about their code refactoring technique. Lenard struggles to answer the question clearly, but Allison overheard the conversation and shares her knowledge on the subject. Now, all three team members have the same information with regard to their activity.

Another advantage of collocation is the sharing of tacit knowledge. Tacit knowledge can be defined as skills, ideas, and experiences that people have, such as playing a musical instrument, or expertly navigating a river without hitting sandbanks. Tacit knowledge is also referred to as know-how, and can be very difficult to transfer except through extensive personal contact, regular interaction, and trust.

Therefore, an individual can acquire tacit knowledge without language. Apprentices, for example, work with their mentors and learn craftsmanship, not through language, but by observation, imitation, and practice. Tacit knowledge involves learning and skill, but not in a way that can be written down. This is the reason collocation is so important to the development of skills and experiences among coworkers. Individuals can learn from each other just by being in the same location.

Teleconferencing and social media are both useful tools, and technology clearly has value in today's working environments. However, when it comes to the agile manifesto and agile values, face-to-face communication through collocated groups is the simplest and most effective way to communicate.

Back to top

1. Exercise overview

Agile teams achieve efficiency by leveraging many of the tools from Lean Management, but also by valuing individuals and interactions.

In this exercise, you'll demonstrate that you can:

• identify characteristics of waste
  
• recognize the relationship between PCE variables
• identify characteristics of Agile environments

2.

Back to top