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
Over the past couple of weeks, several potential clients have discussed problems they want to fix: What are the teams doing, at a detailed level? (The managers want to know when the teams will finish certain features in the short term.) How can they plan for six months at a time? (They want to understand
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
Here’s a scenario I see in all kinds of businesses. Your team has product-focused work. And, the team also has “fast” response-required, ad hoc work: Production support, when something breaks. You need to fix this right away. Provide technical support when people have questions. The team needs to answer these questions on a “timely” basis.
Several of my clients struggle with their deadlines. One of them, Brad, quoted Douglas Adams to me and frowned: “I love deadlines. I love the whooshing noise they make as they go by.” He thought agile approaches would work to “meet” and “enforce” deadlines. I asked him these questions: Do you think people don’t want
Many managers and teams talk about “average” durations for work. On average, how long does it take a team to finish a certain kind of work? However, average doesn’t quite explain why our work takes different durations. Instead of average, consider the word, “typical.” I’ve written about cycle time before. (It’s the time from when
I explained in Leadership Tip #8 that measuring happiness was a lost cause because happiness is a function of more than just work. I suggested we measure satisfaction. And I didn’t tell you how. (You didn’t mind-meld with me, did you?) Here’s how I’ve measured satisfaction with several teams. I start with the 5-point scale
What risks does your project have? Do you need feedback loops so you can: Cancel the project at any time (to manage schedule and cost risks. Assess technical risks so you can rework the architecture or design to manage feature set risks. Manage what you release to customers so you can manage defect, feature set,
The original signatories of the Manifesto for Agile Software Development wanted to solve these specific problems: How can we: Bring more adaptability to software development? Stop “plan the work and work the plan” thinking? Release something of value earlier? Especially since teams now had these levers, from the iterative and incremental approaches: Prototype something for