O’ Mice An’ Men -- Rescuing a Project Gang Agley
Please log in to watch this conference skillscast.
You might have noticed that the world is suffering a pandemic at the moment, and it might have disrupted your software development plans. At least you’ve got a good excuse, though I’ve heard rumors of managers being sacked for not foreseeing the pandemic and including it in their schedules. I’ve not heard that sacking the managers has either made the pandemic go away, or rescued a software development schedule. I’ll leave that first problem to the epidemiologists and virologists, but when circumstances make a laughingstock of your schedule, what can you do? I can’t tell you how to do the impossible, but I can help you make the best of the situation. To do that, we’ll use that much maligned and oft misused tool, estimation. Come with me and we’ll explore ways to use your estimates to guide your response to unforeseen disruptions–meeting near term needs to the extent possible, and future proofing your longer term plans.
Q&A
Question: How do you deal with leaders who want proxy measures to make them feel comfortable that the team is busy?
Answer: Those leaders need to consider which is more important, busyness or the business. The interpersonal stuff can, of course, be tricky. The last chapter in my book is about that. It's the most important stuff in the book, to my mind. I wrote the book because I hated to see people beating each other up over estimates.
People who want to see full utilization tend to be middle managers rather than senior level. They're just doing what they were told was right and important for a manager. It's really more of a foreman approach than a management approach. Helping them learn and grow can be tricky.
Budget is fine. 100% utilization is madness.
Q. What do you call a highway with 100% utilization?
A. A parking lot.
You need slack to have flow. Progress comes from flow.
Question: Anyway my real point to my question was that those “leaders” are likely seen as leaders in name only. How much hope is there to actually turn such a situation around? How often do you see a significant shift through “helping them learn and grow” and those people (re)-gaining true respect before the productive team members start leaving (or get so disillusioned by life that they decide to become middle managers themselves)?
Answer: Improving such a situation is a job in itself. You need to start with what are the other person's needs? That can be hard to determine, especially if they have positional power over you. Think about your own goals. If you can't improve things, do you want to stick around? I generally feel it's worth giving it my best shot before leaving. YMMV
Thinking about your own goals is to decide how much you want to put into the situation. To improve the situation, you need to consider your own needs, the other person's needs, and the needs of the context. It's a dynamic balance.
Question: How would you deal with organisations which have a fixed price quote financial model, but rely on agile teams for delivery?
Answer: The fixed-price quote model doesn't really change when using Agile delivery. Estimate the job based on the historical data you have. Then use Agile delivery mechanisms to keep the project running smoothly, and see the progress toward that goal line.
Question: People always estimate for an iteration or more. Then validate or judge the velocity of the team. I feel measuring velocity depends on the nature of work, complexity, skill set, experience, etc. What is the best way to guess the velocity, I am sure, it’s not accurate but at least give some idea to the delivery manager?
Answer: My favorite tool is the burn-up chart. It lets you visualize the progress, and the changes in velocity, in ways that numbers tend to obscure. Mike Cohn's book gave people the impression that everything should be broken down to the story level up front, but
- that's too much work
- that locks in the design when you know the least
- and a number of other difficulties.
If you were asking how to guess velocity before the project started, I don't think you necessarily have to do that. Start working, and see what is the capacity of the team. I talked about this in http://blog.gdinwiddie.com/2011/05/25/avoiding-iteration-zero/
YOU MAY ALSO LIKE:
O’ Mice An’ Men -- Rescuing a Project Gang Agley
George Dinwiddie
George is a software development consultant and coach with over thirty years of experience creating software ranging from small embedded systems to corporate enterprise systems.