Real World developers prefer:
- Getting things done over sitting in meetings, but understand that communication is important.
- Working code over extensive documentation, but understand that government regulations, and product sustainability require a rational approach to documentation.
- Requirements that describe business value over requirements that prescribe implementation vectors, but understand that the customer often can only express requirements in concrete examples based on his or her experience.
- Practices that work HERE over elaborate methodologies that were designed elsewhere, but understand that some established repeatable practice is beneficial.Continue Reading
Occasionally – I will get into a conflict with someone, and I don’t know why. When I look back at the conversation, what I remember, it becomes apparent that either I baited someone into an argument, or vice versa.
Sometimes this happens because I attach connotative meaning to something someone says because I think I know what he or she means. Other times I have some history that comes to bear, so I project that history on top of something. In either case, the conversation becomes broken, and communication stops.
Inevitably, it turns out that I have tried to read meaning into something that someone didn’t intend, or maybe they did, but didn’t expect anyone to pick up on it, and so they are embarrassed that it was noticeable. Perhaps the best thing to do is to act as if everyone communicates superficially, and straight, and to simply communicate back at that level. To not read anything into other peoples statements and questions.
By ignoring perceived hidden agendas, ulterior motives, personal biases – my communication becomes straight; to the point. Not balled up in other peoples issues. As an analyst, I tend to try (too hard) to unwind this stuff and sometimes get wrapped around the axle in doing so. I react to my perceptions of others’ motive and agendas, rather than simply communicating facts and my opinions (when asked), I let my opinions of others interfere with communication.
Mike Cottmeyer’s post about How to Think About Estimating is freakin’ brilliant. I applaud him for speaking his mind, and telling us how professional software delivery can get done.
Why? Because he gets down to the guts of why estimation is hard for so many teams, and while it seems to me that half of the agile community is ready to give up on estimation altogether, Mike hangs in there with a reminder that the customer has a right to a rational contemplation of cost and delivery schedule. Why – because they are paying the bill. Period. Maybe there are cases (startups, or companies with more money that sense), where the budget or the schedule are not constraining the delivery of software, where the customer doesn’t ask how much or how long. I have never been in that situation.Continue Reading
This article by Larry O’Brien got me fired up…
Not because I disagree with the notion of some software developer being 10 times as “fast” delivering software as the average developer. Because that is not what productivity means. Productivity is about leverage, not speed.Continue Reading
Here is a team formation anti-pattern that I have observed recently: Dividing the team along the lines of Skillset.
Grouping teams along skill lines, inherently sets up competition rather than collaboration. This is especially true (in my experience) in software designed, where skills vary by “architectural layer” so subteams form at the layer level. Each subteam develops some ego: my layer/skill is important, our practices are immutable.Continue Reading