Best development methodology for a team of 6 - 10 looking to grow by 50% eventually

Question

From our current experience we're leaning towards a kind of lean methodology. We are starting to introduce a Product Owner role and we also are forming some QA roles. I'm worried that stratifying the roles like this will result in high visibility but low velocity. I think we'd rather have high velocity at the expense of visibility (we're a small shop visibility is pretty easy).

I'm wondering if instead of handing out horizontally sliced roles if there is a solid framework for handling vertically sliced roles. I'm wondering if that's the crux of XP.

Any thoughts on if I'm off track or any suggestions?

Answer 1

Looks like you should hire some testers and let your developers develop.

Answer 2

I would say for your sort of team, Scrum would probably work well.

I've had good experience with Scrum, particularly with team sizes like you speak of (6-10). (That said, 10 persons is on the large size for Scrum, and your growth of 50% might take you to a bit of a large size for Scrum, but it really depends on your internal dynamics.)

Scrum is all about both velocity AND visibility, and in my experience, I've found it to be easy to pick up, and that engineers like the level of responsibility it places upon them. It's important, too, to not be too strict about it; Scrum is more of a framework upon which to put your individual project; another reason why I like it, because it doesn't as much impose structure as suggest it firmly.

Answer 3

We're about your size, and have been using Scrum (which seems a little heavyweight for us, but it's a decent compromise between the dev side and the business side). If you have to use a specific process, I'd guess that XP will give you the best velocity, but you'd get much more out of concentrating on hiring well and using a prioritized list on a whiteboard to assign and keep track of work than learning and implementing a full agile methodology.

Answer 4

I always prefer to back off a project's creation of 'roles' in situations where you have a group of developers. The developers should group into junior / intermediate / senior, and then all be working from assigned issues in a bug tracking program.

If you assign roles to people statically, you'll have a tendancy for your application to be developed in silos. Each person will have their area of expertise, and all development and issue resolution for that code go to one person.

If instead you have everyone working in all areas, you get more knowledge transfer, and you're less at risk to the 'choke on a pita'/'hit by a bus' scenario. This works great for an Iterative Prototyping methodology. For a period of time a single person will be responsible for a single area of the application, but this should be for shorter terms, and force the developer to do a handoff when other people are assigned issues.

Let's face it, houses that do development often don't hire testers, and often require the developer to be a tester from time to time. Assigning a person the 'Testing' role is a sure way to get them to quit within 8 months. If they know it's just for a bit, and they'll get to do development again, then they'll try to push through at a good pace.

Answer 5

Lean is about increasing productivity by removing the obstructions to productivity. Flow bottlenecks in a work step of the development system get cleared by increasing the capacity of that step. You do that by shifting resources. If you've departmentalized your development system by fixed or specialized roles, you're going to have a hard time following through on dealing with flow bottlenecks.

It's amazing to me that the software development industry has allowed itself to believe that doing work and proving that the work is right is a job for two different people. This is itself a tremendously wasteful approach to development and is a good example of the things that we do that create productivity loss and the preconditions for bottlenecks.

You shouldn't be in-pursuit of perfect of pure generalists, but local generalization is one of the necessities of Lean productivity. If you want to achieve it, you might not want to start at role definitions, but rather look into the skills you need on your team and the skills that you have access to, and shape your process to strengthen the weaknesses. Just having the same old departmentalization of developers and testers is nothing more than the same old over-specialization that leads us to the waterfall conclusion.

Team size don't matter as much as Designing the Work, and doing so to support the reduction of the amount of work that is waiting between work steps. Chose a team size that doesn't itself create more lost productivity, and change it when it needs to be changed and can be changed for the better. The purpose of the team is to get work done. The conditions of the work will change constantly. Don't lock your time size or structure into an orthodoxy that you can't change when it's time to change.

Set all the preconceptions of methodological orthodoxy aside and focus on principles and values. This is what Lean development is, and it will make a number of the considerations that are common of Scrum and XP simply seem unnecessary.