Explaining the nature of software engineers to the sorry souls tasked with managing them
Showing posts with label Project Management. Show all posts
Showing posts with label Project Management. Show all posts
Monday, November 2, 2015
Incremental Illustrations
Have you ever noticed how an explanation with a whiteboard is often more clarifying than even the most meticulously designed chart or illustration? Even when there is no audience participation, a whiteboard explanation can be immensely more valuable than any professional presentation with the same information. It's certainly not because the chicken-scratch of the presenter on the whiteboard is more understandable. And it's not because the hand-drawn diagrams are more accurate or recognizable. So what is it about a whiteboard that makes the complex so understandable?
Monday, May 11, 2015
Making Meetings Count
I've heard it said that there is nothing worse than endless meetings. I almost completely agree. Having constant meetings is exceptionally counterproductive, but to say that there’s nothing worse is to exhibit a slight ignorance. It’s not the worst thing. Having no communication is even worse. So, if both extremes are bad, then what is the proper balance?
I propose that the question is not one of balance, but rather, it's one of quality and kind. If the communication is important, and the most appropriate mode of communication is chosen, then it's almost impossible to have too much of it. The answer is not to focus on how many meetings you are having or how long they last. Rather, the answer lies in making sure that you are only communicating the things that are actually important, and in making sure that you only have meetings when meetings are the most appropriate method for communicating those ideas.
I propose that the question is not one of balance, but rather, it's one of quality and kind. If the communication is important, and the most appropriate mode of communication is chosen, then it's almost impossible to have too much of it. The answer is not to focus on how many meetings you are having or how long they last. Rather, the answer lies in making sure that you are only communicating the things that are actually important, and in making sure that you only have meetings when meetings are the most appropriate method for communicating those ideas.
Wednesday, April 29, 2015
The Average Lifespan of a Crisis
Have you ever asked your team to kick it into high-gear for an extended period of time in order to meet some major challenge? Let me guess what happened…
They rose to the challenge! Everyone stayed motivated, focused, and maybe even put in some overtime! Great strides were made towards completing the goals. But then after a week or so, that high-gear began to slip. All that motivation and focus dwindled away. A few weeks later you looked back and wondered if the project was any farther along than it would have been if you had just kept the status-quo.How did I know? Because it always works that way. "Why," you ask? Well, it’s not because all developers are lazy. Allow me explain.
Tuesday, March 10, 2015
Embracing Inaccuracy
Perhaps nothing in our industry is more debated than time-estimates. Engineers hate time-estimates because they are never accurate, but everyone else desperately needs them. This tension has spawned a glut of software-development methodologies. At their core, most methodologies are all trying to tackle the same problem: time-estimates. Methodologies either claim to improve the accuracy of your estimates or they claim to lessen your dependency on estimates.
I'm not an expert on all of the various methodologies, but I do know one thing--everyone desperately wants to solve this problem. Everyone is willing to bend over backwards to achieve estimate-accuracy. If someone were able to legitimately solve this problem, the entire industry would immediately adopt the new methodology and its creator would become wildly rich. The fact that such a thing has not happened, yet, tells me all that I need to know. There is no solution, nor will there ever be one. I'm not saying that methodologies are worthless; I'm just saying that you shouldn't expect them to be a silver bullet.
So, should we cease making estimates altogether, as some have suggested? Of course not. That's absurd. Time-estimates are vital to the success of any software shop. So what is the solution? Realism. Don't waste precious energy trying to solve the unsolvable. Embrace the inaccuracy of time-estimates and learn to deal with it.
I'm not an expert on all of the various methodologies, but I do know one thing--everyone desperately wants to solve this problem. Everyone is willing to bend over backwards to achieve estimate-accuracy. If someone were able to legitimately solve this problem, the entire industry would immediately adopt the new methodology and its creator would become wildly rich. The fact that such a thing has not happened, yet, tells me all that I need to know. There is no solution, nor will there ever be one. I'm not saying that methodologies are worthless; I'm just saying that you shouldn't expect them to be a silver bullet.
So, should we cease making estimates altogether, as some have suggested? Of course not. That's absurd. Time-estimates are vital to the success of any software shop. So what is the solution? Realism. Don't waste precious energy trying to solve the unsolvable. Embrace the inaccuracy of time-estimates and learn to deal with it.
Subscribe to:
Posts (Atom)