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.

This sounds very intriguing, and not just because of the immediate problem I'm trying to solve- but I won't go into that for the moment.

I guess the big question is, how does QA validate the binding code? The notion that they may not be testing what they think they are testing due to a bug in the binding code is pretty scary.

Other less important questions- when are these BDD scripts created? I could see QA doing this while devs are working on the feature, meaning that there is a lot less strain on QA near the end of the sprint. Are you using TDD and this testing is supplemental? I've never really understood if BDD is supposed to replace or supplement TDD. It sound supplemental to me (TDD is design and unit testing, while BDD tests broader scenarios). How much developer time is required for the bindings? I assume this would lessen over time as you'll have coded some reusable pieces (use is logged in as admin, etc).

Sorry for all the questions- but this idea has real promise and I'd like to know as much as I can before bringing it up to our project manager (I will probably download specflow this weekend and attempt to generate some scenerios avainst an existing resource).

There's a couple of things that work here:

1. Coverage -- if you've got enough tests checking enough scenarios, gaps in the tests will tend to be fairly obvious. This is backed up by a certain amount of exploratory testing. It's not perfect: we had a bug in our tests for a couple of iterations before we noticed. Fortunately, the bug was only in the tests; real-world usage wouldn't have triggered it. If it had been a real-world bug, I'm fairly confident that it would have been spotted sooner.

2. Technically proficient QA. Our QA guys are probably marginal at actually writing the bindings, but they're perfectly happy to review them.

3. Code reviews. We have a rule that nothing is allowed to be checked in without being reviewed. Obviously, it's actually more like a guideline, but we're pretty good at following this rule. Pairing supplements this for the trickier bits of code.



This is exactly how we do it. And the lack of strain on QA at the end of the sprint/iteration is awesome to behold.



It's supplemental. Define behavior in BDD. It fails. Write unit tests (TDD) for those missing features, make those pass, refactor. We've tended to slack on the unit tests, which I think is hurting us slightly.

Here's a cool slide deck: http://www.slideshare.net/drumwurzel/getting-comfortable-with-bdd

You will require more dev time, but that's balanced by having the whole automated testing thing, and also frees your QA guys to do more in-depth exploratory testing. It also means that your QA have more time to get involved earlier, which means that everyone's on the same page for what you're building.

Writing the BDD tests properly is a bit of an art, and takes a while to get comfortable. That said, you can be fairly productive with it quite quickly.

Awesome- thanks for the info. I tried out specflow writing a few scenarios for a feature that I worked on recently- I'm already a huge fan. And darn it if I didn't find a small defect (one of those- "It won't happen in production, but conceptually it's not quite right" kinds of things).

One problem that we've been having is that the PM's great value to this project is she has more business knowledge of what we are building than anyone else. This has led to a great strain on her time as she tries to make sure she verifies absolutely everything we do and that there are no gaps in dev/QA's understanding of business logic. Executable specs would be an enormous benefit to her (at least I think so) because it would be easy to review QA's understanding of the problem we are trying to solve- and do it without requiring a demo or calling a meeting.

I'll admit that I am slightly proud that our app is organized well enough to really take advantage of this- that is that our business logic all exists server side so it can be verified without requiring the client. Individual modules of our code base may be difficult to work with, but the overall structure is very well done (imo). I'm also thinking about how we can use this client side as well- we have absolutely no automated regression testing because we burned about a month and a half trying to get Telerik's Silverlight automated testing tools working with very little success. This would let us test from the viewmodel down- I'm not sure if we could actually hook into the actual views or not. Either way- there's definitely a lot of potential here, and I'm glad this came up. I don't know if it will get us to two teams (it may- this might allow us to have a bank end/front end separation), but if not there's potential to alleviate a lot of other strain on the project.

Ok, BDD excitement aside, let me return to the original problem (which is that I spend a lot of time dealing with poorly written code by people on the team not implementing good coding practices). Assuming (for the moment) we cannot change the team sizes, is there any other advice? I know a lot has been given already (and I am truly, truly grateful)- but some of it is a bit over my pay grade.

The only thing I know we can do is that we absolutly can create a list of "Thou Shall" and "Thou Shall Not" coding rules. In fact, this is what my manager wants to do. IF we move foward with this, is there any advice on some good things to put on this list? My thinking thus far is

-Developers must write test for any piece of code that a) does not talk directly to external resources b) is in the view (xaml or code behind) c) is otherwise excused by a TA

-Developers will not check in code without corresponding unit tests unless excused by a TA

-Developers will not check in methods with more that 5 (totally pulling that number out of my nether region- is there a good number here?) control statements (If statements- loop statements, etc.) unless excused by a TA


That last one feels terrible, but how else can I quantify "Write modular code"? I actually don't mind long methods, as long as they don't have many control statements (that is, a 200 line method containing purely assignment statements doesn't bother me in the slightest).

Am I totally on the wrong track here? Is there another way to force developers who are writing difficult to maintian code into writing better code? Also, this doesn't really address the concept of complicated classes that are doing too much. I don't really have an answer for how to curb that, espcially since our ViewModel design is pretty messy, so implementations tend to be messy. Can't really fault people for that. Beyond that, we have some classes that contain tons of procedural code that have gotten pretty big, but I don't find them to be difficult to work in. If a class is just a container of procedural code, it's not that hard to figure out. It's when a class is actually an object with state that getting big makes it difficult to understand. So it's difficult to say "Classes must be less that xyz size". I suppose you could say "Classes that maintian state and are not ViewModels must be less than 300 lines of code" or something like that.

Finally, how do you enforce any of this? I doubt we can dock pay- but what if a developer continues to not write unit tests or big messy methods?

Add cyclic complexity as one of your continuous integration steps. If it's above a certain threshold, fail the build.

It is terrible. I suspect what you're trying to express is closer to minimizing nesting depth, rather than minimizing control statements. Having a number of control statements in a row isn't hard to follow, it's when the control statements are within control statements, within control statements.

But what Roger said... use cyclomatic complexity as your measure. I wouldn't suggest failing a build because the number is "too high", though, since you may have code that requires that complexity for some reason. It (along with all metrics) is more of a guideline, really, offering insight into areas of code that may be more prone to bugs, or are in need of refactoring.

That, and test coverage, are the two most useful metrics I've used.

I'm far from a professional developer, but maybe instead of raw numbers you could look at an increase in numbers. And then assign "blame" for those numbers. And then put up a leaderboard.

Maybe turning it into a little competition would help. I'm thinking more of bragging rights, though, than Cadillacs and steak knives.

That's actually the best use for metrics -- looking at changes over time. Raw numbers are meaningless without the context. Is a complexity of 10 good or bad? Well, it's good, if the rest of your software has complexity numbers in the 50s. It might be bad, if the rest of your software has complexity numbers in the low single digits. It might be good, if it's encapsulating a complex piece of business logic in a minimally atomic piece of code. It's worth noting if it doubled from the last time you collected metrics.

It's also a good way of collecting data on under-performing team-mates. Isolate change sets, note the complexity of the functions being touched, pre- and post-edit. Did it go up? By a lot? Are they consistently writing code with complexity metrics significantly higher than the project average, even taking into account those cases where the complexity is a necessity? Does the high-complexity code correspond to where you're finding all the bugs? It probably will (based on existing research), but if the bugs are in low-complexity code, that's a darn good indicator that someone is doing a sloppy job of testing.

Compare the numbers of people following the practice of TDD and writing short, modular methods, with those who aren't. All of a sudden, there's hard data to back up assertions that TDD and short, modular methods are a cornerstone of writing quality software, and it's no longer a subjective argument.

Yes- nested control statements are what I meant. I looked at some tools this weekend for evaluating cyclomatic complexity and that seems a good way to go.

I definitely like the idea of tracking trends rather than hard targets. This seems a lot more empowering than a "Thou Shall Not" list. Really good advice guys.

Also, I talked in depth with our two TAs about splitting into client and server teams and using specflow to help QA verify the back end teams work. They are both VERY positive about the idea and I think are going to push for it. Also, I introduced our two best QA to specflow and they are pretty excited at the concept.

My manager (the TA on our side) says he wishes he was involved in such a productive forum as this one. Thanks for all of the insight guys!

On a darker note, we just had to push back our release date, and the reason had nothing to do with anything in this thread. Our PO is NOT happy, but it's all above my pay grade. For inquiring minds, it appears like our best solution is to port the entire client to WPF, and I'm fronting the effort for the moment. It will be a fun Christmas this year, no doubt!

Next thing you know, he'll be wanting an empeg of his own.

I was really happy with the scrum process at SOE during the development of DC. One of the requirements we had was that there had to be an "in testing" column on our scrum boards. Any task that had a testable piece would then be moved into the testing column and sent to QA. A QA rep was then the only person who could move that scrum card out of testing and put it in finished. If the found a bug, it was addressed and fixed with the initial task. During early development, this worked decently to catch a number of bugs before engineers moved on to a new sprint.