In Organizing an Agile Program, Part 1, Introduction, I suggested you think about the communication paths of your programs. Instead of hierarchies, I suggested you think of networks of teams. In Organizing an Agile Program Part 2, Networks for Managing Agile Programs, I showed you how loosely connected networks might work. I explained how you […]
I reported on my progress cleaning up my office Cleaning Up the Office, Round 2. I hadn’t let it get that bad since that round of organizing, but I did ask for help from Daughter #2 in May, to buy some bins and drawers to continue my never-ending attempts to stay organized. The past 8
Imagine you’re a project manager. You talk to your technical lead and ask how far along the team is. “Oh, we’re about 90 percent done,” he says. If you’re like most project managers, your heart sinks. You’ve been here before. Ninety percent done means the other 90 percent is left to do. But what can
I’ve taught several workshops where people wanted to learn how to start adopting some agile approaches. They knew about timeboxing, but didn’t quite see how to make it work. The part they were missing was having working valuable product at the end of each timebox. I explain that to the participants, and they nod sagely.
Joshua asked me to clarify what I meant by implementing by architecture. Here’s my picture-story. When a team implements by architecture, they tend to be functionally-based teams implementing across the architecture. When a team implements by feature, they are cross-functional teams. When teams implement by feature, they do what’s needed in whatever part
© 2005 Johanna Rothman. This column originally appeared on Stickyminds.com Summary: Every manager has a story to tell. Find out how one management professional tackles a fictional dilemma. The story may be made up, but the solutions are tried and true. In this installment, Johanna Rothman recounts the tale of a wayward project rescued by a