Removing delays — for prizes!
OK, here’s the plan. Anyone who wants to answer the following question with a comment is eligible for the prize. The winner will be chosen at random from valid, thoughtful answers starting on Tuesday evening. The prize will be your choice of:
) celebratory bragging comment saying that indeed, you are simultaneously a talented and lucky personIf you don’t want to leave your full name, just make sure that I can get back to or identify you via the email you put down (which is not shown on the page.) I think this will be an interesting exercise to see where potential delays are and to start a dialog on where we can try to remove delays in our processes. The description talks about code, but your answers don’t have to be limited to it.
Imagine that you had a magic wand that removed delays in your work. In other words, you’d do things the same way, but when you needed someone, they’d immediately be available. Perhaps your specifications or work description would be ready for the next task right when you got done implementing your current feature. What would happen if you didn’t have to wait for feedback from test or customers? In other words, as soon as code was written, you knew whether it worked or not. As soon as code was written and tested, a customer would tell you if it was what they wanted or not.
So the questions to answer are:
What delays would you remove? If you had to pick one, what would it be?
What would achieving this do for your productivity?
What is currently in the way of achieving this?
next post: The Pomodoro Technique
What delay would I remove if I had to pick one?
The “build -> start server -> launch browser -> render screen -> login -> navigate to page -> retrigger operation” delay.
Achieiving this would drastically speed up the occassional but inevitable period where I do cosmetic and behavioral tweaks toward the end of a feature. Not that I’d ever allow myself to fall into the rapid cycle tweak-n-build frenzy that hallmarks development-by-accident. I am, afterall, a True Professional. (Whatever!) But plenty of times, having “Ctrl+S, F5″ turn-around-time would make the difference between “stable by lunch” vs. “waiting until I can set aside a few hours this afternoon”.
In the way of achieving this: The reality of ASP.NET and C#, IMO. You build, you usually lose your session. There’s shut down and restart time. It’s the age-old compiled vs. interpreted thing. For non-GUI parts, I think following a TDD approach would help as we can possibly avoid the web overhead. Becoming more savvy in tweaking ASP.NET builds and dev environments might help.
And none of what I just wrote is terribly interesting. It’s a micro-optimization compared to the level you’re talking about (I think), given your (probably) lean process. You’d have to be pretty darn streamlined already for it to be a heavy hitter. And despite how I’ve talked it up, it’s not even in the top 5 most valuable improvements on my project. My project is so decidedly non-lean that fixing any one delay isn’t going to result in a productivity breakthrough. Delay reductions are nice but we simply aren’t geared to exploit them. We’re more piles than pipeline, if you grok.
It seems like the specs/work description would be the most efficient of the fixes for me personally. Things can pile up in the test and customer acceptance queues without it affecting your productivity, but when you have to struggle to get a description of the next thing you’re supposed to do, it brings things to a halt.
You can do this currently if your queue of work is kept full and sorted. If you don’t have a queue, there’s communication lag along with decision lag in the way.
Then again, I sometimes find that decision lag can be beneficial in helping a customer figure out what they need and/or want.
Granger won the coin toss, and opted for the Rapid Development book.
Matt, I thought your comment was pretty insightful. I remember when I was working on a rails project and finally “got” it that doing the tests in an automated way would actually be faster in addition to being less error-prone. It would certainly help to be in the flow better. Perhaps there are other high value activities, but it seems like everything adds up. My understanding of the piles and pipeline part is that you have large batch sizes that move through the system. I could have misinterpreted this.
Granger, I have had similar problems in the past with not having enough important work queued up. Perhaps there is a feedback problem nonetheless? Would getting things to the client and approved assist them with knowing what has been done and what the next steps are? I agree that the queue would be helpful. I’ve found it hard to enforce having the queue be filled if the client does not see filling it as urgent. I guess this is where making a business case for lost value would be helpful.
I like thought experiments like this because they kind of put me in brainstorming mode versus analytical mode. Instead of thinking “I can’t”, I think, “What if?” Anyway, the delay that I would most like to have removed on one of my projects is the time from when I believe that I am finished to when I get feedback about the solution. When the code is still fresh in my mind is the best time to work on fixing it or changing something. When things go stale I am more likely to have errors. Plus, it feels good to have that more immediate feedback/gratification of delivery. The “atta boy”, if you will. There are other things that would be great to change, but this is the most important for me at the moment. Hopefully this realization will assist me in reducing the delay.
Thanks for your comments!