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
I discussed the origins of the agile approaches in Part 5. In this post, I’ll discuss how you can create an agile approach that fits your context. Why should you create your own agile approach? Because your context is unique to you, your team, project, product, and culture. You deserve an agile approach that helps
Which levers does your team need to manage risk in your project? Do you need to cancel the project if you can’t finish a phase? You might not have the time. You might not have the ability to do this project. That’s the point of Serial lifecycles in Part 1. Maybe you need feedback from