I admit it, I’m a bit of a geek. OK, I am an Alpha Geek. And yes, I sometimes go with the slightly more computerized solution that others might. I just don’t get Agile’s fascination with sticking hundreds of pieces of paper on the wall, though. Agile teams need a mechanism to share knowledge about stories and tasks. They often do this by using whiteboards with sticky notes (so they can be moved) or cork boards with push pins and index cards. There are columns for the stages (waiting, in process, in QA, done done done) and rows for each story. This article shows an example of one.
I talked about it with an Agile coach friend of mine, Nancy Van Schooenderwoert of Lean Agile Partners, and she made a good point that the paper system makes the whole process easier to learn. She also pointed out that all software has limitations, and it’s important to start out with the index cards or sticky notes so you don’t get the impression that any limitations in the software are a limitation in the Agile practices. I get that. But once the team is passed that point, it’s time to use software-based collaborative tools. Why?
It’s easy to say that many skills are like riding a bicycle; that you never forget them, and can just start using them again after a long period of disuse. It’s a lot harder to actually do it. This is especially true when you try to keep track of several closely related skills. For instance, I’ve learned so many computer programming languages, that when I need to learn a new one, it’s faster to see how it’s different than one I already know than to try to learn the language itself. I’m sure the same is true of other fields.
When “Jacks of all trades” (I hate the term “generalist”) like myself job hunt, there’s usually a list of possible technologies and environments we’re willing to work in, so we can’t afford to just keep up on Java, or Perl, or PHP, or .NET. We not only need to keep sharp on all of these, but we need to keep track in our heads which is which (after all many programming languages are very similar). No matter how long you’ve used a skill, a few months of unemployment can blur the details. In this post I plan to cover some helpful techniques for being ready for the technical interview or test without flipping through 300-page books each time. I will not be addressing mastering new skills, because that is an entirely different activity. Some of them may be specific to software development, but I hope there are parallels in other areas.
Like many job hunting activities, you shouldn’t wait until you’re job hunting to start doing them. After all, you want to keep marketable on skills you’re not currently using at your current job, right?