It's too easy for us to say "I'm still working on associating the widgets to the watzits". But with this level of information the customer only hears " - still - ".

Instead, we should provide visibility to the customer of the things inside the feature we're doing. "Working on associating the widgets to the watzits - I just finished the service and controller test and code and today I'm going to work on the JSP. After that I should be able to run the interaction and the tests. My roadblocks are XX". These couple of sentences by themselves provide:

• A list of subtasks
• A current status
• What's left
• What problems you're finding

Note that we didn't go into too much of a level of detail at this point - you can always clarify on subsequent sentences. Even if it doesn't mean a lot to the business people, in their brain now there's at least a "step 2 of 4" connection, making things easier for them when planning ahead. Other developers can know what area you're on and what to avoid (or what touches their stuff), and people with special skills (web devs, db people) can more or less suspect when they will be needed, helping them plan their day or be proactive.

This has another important side benefit: A lot of times us techies complain that "project managers and business types don't get it". Well, without the repetition of giving this level of detail out on a daily basis, there is no way to "teach" project managers what is hard for whom and have them remember.

These same business people who "don't understand code" will most likely eventually "get" whether JSPs are easier or harder than controllers in general, and good managers who are in tune with human factors will also understand which are harder or easier for different people (helping with job assignments) even if they don't even know what a controller is.

Development: "You want answers?"
Marketing: "I think we are entitled to them!"
Development: "You want answers?!"
Marketing: "I want the truth!"
Development: "You can't handle the truth!!!

Son, we live in a world that requires software. And that software must be built by people with elite skills. Who's going to build it? You, Mr. Marketing? You, Mr. Sales? You, Mr. Finance? You, Mr. Human Resources? I don’t think so.

Agile Chronicles: A Few Good Managers

technorati tags:agile, funny, development

After doing this for a little bit and then having a small crisis on a Scrum project (where requirements for the current sprint kept changing during the sprint). I realized that one of the big sources of mental stress is precisely trying to do both at once. Our brains just don't seem to be able to handle it.

The way I see it, our brains are pretty much still cavemen brains, used to running out and hunting deer for a very long period of time, and then going out and foraging for food for another long period of time. If you get into a "chase" mode when you're foraging, it means you're the one being chased, and it automatically fires our stressors.

technorati tags:gtd

• Dear XP - A song to XP. In Japanese.
• Scrum Masters 2 - A funny Scrum meeting. With some tips at the end.
• High Moon Studios on Scrum. Pretty funny.
• Paul C Deemer talking about scrum.

technorati tags:scrum, xp

Here’s a few tips I’ve learned in my short time on this earth that have kept me from getting too much accomplished.

fullduplex.org » How to Do Nothing at Work, and Get Away With It

He goes on to explain his "tips".

It left me thinking two things. First, I'm very glad he's not on my team, second, the value of scrum and agile methodologies to get rid of the dead weight. Here's my response to it:

I'm a lead in a web development team, and I manage and assign work for web developers. This is the behavior that gets you fired from my team.

Let's analyze it shall we?

Look Busy/Look Stressed: We're a Scrum team, we meet every day to talk about what we did the day before, what we will do today, and what roadblocks we have in our way. So why aren't you asking for help? I have no use for web devs with such little people skills that they won't even ask other members of their peer group for help. If you can't be on a team, maybe you should go independent and not work on a team.

Speak Quickly/Hide/Break Limb/Make Excuses/Never Leave your office/rearrange furniture,etc: The only thing here that may work is breaking a limb. And even then if that happened to you it would make you a prime candidate for pairing with another developer. All the others, your non-activity would show up on the cvs commit log. In my team we have a great cvs mailer that shows colored differences of what you did, and I check it daily.

Choose a Profession people don't understand: Your manager is probably not a techie, or he's as lazy as you are about checking your work. You're a perfect example why only techies can manage techies, and techie managers need to code at least 20% of their time on the current project so they can keep their skills. Also following the cvsspam list helps understand the issues.

So you see, using Scrum or other Agile methodologies underscores the lack of value of these people and will make it obvious who needs to drop off your team. Either that or they'll shape up via peer pressure, which in the long run will make the ex-lazy team member happier as well.

technorati tags:agile, scrum, lazy, development

Talk-style podcasts are different than most in that you tend not to listen to them over and over like you do a music playlist. Now when you are in your car, you need to be looking at the road. There are a couple of problems with podcasting and the highway.

First, the metadata accuracy problem. The podcasts typically "acquire" mispellings on things like the podcast name, and there is no way to get to a date sorted (or reverse date sorted) list of the podcasts you listen to one by one. Some of the smarter podcasts follow a naming convention, such as "MyCoolCast #0012 - Nov 10", so a natural sort order provides more or less what you would expect.

Second, the metadata in iTunes vis-a-vis play counts and "listened to" bit is severely broken. The ideal situation would be to have a Smart playlist that would provide you with the podcasts you haven't listened to, right? Well, that would be perfect if the play count stuff worked. But as it turns out it doesn't.

This morning I tried using the smart playlist to create something that would only show the podcasts I have not yet listened to, so I'm not a driving hazard when a podcast ends. However, there is no filter for the listened to bit. I thought, well, I can just add a "play count is greater than 0" filter, under the assumption that if I set the "listened to bit" on the podcasts I had already gone through before (sometimes I skip the 'cast because it's boring or I heard everything but the trailing music) it would move the play count to 1 automatically for me. Alas, no go. Worse yet, there is no way (other than editing the library files directly) to change the play count manually, and there seems to be a threshold before which the iPod won't increase the Play count flag. I don't actually want to delete the podcasts (I'm a bit packrat), I just want it off that particular "while driving" list.

So it is impossible (or at least harder than what a software engineer can manage in a few minutes) to create a playlist for the podcasts you haven't yet listened to. There would be a couple of solutions for this, which Apple could implement:

1. Make the Already listened to flag also set the Play count to 1. This would require no changes on the Smart Playlists
2. Add the filter for already listened to to the Smart playlists

Without this, I keep finding myself just switching to regular talk radio so I don't have to be a road hazard.

Now this illustrates how important metadata is, and how humans relate concepts in ways the computer can't. A lesser implementer pretends to be smarter than the rest of us and says something like "but it's not correct, they're two different data elements". An implementer who cares about the human aspect of metadata goes ahead and implements something like #1 above (maybe with a dialog box asking if it's ok and a checkbox for "don't ask me this again"). Note that he doesn't do it because it's correct, but because it is what people are likely to expect. Technology is made for humans. I have high hopes for Apple in that they seem to understand this more than other companies, but with this - "you're making me nervous".

Metadata is frustrating like that. It's not typically visible, it has rules that are specific to the business domain, and when it goes wrong is frustrating for the user. As our hard disks get bigger and bigger and we start storing more and more stuff, the metadata will become more and more important, and issues such as the human aspect and expectations of metadata will become more and more crucial for the success of the underlying platform that manages that metadata, whether it be iTunes, TiVo or any other content management product.