Many of my clients feel stuck with their component teams. They feel they must implement across the architecture, not through it. That’s because the people are organized in component teams. As the organization grows, so does the number of component teams. The more component teams they have, the more complexity they create in the teams, in
I keep encountering managers and consultants who want to make work “fun” for people. As a goal, “fun” is a bunch of hooey. Before I was a consultant, I held various Director-level positions at local companies. Each organization had mandatory fun days. In one organization, we played softball. Yes, everyone—especially the managers—had to play softball
Does your team have to keep two sets of “books”? You have an agile roadmap to see where you’re headed. You have a smallish backlog of the near/upcoming work. You’re delivering on a frequent basis. And, someone on your team keeps a Gantt chart because a manager wants to see the team’s progress in a
When Esther and I wrote Behind Closed Doors: Secrets of Great Management, we didn’t really think one-on-ones were a secret. But, managers weren’t conducting the one-on-ones regularly. The managers canceled for other “higher priority” meetings. The first modern management book is about how managers manage themselves. Part of that management is how and when they
I’ve been working at the intersection of the project portfolio and the product roadmaps. (You can tell because of the various posts about information persistence.) Here’s what I find when I work with my clients: They have years worth of projects in the project portfolio. They have years worth of ideas in various states of description in
I’m in the midst of collecting the management myths into three books. The series is currently titled “Make Modern Management Easy”. The first book is Practical Ways to Manage Yourself. I was thinking of starting with managing the organization issues. The way organization attempt to “manage performance” and do/do not manage the project portfolio has
I listened to The Ultimate Metric: Identifying the Right Problems to Solve. The guest, Janelle Klein, said: Technical debt is not a loan I thought that was brilliant. She went on to explain that when we talk about “debt” managers think they have dials to manage the debt. Uh oh. Wrong. When managers think in
I’ve been thinking a lot about planning recently. Many of my clients want to create long-term plans, based on data with short validity, even for products in a high state of change. I suspect the first question is how much change do you need in your product, not how good your information is, or how
I’ve been working with several managers at organizations large and small, who want to capitalize their software “earlier.” These managers have some strongly-held beliefs about the people: People are resources Resources can multitask on several projects at a time If “headquarters” does the difficult work, you can move the “grunt” work to lower wage areas
Several recent clients want help with these problems: Estimation isn’t accurate. Because the estimation isn’t accurate, management can’t predict when they can release anything. Managers can’t manage the capitalization (a way to move from expensing software to capitalizing it). Teams can’t seem to ever deliver a finished feature. The work in progress everywhere is quite large.