Work in Process - WIP

What is 'Work In Process - WIP'

Work in process, also known as WIP, refers to activities that have entered the completion process but are not yet outcomes. Work in progress (WIP) refers to all materials and partly finished products that are at various stages of the production process. WIP excludes inventory of time or materials at the start of the completion cycle and finished products inventory at the end of the production cycle.  That means you don't count the things you have not started or have not finished.

Work in Process vs Progress

I see the difference between process and progress as being very small but I want to make a distinction.  I see progress being anchored to physical goods at different stages of completeness on an assembly line and process being completion of any activity as part of a goal or outcome.  Your process could be as simple as To-do and Done.  If you are multi-tasking and have 5 things started all at the same time, you have a WIP of 5.

Personal Agility Tip

One of the secrets of managing your work in process is to only start work on things you actually have capacity to work on. When you have capacity, you can pull work into your "queue". Rather than accepting and starting every task that comes your way, limit the amount of stuff that you’re working on at any given time.  Focus less on starting things in your queue and more on finishing them, and I can pretty much guarantee you’ll get more done.

Personally, I know that I can only deal with three activities at a time before things start to get dropped. Know your personal limits and set them accordingly. If you’re working on something and you get blocked, don’t just pull in more work. Add a visual indicator that shows the item is blocked and continue pulling working to done. Once you unblock work, you can pull it the rest of the way through your system to done.

Have questions?  Ask me how I do it!

How You Can Get Valuable Time Back: Part 2

This is Part 2 in a series I'm writing about how you can get time back in your day, week, month, or project.   When a team reaches a natural velocity or throughput, how can you get more out of them? They physically can't deliver any faster, given current conditions.  If we assume we have stable teams, let's focus on governance and process.  Specifically, I'm going to talk about meetings again.  Why?  We all hate meetings but we all still have them. In part 1, I wrote about a strategy to enable your email auto-responder to help manage the inbound meeting invites. In Part 2, I'm going to give you a simple strategy to start Spring Cleaning your calendar.

Spring Cleaning

If you've ever had a professional organizer come to your house for Spring cleaning, they may have employed a common strategy to weed through your crap.  It doesn't matter if you are the CEO of a Fortune 500 company or some person appearing on an episode of A&E's Hoarders. We all have too much stuff.  In this case, we're not deciding if you should keep that mountain of National Geographic magazines sitting in the corner or all of those plastic shopping bags you've been keeping when you return from the grocery story. No, we're going to inventory your meetings. Over time, we tend to accumulate meetings.  Time to take inventory and do some Spring Cleaning.

Inventory

As mentioned in the last post, some meetings have value than others. We're going to need see which meeting we need to keep, which meetings we're going to give away, and which we're going to throw away.

Remember, meetings are supposed to be about the exchange of information.  Unfortunately, they are wildly inefficient and offer limited value.  For the most part, they are a waste of our time.  Nobody wants to listen to you go on and on about how many meetings you have, now that you're becoming a bottleneck in getting things done.

To start, I'm going to review every existing and new meeting request and bucket those meetings into 3 categories.

1. Non value added but it is necessary.
2. Non value added but it is NOT necessary.
3. Value added.

1. Non Value Added But Necessary

Instead of automatically accepting the next meeting request, pause and consider the meeting’s return on investment to you.

• Does the purpose of the meeting align with the company’s strategic goals and priorities?
• Are the objectives of the meeting clearly defined?
• Can the organizer explain specifically why you were invited and the value you will provide?
• Will this meeting assist you in achieving my objectives?

If the first four questions were all answered with a yes, you should still ask.

• Will anyone notice if you didn't show up?
• Is attending this meeting the highest and best use of your time right now?

If any of the first four questions were answered with a no, you should seriously consider declining the invitation. If I was Spring cleaning, this pile would be earmarked to donate.  Because we can't "donate" meetings, I would propose having someone else attend on your behalf or find some way of being informed of the meeting outcomes or action items.

2. Non Value Added But It Is NOT Necessary

Did you read that right?  This meeting not only does not provide strategic value but it's also not necessary.

If I was Spring cleaning, this pile would be earmarked for the trash.  This is like a meeting to prepare for a meeting.  Before outright refusing, try to meet the organizer part way.  What problem are they trying to solve with the meeting?  Can it be solved some other way?

To ensure everyone has a shared understand of what meetings are not NOT acceptable, I would recommend making an actual list.

Thou shalt not have meetings about putting cover sheets on TFS reports

3. Value Added

If I was Spring cleaning, this pile would be a keeper.  This is something that you want or need, as part of business process.  Release Planning, Sprint Planning, Demos... I see these as all valuable meetings.  They all require decisions.

Conclusion

Remember, every time you say yes to a meeting, you are saying no to something else.

Check out some of these templates, including Meeting Agenda/Minutes template

How You Can Get Valuable Time Back: Part 1

Recently, I've been swamped with meetings.  I'm not talking Portfolio Planning, Release Planning, or even Sprint Planning meetings. I'm talking a lot of in-the-weeds type meetings.  After I walk out of some, I realize I could have been informed of the outcomes and action items and that would have been good enough. I didn't need to sit through the whole damn thing.  There are times everyone walks out an hour later, are looking around, and are asking how to get that valuable time back.  It got me thinking, I need to write about this!  Then, as I started writing, I realized that this was either going to be a seriously long long-form blog post or I was going to have to write a few parts to it.  Being the bloggy-blog type, I vote for short form and write a series.

The Scenario

You arrive to the office at 8am on a Monday, only to realize you are late for a meeting someone on Friday after 5pm scheduled.  You're not in the office 5 minutes and you're already behind schedule.  What the hell!?  How does this happen?  You look at your calendar. You have back-to-back-to-back meetings all day Monday and Tuesday.  When are you supposed to actually do your work?  Given the current conditions, you're going to need to catch up on things before or after work. This sucks!

The Problem

You have become a meeting hoarder.  That's right.  At any moment, A&E is going to show up at the office and start filming an episode about you.  In this episode, they follow you around the office.  They confront you and the addiction of accepting too many meeting invites.  Of course this is ridiculous but you really do need some practical strategies to deal with this problem and get back on the track.

Meetings are supposed to be about the exchange of information.  Unfortunately, they are wildly inefficient and offer limited value.  For the most part, they are waste of our time.  Nobody wants to listen to you go on and on about how many meetings you have, now that you're becoming a bottleneck in getting things done.

To start, I'm going to bucket meetings into 3 categories.

1. Non value added but it is necessary.
2. Non value added but it is NOT necessary.
3. Value added.

I see very view meetings offer direct value to the customer.  Most meetings a non value added but we don't have a sufficient method to exchange the information so we settle for the meeting.  It's necessary.

Going forward, assume most meetings don't add value and you should make them prove their worth to you.

The Solutions

In this post, I'm going to give you a strategy to begin controlling the volume of meeting invitations coming into your calendar. First, stop accepting meeting invites for meetings that are less than a full day away.  If someone invites you to a meeting at 5pm on Monday for a meeting at 9am Tuesday, they are being disrespectful of your time.

Set Limits

You may have a standard eight hour work day but the reality is that only half of that day is likely to be productive.  With that assumption, you should guarantee you have 4 hours of productivity. If you don't, your day will be taken up with meetings, responding to email, browsing the Internet and related activities.  Block out 4 hours a day on your calendar for actual work. Make the events private.

Tip: Schedule your most important, high value tasks in the morning, before you get worn out from your current meetings

Turn On Your Email Auto-Responder

Until you can get your meeting addition under control, I recommend you begin using your email autoresponder.  I actually did this several years back, after reading The 4-Hour Work Week with very good results. When someone sends you an email or meeting invite, they automatically get an email from you (with the assumption that you have NOT read their invite).  This will buy you time to focus on real work and not just respond impulsively to the request.

Let’s look at a basic template

Greetings, Due to high workload and too many meeting invites, I am currently checking and responding twice daily at 12:00 P.M. and 4:00 P.M. If you require urgent assistance (please ensure it is urgent) that cannot wait until either 12:00 P.M. or 4:00 P.M., please contact me via phone at 555-876-5309. All meeting invites will require 24 hour notice. Though I appreciate the invitation, sending me a meeting invite does not mean I will be accepting your invitation. Thank you for understanding this move to more efficiency and effectiveness. It helps me accomplish more to serve you better. Sincerely, [Your name]

Conclusion

I can guarantee this is going to help, at least a little.  The more we can slow down the influx of meetings, the more we can assess the value of them and decide if we really need to accept them or not.  The autoresponder will put people on notice and inform them that your time is valuable but that you're not being unreasonable.  If this gets you out of 1 meeting, won't it be worth it?  I know it will do better than that.  Try it and let me know your results.

---

In my next post, I'll write about how to triage your meeting requests, so you can begin spending more time doing real work and less going to meetings.

---

Lean Metrics in the Real World

Today, I was faced with the unfortunate task of renewing my driver's license. It's been 10 years since the last renewal and I remember the last time I was at the Maryland MVA (Motor Vehicle Administration) office, I waited for what seemed to be an hour.  We all know how painful the experience is.  You stand in line, you get to the front of the line, they tell you to go fill out some paperwork and then to get back in line. I will use the opportunity to teach others about lean metrics.

Lead Time

Lead time is the time between the initiation and completion of a production process.  In my case, I left the office at 09:00 and arrived back at the office at 10:00.  The lead time to get a renewed driver's license was 60 minutes.  Given my goal, the shorter the lead time the better.

Cycle Time

Cycle time is the total time from the beginning to the end of a process, as defined by you and your customer. Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action.  The shorter your cycle times (including delays) the shorter your lead time.

My cycle times included:

• 15 minutes - driving to MVA office
• 5 minutes - standing in initial line to be added to the proper queue
• 16 minutes - wait time to get the front of the line
• 5 minutes - actual renewal processing
• 4 minutes - wait time to be given the new driver's license
• 15 minutes - driving back from the MVA office

My hat comes off to Maryland MVA.  On their website, they provide current wait times at the different locations.  I took a screen grab before I headed to the local MVA branch.  This feedback was very valuable.  Given the service I needed, it allowed me to provide an estimate of my time away to others I was going to be working with today.

Throughput

Throughput is the the amount of material or items (people in this case) passing through a system or process per time unit. With an average cycle time of 5 minutes for the renewal process, the throughput in 60 minutes would be 12 people.  At first glance, I didn't see any real bottlenecks or delays in their system.  Given what I saw, I believe 10 people an hour is a reasonable throughput.

Understanding Lean Metrics

I hope this brief real world example of lean metrics is valuable to you.  When I was at a session for value stream mapping at Agile 2015, the poor guy leading the session kept getting lead time and cycle time mixed up.  The people in the room heckled the hell out of him. After reading this, that should never happen to you.

Lean Business Report Presented by LeanKit

You've heard of the State of Agile survey?

Welcome to the Lean Business Report Survey!

I would describe myself as a whole lot of things, including a Lean Practitioner.  I was forwarded this survey and thought I would give it a go.  It only took me about 10 minutes and it felt great that I was able to contribute.

Why not help out?  Get started here >> Lean Business Report Survey

---

In the survey, you’ll be asked to share your experiences in learning, adopting or practicing Lean. LeanKit will compile and share the results in early 2016. Together, we’ll gain a deeper understanding of how Lean works for business.

If you provide your email address, you'll receive an early copy of the Lean Business Report and also be entered to win one of five $500 Amazon gift cards. Here are some quick facts to know before you begin:

• The survey will take approximately 11 minutes.

• Only questions marked with an asterisk (*) are required.

• Your responses are completely anonymous.

Thank you again for your input!

How to Use an A3 Report

What is an A3

An A3 is more than an 11 x 17 inch piece of paper that is structured into several sections and not all A3's are created equal. An A3 is a structured problem solving and continuous improvement approach, first employed at Toyota and typically used by Lean manufacturing practitioners. What your A3 looks like depends upon the situation. The example below consists of the following pattern, as part of an Agile Transformation:

1. Current Situation & Problem

2. Root Cause Analysis / Conclusion

3. Goal

4. Corrective Action

After we agree on the four steps, we're going to implement the correction action and then verify the results. The content of an A3 follows the logic of the Plan-Do-Study-Act (PDSA) cycle.  What I want you to take away from this blog post is not so much TQM, PDSA, and A3's, as much as how you could benefit from them when doing an Agile transformation or any kind of process improvement.

A3 Report Example

When doing an Agile Transformation, I'm going to always cycle back to 3 core goals.

1. Form complete cross functional teams

2. Build backlogs

3. Deliver working tested software

Anything that gets in the way of doing these is an impediment that has to be removed.  The example I have above describes how a team is under-committing each sprint.  We're using a story point completion ratio to know if the team is delivering working tested software. We're going to use this single page to have a shared understanding with our client and agree on a course of action.  Now, I'm not saying you have to use this template. If you can remove an impediment informally, by all means, do it!  But, to make sure my client agrees there is a problem that needs to be prioritized and addressed, this is an effective tool and it's pretty lightweight.  You may also notice I don't call this an A3 on the actual example.  I'm going to call it an Action Report so my client feels comfortable with common language and I don't need to distract them by introducing Lean terminology.  When I say "A3", there are certain expectations.  Let's not get hung up on that and just call it an Action Report going forward.

Flow of the Action Report

You'll notice that I structured my Action Report so that your eyes will be drawn to sections. I want to compare 1 and 3 (Current Conditions and Goals) and 2 and 4 (Root Cause Analysis/Conclusion and Corrective Action).  This allows a transformation consultant to note impediments and identify root causes independently but then be prepared to collaborate with the client on goals and corrective actions.  I'm going to stress this again.  We're only going to go through this process if the consultant can't resolve the issue informally.  If not, he or she will need to collaborate with the client to confirm the goal and agree on an appropriate action. The consultant doesn't do all of this in a vacuum.  When looking at action (or A3) reports used by others, I've seen them identify the goal prior to looking for root cause. From my experience, if I'm required to identify the goal before moving forward, this may create an unnecessary delay.  If I don't think something is right, I'm going to start investigating right away and then circle back with the client to validate their goal. But, I'm not going to stop and wait to be told what their goal is before beginning to look for root cause. I don't want to stop until my personal curiosity is satisfied. Also, I'm not saying to not collaborate with the customer. I'm saying keep moving forward on multiple fronts and to circle back at the first logical opportunity.

Current Conditions

We have several opportunities during the transformation to get this information.  It could be, we just completed a formal assessment of the team or organization.  Maybe we just reviewed metrics of the team or organization.  Maybe I just walked out of a really long and unproductive meeting. Whatever we did, I'm looking for some kind of objective criteria or indicator to describe the condition.

Root Cause Analysis / Conclusion

In order to propose appropriate corrective actions, we need to identify the root cause of the condition. Avoid using logical fallacies like anecdotal, appeal to emotion, or false cause. I like to use Socratic method or ask the 5 whys to help reach the root cause.

Goals

The goal listed above in the illustration focuses on getting a team's story point completion ratio to 100% +/- 10%. This goal is pointing back to building backlogs and delivering working tested software.  By getting the teams to keep their commitments of delivering working tested software regularly, we allow the business to make better commitments to their customers. If we can build that trust and safety within our organizations, we'll start to build balanced systems.

Corrective Actions

Identify corrective actions that is both short term and easy to implement. If the actions are neither, I keep a higher level corrective action around and then break it down so I can incrementally work toward the goal.  Personally, I keep my daily activities on a Kanban board. For an overall transformation, I keep the actions and activities in a rolling 90-day plan.  This keeps the client informed on what value I've delivered and what value I plan to deliver in the coming weeks/months.

Plan Do Study Act in an Agile Transformation

When doing an Agile Transformation, PDSA is just one pattern to map the approach.  Not mentioned in this blog post are the original inputs into the initial coaching plan and 90-day plan. (both of which are collaboratively defined and continuously evolved with the client). But, how do I fit it all together in a high level "plan do study act" process, more emblematic of the original A3 process? I use the following:

1. Coaching Plan (Plan)

2. Rolling 90-Day Plan (Do)

3. Adoption Assessment (Study)

4. Metrics (Study)

5. Action Report (Act)

Inputs and Outputs of an A3 Report

Summary

I hope this provides some insights into how you can take some of the hand waving out of your next (or current) Agile transformation.  There are a lot of moving parts and you need the process and tools to keep an eye on your goals and manage progress, without adding so much overhead that you stifle the forward momentum.  Let me know if you have questions!

Download a free copy of the A3 Report Template

Value Stream for Business Travelers

The more I travel, the more I find myself observing how business travel (particularly flying) is a lot like application development. Process the flow of travelers (business value) through a system much like ideas flow from inception to delivery.  When reviewing the processes of  the business traveler (delivery), I keep asking myself why the system has so much room for improvement and why we as participants within it don't fix it.  I notice many travelers do few things that provide direct value (save time).  Rather, we do things that either provide little or no value but are necessary or are just wasteful.

As a business traveler, I want to arrive to a destination as quickly as possible without violating identified constraints.

Constraints: Quality and Cost 

Quality (safety thresholds):

We want to make sure that some knucklehead does not get on a plane and do something destructive.  Rather than quality, the FAA calls this security.  In the end, the underwear bomber who unsuccessfully detonated his skivvies mid-flight is like discovering a severity one bug in Production.  It would have been a lot cheaper, if this guy was stopped at a security checkpoint and prevented from getting on the plane in the first place.  As a result, I have Bubba the TSA Agent measuring me for a pair of pants every time I opt out the body scan. Do these theatrics actually increase quality?  I'm not sure. But I digress. [TSA Removing Body Scanners?]

We want to ensure planes don't fall out of the sky, due to mechanical issues.  In an attempt to ensure we don't go below this quality threshold, the FAA requires airlines to conduct regularly scheduled maintenance on aircraft.  As stakeholders, both the airlines and passengers see maintenance translate as on-time departures.  As this relates to application development, customers don't always think (or care) about code refactoring, fixing bugs, or paying down technical debt.  Still, if they don't want the system to crash or have a delayed launch, this out-of-site process has to take place on a regular basis.

Cost (budget thresholds):

As a business traveler, I expect my costs to fluctuate, based on quality and the speed in which I move through the system.  If I want to move through parts of the system faster, I can pay more.  In the end, local optimization just makes the process seem less painful.  It is, until you get to the next step or stage of the process.

The overall system:

1. I arrive at the airport (park in the Daily garage) [every 15 minutes a shuttle arrives]
2. I stand in line at the security (TSA) checkpoint.   [1-30 minutes]
3. Choice of x-ray or full body scan [pay more for express search] [1-20 minutes]
4. I opt out? [doesn't necessarily increase quality] [5-10 minutes]
5. I arrive at gate and
6. Board flight by "zone"  1st Class, Zone 1, 2, 3 [0-20 minutes]
7. Fly to destination [varies]
8. Land at destination and disembark the aircraft [5-15 minutes]

Though you can have several local optimums within the system, like any process we need to look at optimizing the system as a whole.

Look for bottlenecks and address them.  There is a bottleneck if a lead time exists between the start of one of the eight processes listed above and its execution (completion).   A lead time is the latency (delay) between the initiation and execution of a process. For example, the lead time between getting into the security (TSA) checkpoint line (process step 2) may be anywhere from 1 to 30 minutes. In industry, lead time reduction is an important part of lean manufacturing.  In application development, it allows us to shorten our iterations or feedback loops.  In travel, it allows us to get on with our lives with less impact to events happening outside the system.

One way I've seen people shorten the lead time at this process step is to just be ready.   Sounds obvious but you would be surprised.  There are signs and videos leading up to the security area.  TSA instructs you to have your boarding pass and photo identification ready.  They inform you what is allowed and what is not allowed (step 3).  I've seen countless travelers wait until they are at the podium before digging through purse or pocket, only to have a minor panic attack because they can't find a drivers license.

I've seen the same thing with application development.  Teams don't have their work ready and then there are delays in getting it done.

Agile on Non-Software Projects

Regardless of where I coach or teach, there is always someone who approaches me and says something like, "Agile is great for software projects but what about projects that aren't software related?"  When asked the question, I usually give examples like a U.S. Marine fire team or air crew or a home construction site. (I'll save those stories for another time).  I now have a new story to tell about a cross-functional, highly collaborative team, which competed for the Progressive Insurance Automotive X Prize. While I was at Agile 2012, I met Joe Justice of Team WIKISPEED and had a chance to actually touch a car that was designed and built using Agile methods. (see cool photo enclosed)

Here is some back story from a 2011 press release:   Based in Seattle and led by Joe Justice, WIKISPEED is a collaborative team of over 50 experts and volunteers dedicated to offering ultra-efficient, ultra low-cost, mass-production road-legal vehicles. In 2010 the team's SGT01 prototype placed in the top 10 in their class out of 136 cars overall in the Progressive Insurance Automotive X Prize.

Joe was able to build his first functional prototype in just three months.  The car that competed in the X Prize got 114 MPG (Highway). Compare that to the Toyota Prius which currently gets 51 MPG (Highway) and was introduced in 1995.  The reason auto manufacturers are so slow to "better" their products is because change is very expensive for them.  It is not uncommon for auto manufacturers to operate on 10 to 25 year development cycles.  Before Object-oriented programming methods were introduced, software teams used to operate much the same way.

By modularizing how we build software, we're able to shorten our development cycles down to days.  By shortening our development cycles down to days, we give ourselves the opportunity to get feedback from our customers and create things that they really want, not things that we think they want.  We save ourselves and our organizations countless dollars in wasted development, due to waiting too long to get feedback from our customers or by operating in functional silos.  My breaking our teams down into small, cross-functional, empowered teams, we shorted feedback cycles as much as we can.

Being Joe is a client facing software consultant, building Agile teams and practices, why would he limit the benefits of Agile to just his customers?  Joe and his team have a car that has a development cycle of seven days.  They do this by modularizing the car.  They can switch the gasoline engine to an electric one in about the same time it takes to change a tire. They could change the car body from a convertible to a pickup truck.  All of this allows them to make changes and develop quickly.

The car is safe (passes road safety standards), because Team WIKISPEED developed safety tests before building the actual parts.  This helps them lower waste (Lean).  Next time you say you can't afford to do test-driven development, think about that.  They do all of their work in pairs, avoiding time training that is not productive. (XP Practices) Again, the next time you say you cannot afford to pair people, think about that.  Pairing also helps lower the need for most types of documentation.  If everyone has a shared understanding, you have less need for it.  They visualize their workflow to help identify hidden delays and deliver something every seven days (Scrum).

So, do you still think Agile is only for software projects?  The fact that they use 7 days sprints on hardware, when I hear people say they can't do anything less than 30-days on software, just goes to show you where there is the will there is a way.

Check out Joe's session from TEDxRainier

Post originally appeared at LeadingAgile