Decisions, Decisions, Decisions: Should you Commit, Kill, or Transform? Dear JR: “I’m on three different must-do projects. I can’t tell if they are all really “must do.” If they were, wouldn’t my managers decide which one I should be on?” – A Harried Developer Dear Harried Developer: If you’re in this position, as a developer, […]
One of the most difficult parts of project portfolio management is deciding how to rank the projects — that is, determining which projects should be done now, later, and, most importantly, never. There are several ways to rank a project portfolio. Each is useful in specific situations and not so useful in others. But all
How many times have you seen this in your projects: You need something specific done such as a new database, or a specific user interface designed, or you need a release engineer, or a user interface designer, or a part of the system tested and the normal person who does that work is not available?
A manager took me aside at a recent engagement. “You know, Johanna, there’s something I just don’t understand about this agile thing. It sure doesn’t look like everyone is being used at 100 percent.” “And what if they aren’t being used at 100 percent? Is that a problem for you?” “Heck, yes. I’m paying their
I’ve been working with folks making their transition to agile. One of the hardest transitions is for the managers and technical leaders. Managers are accustomed to working in timeboxes. To them, the iteration is a timebox. But, they also are accustomed to features spanning multiple timeboxes, and that’s not OK in agile. They are accustomed
I’ve been developing an agile architecture workshop with Rebecca Wirfs-Brock. Aside from more Murphy’s Law moments than a small project deserves, we’ve encountered a number of agile architecture and program myths. Here are three for your reading pleasure. (Just in case you aren’t sure, all of these are false–they are myths.) “We don’t need no
You interviewed with a team a month ago, and you were a little concerned. It didn’t seem as if they were keeping to their iterations. Their product owner wasn’t grooming the backlog often enough to keep the backlog filled for the release meeting. They seemed to have an awful lot of defects piling up at
I’ve been blogging about agile architecture, and the responses have been fascinating. Some people are totally against the idea of an agile architect, regardless of the size of the program. Others are ready to give me the benefit of the doubt. In this column, let me clarify the case for (or against) the job-titled agile
Calvin is a technical lead, the team’s “go-to” guy. Now in his late thirties, he’s been developing since he graduated and has been a tech lead for the past five years. When anyone has a technical question, Calvin finds the answer. In the past, he’s been available to help others with their design, and he’s
“I want to move to agile. Or lean. I don’t know which. I just know I have to show progress more often. I want to be able to adapt to changing conditions. That means I have to choose between timeboxes or Kanban, right?”– a confused project manager, on the verge of adopting a more agile