I wrote a thread a while back about UI vs Front End code and how we'd tried to separate into separate teams. Some of the advice you guys gave was not to be separated into teams. Unfortunately, to me this seems to be a difficult problem- it gets really, really hard to coordinate agile development across a large team. In fact, it's painful. We kept the separate teams, but not really. That is, we had separate stand ups, but since we were sharing a backlog, buglist, QA, and ended up working in the same areas of code, what it really became was a big mess of having to add a LOT of process in order to control things.

Now, I realize Agile does not mean "no process"- however, it seems we are going unnecessarily slow right now, and it all has to due with making sure such a large number of people is coordinated. I'm comparing our current team (2 Technical Architects, 6 programmers, 5 QA, 1 BA, 1 Project Manager) to the team I worked on at my previous company (3 programmers, 2 QA, 1 Project Manager), and the difference in efficiency is staggering.

At my previous company (working on the same product- but back end only), we didn't even have a bug list, believe it or not. All bug reporting was done verbally because QA and devs sat in the same area, and our level of defects was low enough that that was good enough to get it done. Now I realize that is not necessarily a good way to do things or that it should be my expectation in general, but I bring it up to illustrated just how informal things were (and the quality was VERY high- we released a lot of code very fast and never once had to release a hot fix to production outside of our normal release period, which was once every couple of sprints depending on functionality). We had very little in terms of documentation- most requirements gathering was done on the fly as we progressed through stories. Our users sat with us in planning meetings before the sprint, and whatever we didn't glean from that we found out with direct access during the sprint. Coordination between developers was simple- we always talked with one another, used similar techniques, and asked a lot of questions of each other any time we were trying something new. Our only design documentation was very high level- one or two pages describing the overall structure of the application and what its purpose was.

I contrast that with the current process- we have a massive bug list that does not get cleared each sprint (in the previous situation, we never carried bugs between sprints). Even though we are split into "teams", at the end of a sprint everyone is responsible for working all of the bugs in the bug list (so your big reward for getting done faster is to fix the other teams mistakes). We spend a lot more time coordinating all of the moving parts: a lot more documentation is created so that everyone understands what they are supposed to do- Additional meetings are had before and during the sprint to ensure everyone is on the same page for a story, and the TAs are responsible for creating design documentation that each team will follow for the sprint- they are kept so busy they don't get to write code (one of them actually does now- he splits his time 50/50 between writing code and his TA duties). The code itself is quite a mess, with different programmers using different approaches to solve the same problems and different values being pushed (for instance- I value small, simple methods that contain only a few logical statements, where another programmer values having all the logic easily accessible to his eye in big 200 line methods).

It's really frustrating, because at the end of a year we are much, MUCH less productive than I feel we should have been. In fact, I believe given our old team with half the developers, we could have accomplished about the same amount of functionality with a cleaner code base. Our product owner had only budgeted one year for the augmented team (the original team from the first company along with one of the TAs are the only permanent fixtures- the rest are contractors we only had for one year), so we have been counting the days until we get to the end of the road and can strip back to the smaller team. The current process is just so painful- so much time spend coordinating and having to wade through code written by people with different ideas about what good code looks like. It is SO frustrating to go into an area of code with no unit tests and have to fix bugs, which fixing bugs in the areas where there are unit tests is a cinch- of course, we spend more time fixing bugs in the areas without unit tests . . . go figure.

But I'm finding out now that the PO is looking to rehire the contractors for another year, and I'm about ready to scream. I am tired of working overtime on this project, investing blood sweat and tears while other people cannot be bothered to write unit tests and have coding practices I don't agree with. But it's not just that- even if we all were in agreement on how to write good code, coordinating this number of people is painful, without a large gain to show for it.

My manager (one of the TAs, and a good friend) is trying to figure out how to fix things for the next year. He wants to do it by getting stricter on standards- enforcing unit testing and function length, and anything else we can measure. I suppose we may have to do this, but I'm not convinced it's going to be that effective. It seems when you have to start taking draconian measures on people's code, its going to be hard to really motivate people to do better. Ultimately, you'd like for people to adopt common coding practices of their own volition through a good team spirit and a desire to work together, but when that doesn't happen I suppose you have to do what you have to do.

My suggestion was to split the teams more distinctly- put my original team from before back together and let us work on one of the remaining functional areas. The contractors can go work on a completely different functional area and we can deal with the consequences of the code looking different for different areas. At least we will spend a lot less time in coordination and my team can get back to doing what it does really well. Unfortunately, this suggestion has shot down because the PO really wants the next functional area out the door as quickly as possible, and that means putting every able body on it.

So all that to say- am I wrong about team size? Are there ways we can coordinate this number of people more effectively than we are? Should we be looking to replace the team members who are not functioning the way we want, or should we be putting more effort into getting everyone on the same page? Will draconian measures for enforcing code quality work, or will the just lead to bitterness and frustration?

I know I had it good before, and maybe trying to get back to that is a mistake or just unrealistic. I'm just embarrassed by how little we've produced in the time-frame we've had, especially given the number of hours I've put in on this project. I'm not going to keep putting in overtime, and I'm certainly not inspired to to it in an environment that feels like I'm swimming in molasses. I took this job because I was excited to keep working with a great team on a great product using Agile methodologies. But I feel like my team has been swallowed up in this monster of a team, every day we are throwing out more Agile and adding more process to make sure everything is coordinated. I don't think I'm ready to quit or anything, but it's painful enough that it's hard to get excited about the work. No way am I personally going to work as well when I feel that way.

Anyway, sorry for the long-winded post (typical for me, I know). I guess it really just boils down to what can we do to mitigate the pain of a bigger team? Any thoughts would be very appreciated.

Let me get this straight... you have an Agile team of 15 people? That seems about twice the size it ought to be, in my experience.


I would agree with your suggestion. Has the PO never heard the phrase "too many cooks in the kitchen"? They doesn't seem to understand that "putting every able body on it" doesn't necessarily mean "getting it out the door as quickly as possible." Indeed, it can even be counter-productive, and there's been plenty of research demonstrating this.

Can you show him your pre-merger team velocity, compared to the post-merger team velocity as a way to bolster your argument? What about other metrics? Bug counts? Or, can you demonstrate that smaller teams would have more capacity? That is, in a large team, everyone has roughly 4 hours of "useful work" per day, with the rest going to meetings, and dealing with large-team communication issues. In two small teams, where the effort directed towards the large-team communication issues goes away, everyone has a 5 hour capacity for "useful work". (These are the sort of questions that your sprint retrospective is supposed to look at.)


I don't think you're wrong, at all -- I'm willing to bet that big team you're currently on has already fractured into unspoken sub-teams. You might as well recognize it, and just split into smaller teams, and have a scrum of scrums to facilitate the inter-team communication. If, for example, you have 1 TA on each team, they'll talk to each other naturally. Ditto if you split those 5 QA across the two teams.


Heh. I'd say yes, and yes. If everyone isn't on the same page, how can they know what the expectations are? And if no-one knows what the expectations are, how can they know if they're meeting them? And how can you know if someone (consistently) isn't meeting them, and needs to be replaced?


Yes, and yes. I've been the draconion enforcer, before. It can lead to bitterness and frustration. It also means everyone knows what the standards and expectations are. I found that the people who got bitter and frustrated fell into two camps -- the people who sucked it up, and did it, and the people who left. The people who sucked it up eventually quit complaining, and agreed that the end result was better. The people who left? Good riddance.

Hoo boy I hear ya.

Our company is going through similar pains, although from the other direction. We're moving from waterfall development with large teams and trying to get agile methodology working for us on a new product.

It's interesting how I'm seeing the same complaints from you. You'd think they'd be different complaints.

My biggest one is the backlog of bugs that isn't getting cleared. I believe that this is a symptom that we're not doing Agile right. We shouldn't be just pushing bugs into the backlog, we should be fixing them. But the programmers are being pushed to work on the next feature and aren't given the task to Just Fix Bugs. And the testers are only getting the time to verify basic functionality on each new feature without being able to really test all the old features in-depth.

Another symptom that we're not doing Agile right: Not enough dependence on unit tests, automated tests, and static code analysis. Our coders just don't even know how to write unit tests, let alone getting into the mindset that the unit tests need to be incorporated from the beginning. Almost all our testing is manual. Our BVT isn't an end-to-end system yet, etc., etc...

I think what's happening is that we're writing a lot of very buggy code very fast. That's not agile, that's faux-agile, and it's going to bite us in the end.

Hah. Google it. It's a pretty common complaint.


Well, that depends. If the bug is in a new feature, then you're not just doing Agile wrong, you're doing software development wrong. You're intentionally ignoring errors. A feature isn't "done" if it doesn't work. In terms of Agile, no product owner should accept a feature as "done" if there are known bugs (unless, perhaps, it's a corner case that's so exceedingly tricky to resolve that they're okay with pushing it into a different sprint).

If the bug is in an old feature that the new feature depends on, then you should be fixing that bug, as part of the work to implement the new feature. Otherwise, your new feature can't be finished correctly.

If the bug is in an old feature that a new feature doesn't depend on, then it's up to the product owner to prioritize fixing the bug. In that case, just pushing the bug onto the backlog is the right thing to do.


Is there business value in doing all that? If no, then the product owner will never prioritize it high enough to get done. You might need to make the case that you've incurred a lot of technical debt, and suggest spending a single sprint clearing that up. Or, if there's too much to do in a single sprint, suggest dedicating every n-th sprint to working to clear that technical debt.

One way for a team to push back on implementing new features is to decrease their capacity in the sprint planning session. Since that capacity determines how much work you can take on in a sprint, you can use that extra time to work on fixing some of those bugs. Remember, a team's capacity is up to the team to decide, not the product owner. If the team says "we don't have the capacity to work on that," then there's nothing the product owner can do, other than asking "how can we reduce the number of hours you're spending on non-functional tasks?"


Static code analysis isn't an "agile" thing. You shouldn't depend on it, and don't have to use it, the way you do unit tests. However, it is an invaluable informational tool. It can, for example, give you the metrics to take to the product owner, and say "look at these numbers... last year, we were here, this year, we're here. Bug counts have increased in these areas correspondingly. We should spend some time refactoring, blah, blah, blah. The upside of letting us do that this sprint, is that implementing feature X would take less time, so we could also do feature Y, and, since it would eliminate an area of buggy code, we'd spend less time on patches after it's release, and could up our capacity to the point where we may be able to get feature Z in the bag, too."

Ship it if it sucks
call it 1.0

LOL

Funny how I wrote that about someone else...

Bingo. We're incurring the technical debt because we're being pushed to move on to the next feature, and we're declaring far too many bugs to be "edge cases" and thus safe to push to the next sprint, when they're really not edge cases at all.

The bug thing is particularly frustrating because my "team" (which consists of me and another developer) has consistently reduced the bugs assigned to us down to less than five every single sprint, and those left open are ALWAYS because of outside dependencies that make them unresolvable. But the other developers end up with a lot more bugs, and once we are finished with our list we end up working on theirs. I get that at the end of the day we are all in this together, but it's frustrating that we end up fixing their bugs while they are pulling in more stories.

And oh yeah- our velocity is twice what either of the other two pairs of developers are doing. But that is, of course, because all of the back end stories we work on are pointed too high- so I'm told anyway. Never mind that we are doing full TDD and the other teams are not- some are doing test last and others are just not bothering to unit test at all. I guess that's more evidence that our tasks are just to easy . . .

I just spoke with one of my old teammates from before who is paired with a guy who doesn't even try to write modular code or unit tests. It's driving him bonkers because they just approach software development so differently. And that guy is one of those who complains about QA being too tough on the software. For the life of me I'll never get that attitude. I WANT QA to find every bug there is- I'd rather fix this stuff now than when a user comes up against it . . .

I've made my pitch one more time to my boss (who agrees with me, btw, he just can't get the PO to agree)- to split the teams into completely different areas and work more or less independently. I don't think we are ever going to get our "teams" distinct enough when we are working on related stories in the same area of the program.

At least this thread is helping me feel like I'm not crazy . . . Thanks guys.

Sounds to me like your problem isn't your team size. It's your team members (or some of them). Agile only works if there's unit tests everywhere (otherwise you can't refactor, and if you can't refactor then you can't evolve the good design that you didn't do up-front). Software development in general (even before Agile) only works if code is modular. If one or more of your team isn't doing those things, you're sunk unless you can fix it...

If you hired a bricklayer and got one who didn't put mortar between his bricks because it's quicker, and whenever QA leant on one of his walls it fell over, and you told him about the mortar thing and he still didn't bother, then I think you'd very soon get a new bricklayer. Software without modularity, and particularly faux-Agile software without unit tests, is at least as likely to fall over as a brick wall without mortar.

As this is the Empeg BBS, I should say that the car-player itself was not developed using Agile, and at that time there were basically no unit tests in the code. We got away with that, I think, because the original team was unusually tight-knit and unusually on-the-same-page about design and vision; as the team grew in the Rio/Sigmatel era and became less homogeneous, unit testing became essential. (It was JG who was our first great evangelist of unit tests, not me, but it was soon clear to everyone what a benefit they were.)

Peter

We have a rule: if the bug count (on P1 and P2 bugs) exceeds a certain, pre-defined, threshold, we down tools and work on bugs. This includes bugs-to-close. Dev are not allowed to get too far ahead of QA. Obviously, there's scope for triage. Some bugs get downgraded to P3, some get lifted into stories on their own. None of this happens without the agreement of the QA "champ" and the product manager. The threshold is tightened as we near release.

When we got a new release manager, he asked me how many bugs we had in the system. I said 4. He said: "4 bugs in the open stories? That's pretty good." I said: "No. 4 bugs total." We work hard to keep that count low. As I look at our team dashboard this morning, we have 2 bugs to fix, 1 to close.

On the other hand, we do have 5 failing automated test suites (with a total of just short of 1000 automated tests; we don't do a lot of manual testing). I should probably look at those this morning...

This is a fair assessment- but I content that size has something to do with getting away with it. That is, one of the things about Agile is that visibility is so high that you either get with the program or you ship out. However, there are just a ton of moving parts with the way things are currently structured and differences in development get chalked up to "difference in style" rather than "weakness". I actually told the project manager several months ago that I felt that developer in question had a "lack of skill" and that effectively ended our conversation on the subject.

I'll also admit, if I can get the people not writing unit test working on an area of code that I don't have to work on, at least the effects are isolated and when we start having quality issues we can consider a re-write for just that area. As it is we just have a general weakening of our code base and it tends to affect all of our development.

One problem is that the developers from my company are huge believers in unit tests and TDD, whereas the contractors are not. We have bent over backwards not to draw lines and make the dynamic "us vs them"- but it's really hard when we are consistently writing unit tests and they are not. Anyway, I've been beating this drum for months now and I think I pretty much annoy people at this point when I bring up unit tests- but what am I going to do?

My boss's answer to the issues we are having is to put measures in to enforce good unit testing (the lone exception to the "I don't write unit tests" rule on the consulting side is the TA who works for them- so he'll agree with the measures). I hope that helps. I just feel that if you've told people what to do for a year and they continue to not do it, FORCING them to do it isn't going to really fix things. I want team players who want to work together, not people who want to do it their way and ignore the team. I ALSO think that in smaller teams it would be easier to address this stuff at the individual level rather than making sweeping rules that can easily lead to a hostile environment.

You're right. The only way to fix this is to remind them that as long as they want to work for you, they do things they way you want them done. It's long past time to get rid of these contractors.

That's pretty impressive. We have... uh... 498 open issues, though that's spread across 5 different releases with ~9 different pieces of firmware and a couple of libraries in each release. (It may include hardware, too.)

Our company-wide bug database has ~2000 open issues at P1 or P2. That's for ~10 products across 3 divisions. Some of those have been in there so long that I think they should simply be closed.

My project is fortunate in that we're green-field development, which means we've been able to keep the bug count low. The project that we depend upon has ~20 bugs to fix. That's run by a different group, but we'll pitch in and help when we get close to releasing our stuff.

But, back to the original point: I suspect (based on my experience) that the ideal Agile team size is 4-5 devs with 2-3 QA. I also suspect that success is really governed by the quality of your team. The Agile process can't turn bad programmers into good programmers, but it does remove all of that waterfall crap so that good programmers can get on with being good programmers.

Heh. Never! A couple months ago, I fixed a bug that was introduced Feb. 8, 2000. Some parts of the system obviously aren't exercised frequently.

...If the programmers are writing unit tests and there's a lot of automated testing.

Imagine that practically all testing is manual and the programmers have been so pushed to work on new features that they've hardly been writing any unit tests at all.

Now imagine your team is 4 devs, 2 QA, and far too many managers. And our bug backlog keeps growing.

I work for a company that develops ASICs. Our teams usually consist of about 3 devs and about 20 QA. (Read "designers" and "digital verification" in this context.)

Of course, it's a lot harder to fix bugs after deployment with ASICs than it is with software.

The problem is, who is the judge of what makes a "good programmer"? There isn't an objective measure of what makes a good programmer and we end up in "religious" debates all the time over our ideas about software development. I obviously have my beliefs- but the PM doesn't know who to listen to, and our two TAs are divorced enough from the actual coding they don't always have a solid handle on what is causing issues.

The thing about waterfall is that a LOT of effort gets put into controlling weaknesses. In Agile, you have to be flexible to react to weaknesses and deal with them appropriately. Thus far we have reacted to every issue that has come up by putting more and more controls around the process, rather than expecting people to do better. Every day we approach waterfall, but without having put effort into a big upfront design (welcome to "Code Like Hell Programming").

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?

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."

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
b) this product is customer facing
c) the PO is different

She says the performance discrepancies are generally due to the fact that the existing team has product knowledge whereas the contractors do not.

Now, this probably comes off like she has an agenda. I believe that she really tries hard to be unbiased, and you have to admit, when we're sitting there saying all the contractor programmers are lacking (except for the TA), it sounds suspiciously like "we don't like them because they aren't from here". That isn't the truth though- 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.

One point- the team I'm talking about was from a bank that was failed by the FDIC (had nothing to do with our software- I promise!) and we were hired to basically re-create the same software we'd worked on before (we worked on the back end, the contractors worked on the front end- but of that team only the TA, PM and one QA remain- the rest of the contractors are all new). When I told our current PM that there was a reason the people from the old team were chosen, her immediate response "Because you guys had the most product knowledge", not because we were good at what we did (which my manager- at both locations- assured me was the reason)

The difficult part of all of this is that our TAs are not involved enough in the code to truly know the ill effects of all that's going on, while I am officially at equal rank with all of the other developers. I do have the ear of the TA on our end, and the PM respects me enough to ask my opinion (and try to do things the way I suggest). 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."

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.

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?

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.


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.


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.


Ah. You let them empower themselves to make changes.


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?"


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.

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.

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.



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

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).

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).


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.

One thing I'll add, as much as I've harped on it- I actually don't CARE if other people are doing TDD. What I do care about is that everyone writes software that has a low rate of defects and is easy to maintain. No matter how each individual gets there, that's all that really matters to me.

You have people writing design documents and other people implementing them. You have an idea of a finished product that it sounds like you've been working towards for over a year with no meaningful iteration on product. You have bugs that come up within an iteration and the people who worked on the story aren't stopping and fixing them. You have limited test coverage, so meaningful refactoring becomes hugely more difficult.

I'd also suspect that the business side has no real visibility into where you are in relation to their goals.

You're trying to do agile with a huge portion of your team still doing waterfall. Waterfall can work - but it can't coexist with agile on the same project.

My plan if I were in control of your organization:
Fire the existing contractors. Find a PM who can relate business requirements to developers, and technical requirements to businesspeople. Hire developers you trust to implement the product without an architect to tell them how to do it. Figure out what your MVP is. Slice that into stories, do those, and decide what's the next thing that would add the most value to the product.

Presumably you can't do all of that. If I were you, I'd work towards isolating myself in a group small enough to make meaningful progress without interference from everyone else. It's kind of opposite of my advice last time, but your team doesn't seem to be interested in drinking the water/kool-ade, and no amount of process will fix that.

Matthew

All of that is true- however, the business definitely has visibility into where we are. They aren't exactly pleased, though :: Even at that, we are getting close to a first release, assuming we can get a minor (read: critical) bug with our HTTP stack resolved.

I just had a long 5 hour conversation with the project manager. I know she probably comes off bad in this thread, but she really is trying hard and she listens to me. In fact, we kind of complained to one another about things beyond our control.

Anyway- she's pretty convinced that we need to split into smaller teams, and she agrees that what we've done thus far isn't really separate enough. Unfortunately, the PO has nixed the idea of separate teams working on separate areas of the product, so if we are going to make two teams work, we have to do it working on the same functional area.

I'm not sure this is possible, but I'd love some suggestions. We did the back end/front end thing before, and that might be the best way to split for the next release. I think that would lead to the least amount of toe-stepping as we are working on separate areas.

Sharing code across separate teams seems like separation in name only. If you can draw a line at the HTTP boundary with a back end api and a front end app, everyone should be happier. Only you know if that's vaguely feasible with your current architecture. Story acceptance on an API requires a slightly more technical PM and some education from the developers, but give you a very easily testable border and the ability to add mobile or other interfaces at a much lower cost.

Matthew

Technically, we could easily draw a line at the HTTP boundary. We have a very clean separation between client and server logic- the client contains NO business logic at all- it is all pure presentation. Even validation is handled purely server side (though originally we were going to replicate validation logic client side for usability purposes, some user-driven preferences actually ended up with us pushing that logic to server side only). Communication between the two uses a RESTful interface and data serialized as JSON. With the client being written in Silverlight, the client and server sides share interfaces that serve as a contract for serializing and serializing the JSON; however, these interfaces are data only and client side does have any access to methods on our entities (or any of the objects that operate on these entities).

All that to say- easily technically feasible to separate into a Silverlight and Backend team, but I just can't see this flying with QA. I don't think our QA folks are going to be comfortable talking directly to web services with JSON in order to test the backend team's stories. Right now the back end code is only tested going through the UI, and I can't see that changing. Of course, even as I say that my brain is scheming for a way to give them a tool that could auto generate data entry for all of our interfaces and allow them to bypass the UI... I can't help it, it's the twisted mad scientist in my head!

Anyway- I think we'd end up in a situation where none of the back end code is tested until the front end stories are done, and that really just pushes it all back into one big team. Which is not to say that there isn't value in separating the developers into sub-teams- at least then bugs would be clearly assignable (front end goes to team A, back end goes to team B). Also, due to the architecture as I described above, the only shared code between sub teams would be data-only interfaces, which would at least allow poor decisions by one sub team to have less effect on the other team. It's certainly a thought.

Use SpecFlow with bindings that talk to the REST API. You write the bindings; they write the BDD tests (using Gherkin syntax). SpecFlow generates NUnit (or MbUnit, or...) unit tests that you run on your CI server. You can also use SpecFlow with MSTest and the Silverlight Unit Testing framework to automatically test via the UI.

I've been interested in Specflow, but haven't gotten a chance to look at it (or BDD) in detail. I didn't think it was a QA tool, though. Could it be leveraged to help QA test web services without the UI?

Depends how amenable your QA people are. They'll have to write the BDD tests in a fairly rigid syntax, and you'll have to write the bindings, but we find that it works pretty well.

Because you're writing the bindings, you can turn the BDD "Given I am logged in; When I click Buy; Then my basket should contain 1 item" into whatever you want. I've been playing with testing against the controllers in ASP.NET MVC; you could make the bindings talk to your REST API instead. The project I'm working on tests against different tiers: we've got some that have bindings for testing against the database, some that test against an existing (end-to-end) COM API, and some that test against the viewmodel in the UI.