“Get stuff done every day. If the task is too large, break it down and explain what you’re doing. But get something done every day.
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.