I'm a fan of sharing lessons learned along the way.  One light-weight technique I do with a distributed team is a simple mail of Do's and Dont's.  At the end of the week or as needed, I start the mail with a list of dos and dont's I learned and then ask the team to reply all with their lessons learned.

Example of a Lessons Learned Mail

Collaboration

• Do require daily live synchs to keep the team on the same page and avoid churn in mail.
• Do reduce the friction to be able to spin up Live Meetings as needed.

Guidance Engineering

• Do index product docs to help build categories and to know what's available.
• Do scenario frames to learn and prioritize the problem space.
• Do use Scenarios, Questions and Answers, Practices at a Glance, and Guidelines to build and capture knowledge as we go.
• Do use Scenarios as a scorecard for the problem space.
• Do use Questions and Answers as a chunked set of focused answers, indexed by questions.
• Do use Practices as a Glance, as a frame for organizing task-based nuggets (how to blah …)
• Do use Guidelines for recommended practices (do this, don't do this … etc.)
• Do create the "frame"/categories earlier vs. later.

Personal Effectiveness

• Do blog as I go versus over-engineer entries.
• Do sweep across bodies of information and compile indexes up front versus ad-hoc (for example, compile bloggers, tags, doc indexes, articles, sites … etc.)

Project Management

• Don't split the team across areas.  Let the team first cast a wide net to learn the domain, but then focus everybody on the same area for collaboration, review, pairing …etc.

Tools

• Do use CodePlex as a channel for building community content projects.

Guidelines Help Carry Lessons Forward
While this approach isn't perfect, I found it makes it easier to carry lessons forward, since each lesson is a simple guideline.  I prefer this technique to approaches where there's a lot of dialogue but no results.  I also like it because it's a simple enough forum for everybody to share their ideas and focus on objective learnings versus finger point and dwelling.  I also find it easy to go back through my projects and quickly thumb through the lessons learned.

Do's and Don'ts Make Great Wiki Pages Too
Note that this approach actually works really well in Wikis too.  That's where I actually started it.  On one project, my team created a lot of lessons learned in a Wiki, where each page was dedicated to something we found useful.  The problem was, it was hard to browse the lessons in a useful way.  It was part rant, part diatribe, with some ideas on improvements scattered here or there.  We then decided to name each page as a Do or Don't and suddenly we had a Wiki of valuable lessons we could act on.

If you're backlogged and you want to get out, here's a quick, low tech, brute force approach.  On your whiteboard, first write your key backlog items.  Next to it, write down To Do.  Under To Do, write the three most valuable things you'll complete today.  Not tomorrow or in the future, but what you'll actually get done today.  Don't bite off more than you can chew.  Bite off enough to feel good about what you accomplished when the day is done.

If you don't have a whiteboard, substitute a sheet of paper.  The point is keep it visible and simple. Each day for this week, grab a new set of three.  When you nail the three, grab more.  Again, only bite off as much as you can chew for the day.  At the end of the week, you'll feel good about what you got done.

This is a technique I've seen work for many colleagues and it's stood the test of time.  There's a few reasons behind why this tends to work:

• Whiteboards make it easy to step back, yet keep focus.
• You only bite off a chunk at a time, so you don't feel swamped.
• As you get things done, you build momentum.
• You have constant visual feedback of your progress.
• Unimportant things slough off.

My Related Posts

• My Personal Approach for Daily Results
• MUST vs. SHOULD vs. COULD
• Scannable Outcome Lists
• Using Scannable Outcomes with My Results Approach

Here's a quick rundown of our patterns & practices VSTS related Guidance projects.   It's a combination of online knowledge bases, guides, video-based guidance and a community Wiki for public participation.  We're using CodePlex for agile release, before baking into MSDN for longer term.

Guides

• patterns & practices Performance Testing Guidance for Web Applications - This guide shows you an end-to-end approach for implementing performance testing. Whether you are new to performance testing, or looking for ways to improve your current performance testing approach, you will find insights that you can tailor for your specific scenarios.
• patterns & practices Team Development with Visual Studio Team Foundation Server - This guide shows you how to make the most of Team Foundation Server. It starts with the end in mind, but shows you how to incrementally adopt TFS for your organization. It's a collaborative effort between patterns & practices, Team System team members, and industry experts.

Knowledge Bases

• patterns & practices Performance Testing Guidance Wiki - This project is focused on creating an online knowledge base of how tos, guidelines, and practices for performance testing, including performance testing using Visual Studio Team System. It's a collaborative effort between industry experts, Microsoft ACE, patterns & practices, Premier, VSTS team members, and customers.
• patterns & practices Visual Studio Team System Guidance Wiki - This project is focused on creating an online knowledge base of how tos, guidelines, and practices for Microsoft Visual Studio Team System. It's a collaborative effort between patterns & practices, Team System team members, industry experts, and customers.

Video-Based Guidance

• patterns & practices Video-Based Guidance for Visual Studio Team System - Our video-based guidance is a set of short "what is" and "how to" videos.

Community Wiki

• patterns & practices Community Wiki for Team System - This is an experiment to see what a little harnessed community power can do. This is a partner site of the patterns & practices Visual Studio Team System Guidance Project.

Note that we're busy wrapping up the guides.  Once the guides are complete, we'll do a refresh of the online knowledge bases.  We'll also push some updated modules to Guidance Explorer.

My Related Posts

• patterns and practices Performance Testing Guidance
• Performance Testing Guide Beta 1 is Available
• TFS Guide Beta 1 is Available
• Video-Based Guidance for Visual Studio Team System Now Available
• patterns and practices Visual Studio Team System Guidance Now Available

If you want to tune your software engineering, take a look at Lean.  Lean is a great discipline with a rich history and proven practices to draw from.  James has a good post on applying Lean principles to software engineering.  I think he summarizes a key concept very well:

"You let quality drive your speed by building in quality up front and with increased speed and quality comes lower cost and easier maintenance of the product moving forward."

7 Key Principles in Lean
James writes about 7 key principles in Lean:

1. Eliminate waste.
2. Focus on learning.
3. Build quality in.
4. Defer commitment.
5. Deliver fast.
6. Respect people.
7. Optimize the whole.

Example of Deferring Commitment
I think the trick with any principles is knowing when to use them and how to apply them in context.  James gives an example of how Toyota defers commitment until the last possible moment:

"Another key idea in Toyota's Product Development System is set-based design. If a new brake system is needed for a car, for example, three teams may design solutions to the same problem. Each team learns about the problem space and designs a potential solution. As a solution is deemed unreasonable, it is cut. At the end of a period, the surviving designs are compared and one is chosen, perhaps with some modifications based on learning from the others - a great example of deferring commitment until the last possible moment. Software decisions could also benefit from this practice to minimize the risk brought on by big up-front design."

Examples in Software Engineering
From a software perspective, what I've seen teams do is prototype multiple solutions to a problem and then pick the best fit.  The anti-pattern that I've seen is committing to one path too early without putting other options on the table.

A Lean Way of Life
How can you use Lean principles in your software development effort?  ... your organization?  ... your life?

More Information

• Lean Software Engineering
• Wikipedia Lean Manufacturing

Today I helped a colleague clear their inbox.  I've kept a zero mail inbox for a few years.  I forgot this wasn't common practice until a colleague said to me, "wow, your inbox doesn't scroll."

I didn't learn the zen of the zero mail inbox over night.  As pathetic as this sounds, I've actually compared email practices over the years with several people to find some of the best practices that work over time.  The last thing I wanted to do was waste time in email, if there were better ways.  Some of my early managers also instilled in me that to be effective, I needed to master the basics.  Put it another way, don't let administration get in the way of results.

Key Steps for a Clear Inbox
My overall approach is to turn actions into next steps, and keep stuff I've seen, out of the way of my incoming mail.  Here's the key steps: 

1. Filter out everything that's not directly to you.  To do so, create an inbox rule to remove everything that's not directly To or CC you.  As an exception, I do let my immediate team aliases fall through.
2. Create a folder for everything that's read.  I have a folder to move everything I read and act on.  This is how I make way for incoming.
3. Create a list for your actions.  Having a separate list means you can list the actions in the sequence that makes sense for you, versus let the sequence in your inbox drive you.

Part of the key is acting on mail versus shuffling it.  For a given mail, if I can act on it immediately, I do.  If now's not the time, I add it to my list of actions.  If it will take a bit of time, then I drag it to my calendar and schedule the time.

Anti-Patterns
I think it's important to note the anti-patterns:

1. Using your inbox as a large collection of action and semi-action items with varying priorities
2. Using your inbox as a pool of interspersed action and reference items
3. Adopting complicated mail and task management systems

My Related Posts

1. Scannable Outcome Lists
2. Using Scannable Outcomes with My Results Approach
   

Here's my short-list of techniques I use for improving efficiency on a given task:

• Increase the frequency.  If I'm not efficient at something and I need to be, I start doing it more.  A lot more.  Frequency helps me get over resistance.  I also get more chances to learn little things each time that help me improve.   
• Reduce friction.  This is important and goes in hand with increasing the frequency.  When I do something more, I can quickly find the friction points.  For example, I was finding that pictures were piling up on my camera.  The problem was I needed my camera's cradle to transfer my pics.  When I got my new camera, I could transfer pics through the memory disk without the cradle and the friction was gone.  It was a world of difference.  I pay attention to friction points now in all the recurring tasks I need to do.
• Model the best.  If I look around, I can usually find somebody who's doing what I want to do, better than I'm doing it.  I learn from them.  For example, when I was doing an improvement sprint on making videos, I learned from Jason Taylor, Alik Levin, and Alex Mackman, since they were all doing videos for some time and had lessons to share.
• Batch the tasks.  There's two ways I batch tasks.  First, I gather enough so that when I do them, I'll learn in a batch.  Second, I look for way to split the work and to batch the workstreams.  For example, when I was working on an improvement sprint for speech to text, I made very little progress if I tried to dictate and edit.  I made much more progress when I dictated in batch, and then edited in batch.  It was a simple shift in strategy, but made a world of difference.

While each technique is useful, I find I improve faster when I'm using them together.  It's synergy in action, where the sum is better than the parts.

My Related Posts

• 30 Day Improvement Sprints
• Making 30 Day Improvement Sprints More Effective
  

Grigori Melnik joined our team recently.  He's new to Microsoft so I shared some tips for effectiveness.  Potentially, the most important advice I gave him was to timebox his day.  If you keep time a constant (by ending your day at a certain time), it helps with a lot of things:

• Worklife balance (days can chew into nights can chew into weekends)
• Figuring our where to optimize your day
• Prioritizing (time is a great forcing function)

To start, I think it helps to carve up your day into big buckets (e.g. administration, work time, think time, connect time), and then figure out how much time you're willing to give them.  If you're not getting the throughput you want, you can ask yourself:

• are you working on the right things?
• are you spending too much time on lesser things?
• are there some things you can do more efficiently or effectively?

To make the point hit home, I pointed out that without a timebox, you can easily spend all day reading mails, blogs, aliases, doing self-training, ... etc. and then wonder where your day went.  Microsoft is a technical playground with lots of potential distractions for curious minds that want to grow.  Using timeboxes helps strike balance.  Timeboxes also help with pacing.  If I only have so many hours to produce results, I'm very careful to spend my high energy hours on the right things.

My Related Posts

•  The Secret of Time Management