finally, a picture...

While not quite a paper plane, still something, and something I think many will find interesting. First, a disclaimer, this wasn't the BEST in the group, in fact, many were quite nice, and did what they were supposed to do. The problem here, wasn't process, but I am going to talk about process, and what I think caused this outcome.
Ok, ready for the picture?

Before you laugh too hard, let me explain. This was the result of an "Agile simulation" we had today, as we look to move from waterfall to agile (I think scrum, but that hasn't been completely ironed out yet).
The plan was simple. Build a robot that follows a black line around a piece of paper, and goes as fast as possible. Well, that's what the end requirement was as of Iteration 1. Oh yeah, in Iteration 1, "Hardware" (the people building the robot) and "Software" (The people programming the robot) couldn't talk to each other. Iteration two, added two things. First the two groups could talk, and second, we had to have a little guy on the robot, you can see him hanging on for dear life, on the right side of the picture (robot's left).
Iteration three was it had to say "Good Morning" and all the barriers between groups was gone (hardware could help software, and software could help hardware).
Sounds good, right?
Well, here's the thing. The ONLY deliverable, was after the entire project was completed. Sound familiar? It sounds kinda like waterfall, with extra requirements thrown in during the process to me. Anyway, that aside, We had other issues as well. First, while we did communicate well, we had nobody with any real hardware (lego) experience, and our only design was the picture on the box, which, turns out, we didn't have to follow. So, with this, and the fact that we had no real lego experts, we ended up building something we thought would work, but in the end, last minute of the exercise, had to try to rebuild because of design flaws.
What does this have to do with projects and project plans?
EVERYTHING! ;)
First, in order for a project to succeed, you need to have the right people in the right position. Having a team of software people works great, if all you need is software. Likewise, having a team of hardware people is great, if all you need is hardware. You may be able to get by with just one or the other, many do, but you have a much higher chance of success, if you have the right skills performing the jobs.
Second, a project without a solid plan, is much more likely to run over budget and exceed time constraints. Could we have built a robot that fit the requirements in the time we had? Sure. 5 of 8 teams did. Could we have done it without a plan, Again, 5 of 8 teams did. Now, if we'd had a plan, perhaps a blueprint of sorts, I think the number would have been much closer to 8 of 8 succeeding.
I'll probably be coming back to this in later posts, but until then....

Wait, I thought this was about paper planes?

Yeah, I know, two posts, in three days, and NO pictures of project plans turned into airplanes! OK, before you come after me with pitchforks, let me assure you, there WILL be planes, some in various states of construction used to make points.
However, today I wanted to just share some thoughts from a book I'm reading, I'll share more about the book later, but it's not important to this thought. So according to this book I'm reading, the average employee spends between just 30 minutes and an hour productive a day. 8 hour day, and they're only productive for an hour TOPS? How is that possible? Then, I started looking at my day, observing how I spend it. While I may be way above that average, but still lose vast amounts of time per week on things that take me away from coding. Based on what I saw, the biggest two time sinks in my environment were email and IM. Now, I'm not talking about Yahoo or gtalk, although those certainly can be time wasters, I'm talking about the typical work related stuff. It's work stuff, taking away from work time. How's this possible? Many times, the simple interruption of even a notification on email or IM are enough to throw off your train of thought JUST enough to keep you out of your sweet spot for a couple minutes. A minute here, two minutes there add up quickly, especially in demanding environments.
As an experiment, I decided to try something for a day, that is, I left Outlook and IM off, and only turned both on for a couple minutes during compile times, which are normally dead periods, and if I hadn't built in an hour, I opened Outlook once an hour on the hour. The results, were incredible. I got more accomplished in that one day, than I could have imagined, and it seemed like I wasn't working as hard.
I'll keep you informed about this experiment in future posts, and share more from this book I'm reading too.
For those of you who may be too impatient to wait, the book is Simpleology by Mark Joyner, great book on productivity and reaching goals.

Until next time......

Wait, what's that? Project Plan Paper Planes? There HAS to be a mistake!

Nope, no mistake. I've decided to build a blog with project plans turned into paper airplanes. Why? because I thought it would be fun, and we could take the boring topic of team productivity, delivering projects on time and project management and make them, well, FUN!
I know, you're probably wondering, WHO in their right mind would, or even COULD think talking about processes and methodology could be fun. Sure, it's a boring topic, not much excitement, but hopefully with a little humor, some lightheartedness and paper air planes, we can have a good time and share thoughts about this stuff.
My background is in software development and architecture, with a bit of project management thrown in. Actually, that's only part of it. I also have a some business experience, and a degree in Business, with a heavy emphasis on PMBOK (that's Project Management Body Of Knowledge). I've worked with SEI certified projects, including gathering information about processes for certification, and setup small organizations for ISO 9001 certification.
In Software, I've worked with several methodologies including various Agile methodologies such as Scrum, XP and "custom" agile methodologies, RUP, Waterfall and even very informal iterative processes.
Ok, enough about me, in the next post, we'll start with the planes!