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.

---

Epics, User Stories and Tasks

I was working with a client this last week and I overheard one team member trying to explain the difference between Epics, User Stories, and Tasks.  He finally offered an analogy.

The Analogy

Epics are to User Stories are to Tasks as Rocks are to Pebbles are to Sand.

I thought it was a clever description of comparing relative size and complexity of work. But would it pass muster with the Agile Community? I figured I would send it out to the Twitter-verse and see if any conversations would result.

The result was an excellent conversation with David Koontz.

The Conversation

Though I will admit there are some challenges in communicating in 140 characters or less, it really forced me to think about what I was trying to say.  David did a really great job of challenging me to explain what I was thinking.  In tweet responses, David stated if it can fit in a Sprint, he calls it a User Story.  If it is too big to fit in a Sprint, it is called an Epic.  I have to say, if we all followed that model, it certainly would simplify things.

I find customers asking if they can call them sub-stories, major stories, and craziness like that. Customers take a stab at breaking down work to manageable chunks but when the team estimates the work, it's still too big to fit into a sprint.  To restate David's identifying criteria, too big equals epic; small enough equals user story.

David then asked me,

does Epic == collection of stories? Or some stories and some waste we should never do?

My response was,

I believe epic != collection of stories. I believe epic == placeholder of a goal or idea. Stories may result but no guarantee

The Clarification

To clarify my beliefs, I believe a User Story as merely a placeholder for a conversation.  I believe an Epic is a placeholder for a goal or an idea.  Along the way, there will be resulting value delivered and waste.

Though you should be able to map all of your User Stories (and waste) back to Epics, that's not the goal.  You don't just do tasks and then look for a bucket of stories or epics to group your efforts.

I won't say having something small enough to fit in a Sprint is automatically called a User Story.  What if you don't leverage Scrum?  What if you are leveraging Kanban?  In either case, we refer back to the conversations.  As long as your work meets your definition of Ready, I don't care what you call it.

Thank you, David, for an excellent conversation.  I hope others will join in.

Waste In Software Projects

This evening I attending the monthly Agile Leadership Network event. I noticed a very familiar slide on Waste In Software Projects. It looks familiar because I have it in my training deck as well! Yes, my Introduction to Agile class has a slide that credits the Standish Group Study reported at XP2002 by Jim Johnson, Chairman.  In reviewing software systems, Jim Johnston, Chairman of the Standish Group, determined that in systems defined and delivered using a traditional / waterfall style approach almost half of all features developed and paid for are never used.  The question this evening was, for the 45% of the features that were never used, what was the cost incurred?  Well, I can tell you it's probably a lot more than 45% of the budget!  What if the features that were never used were actually the most costly as well? The rule we should learn here is we should eliminate the waste at the source, before it makes it all the way to the Production environment.  If a feature or product is never used, it's waste. But, since XP2002, have we learned our lessons?     Are we still delivering features that customers will never use?  I figured I would create a quick Google Doc that would collect some data. After giving it some thought, I decided to remove the link to the Google Doc.  The collection of data was just a distraction from the actual blog post.  Thank you to those to participated.

Team-Based or Value-Based

I'm currently reading a book about Systems Analysis and Design.  In a chapter discussing Agile Methods, one of the statements really rubbed me the wrong way.

The Agile Manifesto is a set of team-based principles...

For the last 6 or so years, I've assumed the Manifesto was a set of "value-based" principles.  That is, at its core, Agile is about delivering value or eliminating waste.  What I like about the Manifesto is it leaves a lot to interpretation.  It doesn't spell thing out to the N^th degree.  But, I'm very curious what the community thinks.  How would you describe the principles?

Please leave a comment.  Tell me what you think.

---

Mura Muri Muda

I had the wonderful opportunity to meet and listen to Jeff Sutherland a few days ago. For those who do not know who Jeff is, he and Ken Schwaber created Scrum.  It was really quite amazing to listen to him speak.  The topic of the talk was Using Scrum to avoid bad CMMI implementations.

Scrum and CMMI are often at odds with each other. What does each approach bring to the table? Scrum promotes the idea of focusing on the most important product issues first and supports frequent communication. CMMI brings a structure that promotes consistency and discipline to avoid waste and rework. So, why should we try to combine both approaches? Is this combination a good idea?

This post isn't going to go into detail about the entire talk. Rather, there were three words Jeff said that had me scrambling for my pen. "Muri, Mura, Muda".

The Toyota Production System identifies three types of waste (Muri, Mura, Muda).

Muri (無理, “unreasonable”) is a Japanese term for overburden, unreasonableness or absurdity.

Mura (斑 or ムラ) is traditional general Japanese term for unevenness, inconsistency in physical matter or human spiritual condition.  Waste reduction is an effective way to increase profitability.

Muda (無駄) is a traditional Japanese term for an activity that is wasteful and doesn't add value or is unproductive.

With commercial organizations, I consistently see two primary goals:  [1] Make Money and [2] Save Money

But as you drill down into an organization, these two goals are not as obvious.  So, to address this, I rewrite the two goals as:  [1] Deliver Value and [2] Eliminate Waste

When we reach this point, muri, mura, muda come into play.  In your day-to-day activities, are there areas you can make more efficient or improve?  Do you really need to go to that meeting or can someone just email you an agenda before and minutes after?  In your project lifecycle, do you really need a 10-step process workflow or can you achieve the same goal with just 5 steps?

Here is a practical exercise:  Make a list of activities you have to do this week.  Ask yourself why you need to do each of those activities. Do they map back to the core mission of your company?  Should any of these activities be postponed until the goal is clarified?  Should you just NOT do one of them?

I have a daily meeting at 10:00.  Why?  I fill find out what the team did yesterday, what they are doing today, and what impediments they have.  My job is to help facilitate their activities and remove roadblocks.  This 15 minute meeting is a keeper.

I have an invite to the Finance Working Group meeting on Monday. Why? Hmmm.  That's a good questions!  The meeting is scheduled for 1hr.  I know that it traditionally lasts 2-3hrs.  No invoice was attached in the meeting invite.  That leads me to believe they are going to review 500 pages as a group.  Though it's necessary to review the invoice, this is a very inefficient way of doing it.  I will send a request for a copy of the invoice to review when I can.  I will decline the meeting invite.

Of those activities on your list, highlight which ones just don't sit well with you.  Really listen to your gut. Are any items on your list an activity that does not directly translate into providing value?  Are any items on your list going to somehow cut into your personal life?  Are any items on your list literally a waste of time, money, or energy!?  If you can scratch any one of these items off your list, you are on the road to Kaizen (改善) (English: Continuous Improvement).

Before you accept that next task or meeting invite, ask yourself if there is a better way.

HT: Wikipedia

Like the drawing?  You can download it free at Pictofigo