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.
Well, the argument is that before we didn't have to worry about how the software looked- we could just implement UIs however we wanted, and the customer was generally OK with it as long as it got the job done (Our UIs were nice, but the user really didn't give us any guidelines). On this project the customer wants to be in control of every detail of how the app looks and feels, so more coordination is required (we have comps and style guides, etc.). I still agree with you- but I also understand why she thinks what she does.
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.
The thing with the PO is I think the PO would be MUCH more comfortable with a waterfall approach. That is, she likes reading through specs in detail, approving them, and then getting exactly what she asked for (even if it's not what she wants). It's just how her brain works. The idea of Agile has really thrown her for a loop. The reason we are doing Agile is that at the old bank it worked so successfully for us- but at that time our PO was someone different who was the perfect candidate for Agile (I specifically remember a time when a requirement had gotten missed and didn't make it into production, and she shrugged and said "OK, let's create a new story card" and that was the end of the discussion. It was actually a fairly important feature, but she had faith it would get prioritized correctly because of the process, and it did).
Anyway- the problem with switching away from Agile now is that we simply haven't done BUFD, and we don't have time to do it. And quite honestly, I wouldn't stick around if we did. The whole reason I took this job was to work on a great Agile team. Waterfall is fine, but Agile (when it works) is just sooooo much better. There are plenty of options here in Atlanta that would put me in a better location for my family, so if this project doesn't offer me anything over those other jobs, it will be time to move on.
I'm still sticking around because once the project is done, the contractors go away and it's back to our original team and doing projects OUR way- we are the only permanent employees. We just thought it was going to be the end of this year and now it appears like we might have to wait another year
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.
Well shouldn't they be empowered? I mean who wants to step into development environment in which you are powerless to make changes? It's pretty much the developer mindset to want to do things YOUR way and bring your experience and skills to the table. That being said, part of being a team player is working those ideas into the existing infrastructure.
I've heard over and over again that you cannot force people to do TDD, and I get that (and I'm not talking about on this project- the TDD folks say that). It's not an easy shift in thinking. But if an organization is already doing it, I'd expect people to try and learn to fit in to the existing practices, especially with a lot of people around to give pointers and help you learn. And TDD isn't the only thing. I mean, jeeze, the last time I jumped onto an existing project I changed my bracing style to fit the existing coding style because I wanted to keep the code visually consistent (I realize that TDD != bracing style- but the point is, being a team player can mean significant or insignificant changes to how you develop software).
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.
Unfortunately, I've used up a lot of goodwill on the question of TDD
I've beat the drum loud enough that I think people are deaf on the subject now. I've explained time and time again why it's such a good practice, so now it's just "oh, he's going on about TDD again . . ."
Of course, I'm not the only person who feels this way, but I'm the most vocal.
But this kind of thing is why I want smaller teams. If you just put the team that is experienced with TDD together and let us write software on an isolated project, there's no doubt we're going to be faster and have better quality. And if you stick a non-TDD person on that team, they are either going to learn it or get frustrated and leave (or maybe even find a happy medium that everyone can live with).
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?
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.
The thing here is, if we could trust people to honestly assess this stuff I don't think we'd be having the problems we are. I think this would have to go back to the TAs and let them review the bugs and assign causes. Unfortunately, I don't think they have the time to do this.
Previous Topic
Index
