The PM should listen to the person/people they trust the most. Do they know you well? Do they know your track record as a high-performance team? Did they hire the contractors to change they way the company works?
The PM IS one of the contractors. She knows our track record as a high-performance team, however she has lots of reasons that our previous experience does not apply:
a) it's a larger team
Valid point. But if your velocity doesn't ramp back up, at some point, she really needs to step back and realize that the larger team sizes are hampering the ability to get work done.
b) this product is customer facing
That's a BS reason. Software is software. Unless you're writing it for your personal use, there's always a "customer" somewhere. Whether it's internal, or external to the company doesn't matter from a development practices perspective. The PO is supposed to be shielding the dev team from the customer, anyway, so if there's any impact at all on you guys because the product is customer facing, the PO isn't doing their job.
That's semi-BS. The main role of the PO is to maintain and prioritize the backlog. If the PO is causing the team's velocity to decrease (or preventing it from increasing), they're meddling far too much.
She says the performance discrepancies are generally due to the fact that the existing team has product knowledge whereas the contractors do not.
You can only use that reason for so long... after a year of development, they should have a sufficient command of the product (or at least the portion of the product that they're responsible for) that it's no longer valid.
I was very stoked to add more people to the team. The thing was, we were all set to do a fully TDD application and knock it out of the park, and they came in with different ideas. We said "OK" and tried to adjust to new ways of doing things, but mostly we just created a mess of an app.
Ah. You let them empower themselves to make changes.
But while both TAs agree with my assessment and the PM is willing to listen to me, it's hard to REALLY take disciplinary action. There's always a feeling of "well that's YOUR way, but that doesn't necessarily mean it's the ONLY way."
Hmm... sounds like it's time for Let's Make a Deal. "Well, you're right it's the way we've been successful in the past, and you're right it's not the only way to be successful. We've put our methods aside for the last year, and have been doing it a different way, and the TAs and I are in agreement that it doesn't feel like it's been as successful. Can we get the whole team trying our way for the next year as a comparison?"
I don't know how many times I've been asked "is TDD necessary for writing quality software?", to which I always reply "absolutely not, but it's one really good way of getting there". The problem is, if we aren't doing TDD, we need to be doing other things that give us the same benefits TDD gives us.
The next time someone asks, answer a different question. When they're asking if it's necessary, they're not really asking "is it necessary?" Chances are, they don't know what the benefits of TDD are, but they have the perceptions that a) testing is hard/boring, and b) hard things require a lot of effort. Tear away at those perceptions with your answer, and frame it in a way that shows value to the person asking the question.
At the very least, change your stock answer to "Well, my experience shows it's the most consistent and effective method, for the least amount of additional effort." Phrased this way, you recognize that there are other ways to do it (the no, it's not necessary part of your answer) but that this is the easiest way you've found. Suddenly the option not to do it seems less palatable, because the other options are harder. Give people two either/or options, one that you want them to pick, and one that they'll find less palatable. Most of the time, they'll pick the one you want them to do. (On a side note, this is a trick I've known about for a while, but have only really come to appreciate after having a child. This morning, after restraining my 1 1/2 year old daughter from chasing my wife around the house while she was getting ready for work, I gave her the choice of staying with me, or going back to lay down in her crib. Since she was currently mad at me, she picked her crib, settled down immediately
because going back to her crib was her choice, and I got to sleep for another hour.) By explicitly saying "no", they won't hear anything else... you've give them the option to not do TDD, and that's the option they'll take because they don't want to do the extra work involved.
If it's someone in management asking, you might expand that to "it's a simple practice that allows developers to catch bugs in their code while it's still in development (before the code even makes it to QA, never mind deployed to the customer). Since the number of QA cycles is decreased, the development process is cheaper and faster." Attach a cost benefit to it.
Track the bugs you're fixing, and do an analysis of where they're coming from; who's introducing them, and at what stage (i.e. implementation error, should have been caught by simple unit tests, API design problem, misunderstood requirements, etc). Then you can take that to your PM, and say, "look... we're spending 30% (or whatever) of our time fixing problems they're creating, because of X, Y, and Z. If they did A, B, and C the way we've been asking them to for the last year, most, if not all of these bugs could have been avoided, and we would have been able to ship earlier/add additional features/etc."
I will pass this idea along to my manager- I think this is definitely something we could implement. The question is, who goes through and assigns the reasons for the bugs?[/quote]
The answer to that probably depends on your team dynamics. If this is an analysis that you're doing on your own, then obviously you can do it. On our team (though we're not doing Agile), the person fixing the bug does that analysis. That would depend on everyone dropping their ego, and being honest. If that's too hard for people to do individually, you could take it to a sprint retrospective, and say "Hey, I tallied up the amount of time we've been spending on bugs, and it's pretty high. Let's go through the bugs for the last sprint, and see if we can figure out why there have been so many." At least then you get everyone in the discussion about why a bug cropped up, and why it wasn't caught before getting to QA. Make sure everyone knows it's not about blaming a person... you're looking at the process.
Previous Topic
Index
