My clients all have too much work to do. So they ask the product or project leaders to write a business case for each effort. The clients claim this information helps them decide which work to do and not do. However, everyone knows each business case is at least partially fiction. That’s because the writer […]
A senior manager said, “We give our resources everything they could need: technology, tools, even some training. Why are they so slow?” I asked, “How many projects are they working on?” “Each resource has at least two projects so they stay productive and efficient.” These managers have created a resource efficiency culture, not a flow
Before the pandemic, Jenny, the VP of Engineering, insisted that the engineering staff needed to work in the Boston area. She expected that people would mostly work in the office, and they did. However, during the pandemic, Jenny changed her mind. She said that as long as teams had sufficient hours of overlap, she didn’t
Dan, a VP, knows he needs more people to get the work done. Suzanne, one of the directors, starts to hire and realizes she has several problems. First, their salary bands are too low—candidates want more money. In addition, the people want to collaborate more than the existing people seem to. She meets with Dan
The larger your product, the more likely you have components teams. I often see component teams because of the architecture of the product. In this first image, the Integrated System Program, the rest of the product uses the Platform of Common Services as components. Also, the teams find it tempting to think of the common
Continuing the series on dependencies… Maybe you don’t have the problem where the team creates internal dependencies with their process. And you don’t have to wait for someone outside the team to approve your work—an organizational process. But you do have a combination of platform/component teams and feature teams. I see this most often in
Does your organization have an enterprise architect or Chief Product Person? We create these positions to check that the teams don’t try to implement something “wrong.” However, a single person in this position creates bottlenecks and dependencies. (A committee might create even tighter bottlenecks.) Those dependencies slow the work. If a person delays the work,
Even when managers try to create cross-functional teams, the teams still have dependencies. Dependencies slow and make finishing the work more difficult. Too many teams have a built-in dependency creator—code review. When we take time to perform code review after we write the code (or the tests), we create dependencies between the people on the
Did you ever work on a project that dragged on and on, slipping a week every week? Back in the day, we called those projects “death marches.” I never saw anyone literally die, but I saw too many divorces, abuse of drugs and alcohol, and very dissatisfied and unhappy employees and customers. Waterfall projects can
Tim, a first-level manager, asked me, “Is it reasonable for someone to quit after just a week? With no notice?” “No. What happened?” “Sam, a new developer, started on Monday. He told me today, Friday, he’s not coming back.” “Did he say why?” “He had a whole raft of reasons. He had too many questions: