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

New Scrum Team Challenges

A while ago, I published a post titled: Simple Cheat Sheet to Sprint Planning Meeting.  Though I understand every team is different, I thought it would be helpful to those who are new to agile processes.  People are always looking for cheat sheets, templates, and stuff like that.  What is the harm of giving them what they want? In retrospect, I think the harm is the lack of context.  When people come to a training class, they are provided an ideal situation.  Even the Scrum Guide was written as though you've been doing Scrum for a while. It doesn't talk about things that happen leading up to your team's first Sprint.  It doesn't talk about the complexity of scaling to the enterprise.  It's just vanilla.

I just got back from coaching a new team and I'll be heading back next week to see how they are doing.  To get them moving forward, I facilitated release planning and sprint planning.  That's where things started to get interesting.  What if your team has never done release planning or sprint planning?

Release and Sprint Planning

The purpose of Release Planning is so the organization can have a roadmap that helps them reach their goals.  Because a lot of what we know emerges over time, most of what we actually know is that we don't know much.

The purpose of the Sprint Planning is for the entire team to agree to complete a set of ready top-ordered product backlog items. This agreement will define the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint timebox.

You're new to Scrum.  You don't have a velocity (rate of delivery in previous sprints) and you are not sure of your capacity (how much work your team can handle at a sustainable pace).  What do you do?

The Backlog

The product backlog can address just about anything, to include new functionality, bugs, and risks. For the purpose of sprint planning, product backlog items must be small enough to be completed (developed, tested, documented) during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner. 

Again, you're new to Scrum.  How do you know what small enough is?

Right Sizing Backlog Items

Product backlog items determined to be too large to be completed in a sprint, based on historical data of the team, should not be considered as sprint backlog candidates during the sprint planning meeting and should be split into smaller pieces. Remember, each story must be able to stand on its own (a vertical slice).  It should not be incomplete or process based (a horizontal slice).

Again, you're new to Scrum.  You have no historical data.

Determining Velocity

The velocity of a team is derived by summing the estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams focus less on utilization and more on throughput.

If you have a new team, not only do you not have a velocity, you won't have any completed work to compare your estimates to and you won't know how many deliverables to commit to.  What do you do?  I think you just go for it!  You keep track of what you are completing and collect historical data.  You get through the sprint and establish some context for future sprints.

The first few sprints are going to be pretty rocky, until the team begins to stabilize. Just ask yourself.  WWDD?  What would Deming Do? Plan a little; Do a little; Check what you did versus what you planned to do; Act on what you discover.

PDCA and Emergency Preparedness

Some of you may have heard there was an earthquake and a hurricane that hit the Mid Atlantic this last week.  I see both events as perfect learning opportunities.  No, these are not learning opportunities on emergency preparedness.  Rather, let's learn about the PDCA cycle by Dr. W. Edwards Deming. Several years ago, my wife and I thought it would be prudent to put together an emergency preparedness kit.  We didn't want 6 months of TVP or anything like that.  We just wanted something for events that may never happen.  So, we planned for the unexpected.  We created a kit and packed it away.  And there it sat for several years.  So, after the earthquake, my wife and I checked our preparedness "kit".  It's interesting to see what you put into these things when you haven't had a recent emergency.  It's like opening a time capsule to a naive past.

After we did our inventory, we created an actionable list of  refinements. I swear, it doesn't matter if you're preparing for a zombie apocalypse, an earthquake, or a hurricane.   If you try to plan too much for one particular event, you'll find yourself with a lot of stuff you'll never need or use.  Low and behold, a few days later, here came hurricane Irene.  Fortunately, the hurricane spared us.  And with that, tonight we had a retrospective.  You may have guessed.  We missed something.  What's scary is you don't get many chances to do retrospectives like this.  So, we're hoping the new additions will not lead to wasteful spending on something we'll never use.

If you want to get something right, you plan, you do, you check, and you act.  Then, you do it again and again.  You never stop.

Smoke Detector Battery Replacement Process

smokedetector

Why am I writing about replacing smoke detector batteries?  It's all about process improvement. Every six months, we are tormented by our home smoke detectors chirping after we replace the batteries.  As a rule, we know we're supposed to replace smoke detector batteries at daylight savings time (twice a year). Also, if the smoke detectors start chirping or beeping off and on, we know it's time to change the batteries.  Six months ago, I decided I was going to put an end to the chirping once and for all.  I planned to document the battery replacement process and find out how to consistently replace the batteries with no chirping.  I created a decision table to help me get it all out on paper.  I then spent a few hours writing test procedures and testing the outcomes.  If you want to drive yourself a little crazy, listen to smoke detectors screaming in your ear for a few hours.  After all was said and done, I had a successful process documented.

You may ask yourself why I didn't check Yahoo Answers or eHow for the answer to my problem.  Well, I did and they sucked!

I searched on: Smoke Detector Battery Replacement Process, How to Change the Batteries in Your Smoke Detector Chirping Smoke Detectors Stop Chirping Smoke Detectors...

So, if the planets align and there is some poor sucker out there suffering from the same problem, I hope you find this post and it works for you.

Scenario:  We live in a three level home.  Each of the smoke detectors is wired into a single circuit and they all use 9volt batteries.  We are using standard First Alert smoke detectors.  In the past, if we replaced any or all batteries, the smoke detectors would chirp randomly.

How to avoid the annoying smoke detector beeping

1. Replace the battery and make sure the + and - are facing the correct direction.

2. One smoke detector at a time, replace the battery, connect the electrical plug, then push the test button.

3. Let the detector cycle through the screaming load test.

4. If there is more than one detector, move on to the next.

What was the problem?

The problem I was running into was the hush button.  The detector was so loud, I would push the hush button before it was allowed to run it's test cycle.  I included the action on my decision table and was able to isolate the problem there.

Just in case, in the event I forgot the process, I saved it in Evernote.  I just replaced all of the batteries and it worked perfectly.  I was so excited, I just had to blog about it.

Building on failure and action versus motion

I just listened to the 37signals podcast.  It was a playback of some of the brainstorming sessions leading up to the release of the book REWORK.  For those who don't know me, I'm a complete 37signals fanboy.  They just "get it".  I don't know if it's their no BS approach to business or that they have great products.  But, I've found many of the things they created, do, and say helpful in multiple areas.  It doesn't matter if you're an entrepreneur or a project manager.  They have something for everyone. There were two things from the book I wanted to note today.  First, they talked about building on failure versus building on success.  My takeaway is if you want to reach a goal (insert your project or product here), it is easier for you to build upon small successes than to fail and start over. Example: When you're [creating] an [product] for a customer, wouldn't you rather deliver small chucks and get acceptance from the customer along the way, rather than offer a big reveal at the end and risk delivering something they don't want?  If you fail, you have to start all over.  Out of a million possibilities, you've narrowed it down by ONE.  I agree with the PDCA approach (Deming cycle). You should refine, deliver, refine, deliver.  Don't forget to deliver.  If you get something 99% done, you still have nothing.  Deliver something (regardless how small), get acceptance, and repeat.

The Second thing I wanted to note from the podcast was the mention of an Ernest Hemingway quote

Never mistake motion for action

Things don't have to be hard.  If your business [process] requires you to do wasteful (time or money) things, don't do them!  You should be doing things because they provide value (save time/money or make money).  The rest is just fat and you need to trim the fat from every business [process].  Make your [processes or products] as lean as you can without hitting the bone.  Only then can you have a good baseline.  Only then can you build on top of something.  Anything beyond that and you may be wasting time and money compensating.

Do something because you need to do it.  Don't do it because you feel obligated.  Do you need to go to that next meeting because there is valuable information being communicated?  Or rather, if you don't go it will give the impression that you're being antisocial?  Meetings are perfect examples of an crime perpetrated by people that don't have enough actual work to do or those to feel obligated by people that don't have enough real work to do.

You know why I don't check my email every 5 minutes?  Because I have things I need to get done for the customer!  Sending me pictures of LOLcats is not going to help me get that work done.  Equally, expecting me to respond to that email within an hour of you sending it just reinforces the fact that you have more time on your hands than me.

Image courtesy Flikr: Travis S.

Process Improvement and Grilling Steak

What's a weekend without grilling steak?  I would say a weekend without a good blog post idea.  Some things in life are an art and some a science.  It doesn't matter if it's project management/leadership or grilling a steak. So, what is a geeky way to write about grilling the perfect steak?  I would say compare it to the Deming cycle, or PDCA (Plan-Do-Check-Act) cycle to illustrate the point.  PDCA is a continuous quality improvement model consisting of a logical sequence of four repetitive steps for continuous improvement.

• Plan what you intend to do. In this step assess where you are, where you need to be, why it is important, and plan how to close the gap. Identify some potential solutions.
• Do try out or test the solutions.
• Check to see if the changes you tried had the effect you hoped for, and make sure that there are no negative consequences associated with them. Assess if you have accomplished your objective.
• Act on what you have learned. If you have accomplished your objective, put controls into place so the issue never happens again. If you have not accomplished your objective, go through the cycle again, starting with the Plan step.

PDCA applies to entrepreneurial ideas, application development, and anything that happens to do with my grill.  Realistically, you can apply it to anything where unknowns exist.  There are just so many variables, you need to be prepared to act and pivot.  I have grilled countless steaks and have refined my process to the point that it finally meets my quality standards.  On occasion, I do check to see if my process holds true and all I do is mess up a good steak.  I won't go into specifics as to what my perfect grilled steak process is.  (Unless someone asks)  Rather, I'll say I documented it and saved it in Evernote.

Now if only I could do the same with a hamburger.