I think of development and test as partners. The developers create product and defects. The testers detect product and defects. They both need to understand what the product is supposed to be and how it’s supposed to work (the requirements). The more the developers explain the architecture and design, the better the testers can […]
Hal recently said, “Listening is one of the foundational skills of project managers.” I agree, and would add writers, tech support reps, people managers to that list. What about developers and testers? I think they need to listen also. Anyone working in an agile project needs to listen (including customers or product managers). Is there
In a recent blog post and comment, Hal Macomber said, “Listening is one of the foundational skills of project managers. Without a high level of competence at listenting projects are doomed to drift. Given the general characterization by wives that husbands don’t listen, anytime we have project managers who are men we have a potential
After my presentation last night at the Detroit PMI chapter, an attendee asked me, “Is context switching really as bad as you say it is?” Yes, it is. I believe Weinberg’s estimate of losing 10-20% of possible work-time every time you attempt to take on one more project. And, if you read Hal’s entry today,
When we have recessions (or whatever this economic slowdown is), people lose their jobs. At first, the marginal people lose their jobs, along with people who made bad job choices. However, since the layoffs started in the high tech industry, more experienced people are losing their jobs and have stopped looking for technical jobs. One
Via Steve Norrie’s weblog, I found Kovitz’s “Hidden Skills that Support Phased and Agile Requirements Engineering”. In phased development, projects promise large feature sets to a customer for future delivery. In agile projects, the requirements are refined over numerous little conversations with the customer, day in, day out. Kovitz claims the skills required for agile
On the AYE conference wiki, Jerry Weinberg said this: “no iteration should be so big that you can’t afford to throw it away if it doesn’t come out right in the end.” The longer the iteration, the less likely you can recover the project (or re-steer it, or re-guide it to an appropriate direction).
In a previous post, Attracting Suitable Candidates, Laurent caught me being vague. In Screening Out, he points to a great skit, where the technical people are talking about people skills but the HR people are talking about tools and technology.Too many recruiters just don’t get it — that software is much more people and perseverance
Bloglet subscribers saw two posts from me Friday. They saw the post I published *and* the post I saved as a draft. Surprised me. Since I know about this feature, I’ll work around it, and compose future drafts somewhere else. This isn’t a big-deal problem for me. But it was a surprise, and a
In Sunday’s Boston Globe View from the Cube column, Lisa Liberty Becker claims “Telling the truth can be hazardous to your job”. She goes on to talk about her husband, a performance test engineer, whose manager buried his reports, because “they [the reports] reflect poorly on the job he’s done.” The result? Bad product performance,