Contents: This month’s Feature Article: Using One-on-Ones to Build Trust Announcements =-=-=-=-=- Feature Article: Using One-on-Ones to Build Trust A colleague of mine just arrived at a new company as a manager. He’s inherited a group where management was (and still is) a dirty word. Due to some of the previous managers’ actions, the technical […]
Contents: This month’s Feature Article: Becoming Comfortable with One-on-Ones Announcements =-=-=-=-=- Feature Article: Becoming Comfortable with One-on-Ones Last month’s feature article was about building trust with one-on-one meetings. In response, a reader mailed me this question: “How long should it take to become comfortable with one-on-ones?” Ok. Here’s the standard answer: It depends. It depends
I recently spoke with a recruiter who told me, “I just can’t seem to find agile candidates. No one has “stand-up meetings’ listed on his resume.” When you’re reviewing resumes, it would be nice to find some keywords so you could see if the candidate has had agile experience–but it’s unlikely. However, implementing a few
Technical debt is the unfinished work the product development team accumulated from previous releases. This debt includes: design debt, where the design is insufficiently robust in some areas; development debt, where pieces of the code are missing; and testing debt, where tests were not developed or run against the code. Technical debt is common, but
When it comes to projects, there are as many questions to answer as there are project teams, but “Where are we?” is by far the most popular. The key to understanding a project is to make regular measurements—both quantitative and qualitative—and display the measurements publicly. When project managers display these measurements as part of the
Senior managers — the people who make strategic product decisions — need to know when they can expect those products to release. The organization of current product releases against a timeline is a project portfolio. And, planning the project portfolio in an agile environment is different — but not harder — than planning the project
Technical debt is the unfinished work the product development team accumulated from previous releases. This debt includes: design debt, where the design is insufficiently robust in some areas; development debt, where pieces of the code are missing; and testing debt, where tests were not developed or run against the code. Technical debt is common, but
Summary: If someone on your project team isn’t working up to par, it might take more than a simple showing of your disapproval to put him on the right track. Johanna Rothman suggests trying specific and useful feedback—show your employees the light before you show them the door. Margaret, a manager, was concerned about one of
My column over at the Fast Company/Inc hiring site is up. See Developing a Professional Portfolio. You can’t leave comments there, so please leave comments here.
I’ve been working with some companies who do hardware/software systems. Most often, they have some embedded code too, just to make life interesting. To be honest, I don’t know how to do implementation by feature for a whole brand new system. Here’s what I’ve been suggesting: Prototype the software architecture as early as possible,