In part 1, we talked about “what trauma points are”, where they come from, why you only see them in maintenance programming.
What to expect and what do about it?
So, trauma points. If your team is using this term/concept for estimating/pointing your Jira cards, then guess what? Your points don’t really mean anything, because your folks are telling you that this is a guess. They are going-in blind and hoping for the best, but experience is showing that “the best” is probably not what will happen. This pessimism might seem misplaced, but then again, it might also be completely appropriate. No way to know yet.
You need to listen for this, and plan accordingly. An example of WHAT NOT TO DO, is to belittle your folks or mock them for being cautious. (If that sounded a little terse, then you read me correctly.) Not everybody is built for maintenance programming, including some leaders. Some people can become acclimated to it, but not everyone. Experienced folks who respond with caution, are probably folks you should listen-to. It also helps if you know your team. Nonetheless, know how to “read a room”! Listen/look-for “tells”. Don’t shrug it off. If your timelines are squirrely, this is why. You won’t make good choices if you don’t/won’t acknowledge your actual conditions.
Maintenance programming projects will require programmers to work differently sometimes, and therefore, the project/process is also going to run differently sometimes. If you want consistency and predictability, you are on the wrong project now. You have to adapt, your people have to adapt, and the way you listen to them must adapt. For now, it matters more [how they say things] instead of what they say. When you see/hear it, adjust your processes a little, and encourage the programmers to adjust.
Getting back to predictable
So how do you get back to predictability when stuff is so unpredictable? There are two ways:
1) Halt progress until you gain a thorough understanding of everything. No programming, just research and learning. As long as it takes. At that point, these won’t really be estimates anymore, because the term “estimate” implies some margin of uncertainty. Once that is fixed, I guess you can switch to waterfall or something.
… If that sounds like an egregious waste of time, then I would agree with you. Nobody got time for that!
2) Eat the frog. Prioritize unpredictable work, so you can eliminate unknowns earlier. As the unpredictable tasks are resolved, (by definition) you will be left with simpler / more-predictable work. If this sounds like it requires a crystal-ball or something, then you are half correct. You can take some pretty good guesses at which kinds of work, tasks and parts of the system are the most traumatic.
The hard part of this strategy is watching all of that sand drain out of your hourglass. It is scary, and your developers will become demoralized as they drown in the bad-stuff. It takes guts, some uber-ninja developers and maybe even a little counseling/therapy. If any of this sounds like it will be easy, you better adjust your expectations.
Assigning the trauma
I know I already said this, but once more: this is not for everyone. Experience, intelligence, know-how are not the same as “grit” and grit is hard to measure. Try your folks at different challenge levels and figure out which ones have the mettle to handle it. Give the tough stuff to them, along with some support (because they will need it), and give the predictable (trauma-free) stuff to folks who just aren’t cut out for the bad stuff. Monitor and support the bad stuff, until it is resolved.
Aah, the pain of being an elitist 