Software Engineering, Project Management, and Effectiveness
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 InboxMy 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:
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-PatternsI think it's important to note the anti-patterns:
My Related Posts
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:
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:
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.
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.
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.
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:
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 LeanJames writes about 7 key principles in Lean:
Example of Deferring CommitmentI 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 EngineeringFrom 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 LifeHow can you use Lean principles in your software development effort? ... your organization? ... your life?
Here's my short-list of techniques I use for improving efficiency on a given task:
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.
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
Guidelines Help Carry Lessons ForwardWhile 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 TooNote 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.