Get Your Ears On
As we gain more experience and expertise in our selected domains, there becomes a stronger tendency to lean primarily on that knowledge to solve problems. Sometimes this works, but sometimes we tend to lean too far in that direction and forget that we should be listening before we start solving. There are times when we need to remind ourselves to get our ears on. Read more
ESL
I asked teams in a workshop this week to come up with issues they faced, and one group identified their biggest issue as a failure to communicate. As they listed their root causes for this extremely broad issue, ESL came up in the list. More importantly, though, came an insight that expands on that theme of using a different language on each other. Read more
Engagement Beats Handoff and Jargon
Quite often when we talk about challenges in this industry, we lament that our customers don’t get it, or that those hardware guys seem to live in their own little world (that is, if we’re in software – for those in that hardware world, the shoe is often on the other foot). If we dive into the majority of those communication issues, one of the problems is that we have not really engaged with ‘the other side’ – we have been busy confusing them with our jargon. Read more
Focus On the Interfaces
Recall a while back where I wrote about a couple of training sessions in one company where there was a simulation involved, the teams building a device after spending some time working out the network of activities required to get the job done. Back then, one class managed to develop a well-conceived network but failed to accomplish the construction task, while the other managed to build the device, despite not having an end-to-end schedule. Read more
Candor
I’ve always been convinced that failure to communicate is at the root of almost all challenges we face in software development. Process and procedures are a means of ensuring that we do the right things at the right time, analysis models help us communicate different aspects of our product in more precise forms than the English language can convey. Read more
Planning to Build vs. Building the Plan
Apparently, Dwight D. Eisenhower once said “In preparing for battle, I have always found that plans are useless, but planning is indispensable.” Read more
Idiot Lights
It is quite easy to justify doing nothing to improve how your organization develops software. Whether it takes the shape of “we don’t have the budget”, or “we can’t afford the time, we’re just too busy right now”, the point is the same. It can be paraphrased as “We have decided, consciously or not, that our current painful approach is preferred to spending the money or time to do something about it.” Read more
Practicing Safe PM
Inevitably, if we build our project schedule based on reasonable expectations of how long it will take to do the work and an initial cut at dependencies between activities, the resulting overall duration will be well beyond our hopes, goals, and promises. This is a challenge that will not go away, and there are different ways to deal with the issue. Read more
No Apparent Problem to No Actual Problem
However we would like to frame it: an approach to problem solving, a progression of learning, or simply how we grow over time, there are stages that we pass through along the way. Read more
Technological Heart Attack
Whirr-click…whirr-click…barely perceptible. I wouldn’t have noticed it at all, except for the fact that I was starting to wonder whether my computer was going to wake up at all. Read more
Books
Develop skills to thrive in the face of workplace chaos (now available at Banyen Books and selected Chapters and Coles in Vancouver):
Ten years of observations on agility, in e-book form:
A practical guide to human dynamics in project teams:
