Agile Is NOT a Process

Rant warning.
I've heard one too many people either ask me if I work in an agile environment or tell me that their team is doing agile development. The English teacher in me goes berserk when I think of the abuse they are doing to the word agile. They have taken a simple, clear word and turned it into marketing slang for any manner of product management process that doesn't involve long range planning.
I've worked on several teams that were "agile" and been to training to for another that was attempting to be "agile". Let's just say I've seen mixed results.
In fact, one of the most agile teams I worked on did formal long range project planning with feature specs and everything. We had an overall idea of what we wanted to build and worked towards it. However, we also did good beta programs and customer outreach during the development cycle. This way we could validate what we were doing against what was really needed. If we needed to change, we did. It probably helped that I worked with a very talented group of software engineers who liked modular architectures and an excellent customer facing product manager who understood the customer's as well as the the developer's.
The least agile team I worked on also followed the classic model. However, they were a monolithic, top-down driven team that was a slave to their process. Development cycles were months long and getting a new feature in, or responding to a change in priorities, was virtually impossible. I wasn't on this team long (it made me crazy), so I have no idea what confluence of factors made it so rigid.
This same team is now "agile" thanks to adopting SCRUM. They still have long development cycles, although they are split into two week sections. Getting new features, or responding to changing demands, is still virtually impossible. The things that have changed are that less people actually know what the feature set will look like, the writers are more in the dark than usual, and the release date is so fuzzy that it may simply arrive without warning.
I worked on an XP "agile" team as well. I'd put there agility in the moderate range, but they were that agile before XP. What XP did bring was more frequent meetings, less shared information, and a steep decline in release quality. We still marched for a set date and a predefined feature set, but product management reserved the right to change the feature set at will without changing the release date. We also did away with any meaningful sense of resource planning. More meetings and less quality is the kind of outcome I look for from a hot process.
One friend was telling me that his work estimates for a big project were rejected because they were done in hours. Since they are SCRUM "agile", estimates cannot be anything as tangible as hours. So, he went back to his desk, removed the word hours from the estimates, and waited a day before resubmitting the estimates. Naturally, they were perfectly OK. One of the funniest parts of this to me was that he was asked to do planning four months out.
At FuseSource we are pretty agile, without using any formal process. We keep in touch with customers, design in a way that makes responding to change easier, keep open lines of communication between all functional groups, and get the job done. Things can get a little chaotic, but that is pretty common in software development. The key point is that we make solid quality products and can respond to customer needs quickly.
So my point is that being agile isn't about doing "agile". Most of what people mean way they say they are on a team that is doing agile development is that they are following one of the "agile" product management processes that their management was sold. If the team isn't agile, no amount of mystical "agile" religion will make it agile. All doing "agile" will do is replace one set of rigidity with another. On the flip-side an agile team will be agile regardless of the process imposed on it. There are definitely processes that will be less efficient than others, but a truly agile team will either stop using them or find a way to make them work.

Video Tutorials

Video is all the rage these days, but I have been trying to avoid making them. It's not that I don't appreciate the strength of videos for marketing and for visual learners. It is just that my medium is static words on a page, not moving pictures with audio.
It came to pass that FuseSource wants video tutorials and the writers have been assigned the task of producing them. I did the first one recently and it was an interesting challenge - I should say series of challenges.
The first challenge is figuring out what software to use building the tutorials. There are a number of screen recording tools available, like Camtasia, you can record a WebEx, or you can go with a tool geared more towards e-learning and demo creation, like Captivate. I quickly ruled out the WebEx idea. Some consultation with co-workers who make video tutorials at Progress strongly suggested using Captivate over Camtasia. Captivate is more forgiving and more flexible.
The big problem with Captivate is the price tag.... So, I set out to find a freeware alternative if possible. Fortunately I stumbled upon Wink from DebugMode(http://www.debugmode.com/wink/). I has most of the features of Captivate for free!!
Tool in hand, I created the video portion of the tutorial. Wink lets you record as a stream or based on mouse/keyboard clicks. I opted for the mouse/keyboard clicks method because that was what I was told worked best. So, I ran through the demo I was using for the tutorial and captured everything. This was a little nerve wracking because you want it to go smoothly. This is where doing it based on mouse/keyboard clicks comes in handy. If you record the demo as a steam, you have to restart every time you make a mistake. Using the mouse/keyboard saves the session as a collection of individual frames so you can remove mistakes later.
The resulting video capture was pretty good overall. A few places were choppy and in a few places the cursor jumped around a bit.
Wink lets you do a bunch of editing of the individual slides, so I could fix most of the choppy bits. I could also edit out any mistakes. It also allows you to add text boxes, images, and links onto the frames. This is one place where the price of the software is evident-there are not a lot of choices for button styles or text box controls.
Laying down the audio was tedious, but not because the tool makes it hard. In fact Wink makes it pretty simple. Doing audio is tedious for several reasons. The first is that I hate listening to my own voice for an entire day. Second, I'm not a trained voice talent, so I am not graceful at reading prepared texts. There are stops, stutters, strange tonal changes, pauses. I had to redo several portions of the audio multiple times to get it acceptable.
So, the first one is done. I've learned that doing a video takes a lot of prep work. You need to plan out what you intend to do and make sure that it is a) not too long b) visually interesting (watching a maven build scroll by does not make good video) c) going to work consistently. I've also learned that it takes a long time to make a short video. This first one took the better part of a day and it is only a few minutes long. I'm pretty sure I'll get better, but not so sure I can get faster.