I spoke with a new manager, Drew, the other day. His days are full. He’s got tons of meetings. He tries to provide feedback and coaching to his team members, but he has crises up the wazoo. Drew asked for coaching: “I have way too much to do. I need to learn how to manage […]
We talk a lot in agile about generalizing specialists. Scott Ambler has a terrific essay on what a generalizing specialist is: Has one or more technical specialties… Has at least a general knowledge of software development. Has at least a general knowledge of the business domain in which they work. Actively seeks to gain new
Way back when I was a developer, my professors taught me structured design and design by contract. Those were supposed to be the silver bullets for programming. You see, if you specified things enough, and structured things enough, everything would all work out. I thought I was the only idiot that structure and specification didn’t
In a recent estimation workshop, one of the participants asked, “How do we estimate something we’ve never done before?” “Is it a feature or a project?” I asked. “A feature,” she said. “How do you do things now?” Based on her previous comments in the workshop, I suspected she was pretty good at what she
One of my clients was having trouble with estimating work they had never done before, so I wrote an article explaining spikes. That article is up on agileconnection: Need to Learn More about the Work You’re Doing? Spike It! It was a little serendipity; I taught an estimation workshop right after I explained how to
by Johanna Rothman. Originally published in Cutter’s Business-IT Alignment E-Mail Advisor, July 7, 1999. “There is nothing permanent except change.” — Heracleitus As our industry has changed from mainframes to client-server to distributed systems and the Web, the tools we use to develop and test our software have changed. How do we keep our staff