Is there a minimum team size required to see a benefit from Agile?

Question

I work at a company that has repeatedly cut the sizes of its development team, to the point that previous 10-man teams are now down to one developer per product (and a couple of testers shared between 5 products). We used to be fairly process heavy, having been a spin off from a larger company, and inherited its multi-stage waterfall process.

It has come down from the executive team that we are not releasing software fast enough, and that this is likely the fault of the process (which may be a contributor, although the 90% loss of manpower probably didn't help). There has been a push for us to move to an Agile process to avoid spending time writing design documents, etc.

I guess I'm just curious as to whether a switch to Agile will help with single-person teams. It was my understanding that a lot of the benefits come from higher visibility and more communication between team members, but I know what I'm doing and so does my manager. I already do TDD since we have no one to test the product anyway.

TL;DR version: I guess what I'm really asking is, can you implement Agile with single-person 'teams', and do you see any benefits from it, or is it usually something that's more effective for larger teams?

Answer 1

Check out https://groups.google.com/forum/#!forum/solo-scrum

and https://stackoverflow.com/questions/829497/agile-methods-specifically-taylored-to-working-solo

Update:
The first link is to the Solo Scrum Google Group. The most obvious benefit talked about here is using time-boxed sprints to manage scope and determine project velocity--both very good things.

The second link is to a previous discussion on Stackoverflow, which might indicate this is a duplicate question, but I thought it would be more useful to link to it. It in turn links to http://c2.com/xp/ExtremeProgrammingForOne.html which has a lot of links and info about doing XP solo (sans pair programming).

Answer 2

one

the minimum team size is one

Agile is a collection of principles and practices, which you choose to tailor the work-flow. If you're a one-man show, you choose what works for you.

XP/TDD works beautifully for one-man teams. And you get to skip the potentially time-wasting practices of daily stand-up meetings and pair programming.

Answer 3

Your main problem is not "going agile", but documentation. This article on Agile/Lean documentation by Scott Ambler would probably be an interesting read for you and your coworkers.

Agile is not about not documenting. You still document, it's just that you choose what and how you are going to document in order to maximize value while minimizing the time spent on creating it. You still capture requirements, carry out design, document your implementation decisions, and have full tracability throughout the lifecycle as needed, but only to the extent that the project needs. Not capturing key project information and decisions is a sure way to have a project fail.

---

For a fun little bonus, here's my take on agile for individuals:

The agile methodologies are designed for teams. Scrum usually needs around 3-9 developers along with a Product Owner and Scrum Master (and the Product Owner and Scrum Master should not be the same person). Extreme Programming often calls for 4-7 people.

The reason is that a number of commonly used practices in the mainstream agile methodologies don't scale down to a single developer. A prime example of this is the emphasis on pair programming and code reviews in XP - you really can't do this with a solo developer.

A single developer can be agile, but it will have to be a tailored process. Most agile methods call for some combination of continuous integration, unit testing, test-driven development, refactoring, KISS and YAGNI principles, and so on. Many of these have become "best practices", even on more plan-driven methodologies. There's no reason why a solo developer can't take advantage of some of them, as long as they don't interfere with producing and delivering software.

Answer 4

If you want to limit documentation, I'd focus on that if this is holding you back. Documenation is just a piece of agile and it doesn't sound like there is anyone at your firm that is going to know how to implement it. This could delay your code release in the short-term because of training, buy-in, adjusting, etc. The powers that be will just toss it out and look for the next great panacea for production delays after a 90% layoff.

Answer 5

Coming from a one man team (though hopefully not for long).

I strive to acheive Agile for myself in a sense that I intend for their to be more developers than just myself for future projects. I write up a high level WBS, I create user stories, tasks under user stories, test cases, and keep good track of projects in a way that my manager can look at and understand. It can be a little cumbersome because I "just know" in my head where I am at but I take the time to do it anyway purely to stay diligent for the mythical future team that has been promised to me but hasn't occurred yet. I would like to think that I am trailblazing good processes for the people who will come after me.

Documentation I do in small amounts and that is mostly flow diagrams and use case diagrams but generally nothing low level unless there is something really complicated or important about it that I don't want to forget. I also do deployment diagrams for the benefit of future people when they have to throw up a new environment for "training" or the like.

I am teaching myself TDD slowly but I haven't perfected it yet, it is an extremely tough to do in the pure sense for legacy applications without refactoring large and risky swaths of functionality. Complicated new functionality I still struggle with but I still aim for 100% coverage which is the end game of TDD after all. I may not take the best path to get there though.

It can definitely be done, but out of necessity mostly.

Answer 6

Why do Agile as a one man team when you can instead form a single team of five developers with a single product backlog for your five products. Try one or two week iterations and focusing on one product at a time and see how your productivity improves with five engineers working together as a cohesive self-organizing team. Depending on how frequently you plan to release you may need to adjust the length of the sprint. I'm guessing the business may not want to wait 10 weeks between updates to a product, in which case the 1 week sprint lengths may work better. You could work on two products in a single sprint but I would try my best to avoid this so you can focus on a single product goal and doing that productively and with quality.

IMO having a single person dedicated to a single product is likely an unwise approach when there are five developers and five projects total, irrespective of your chosen methodology.

Answer 7

Lots of agile practices pay off for teams > 0. Source control and frictionless development, for example, and such will always pay off no matter how small the team is.

Answer 8

This really depends on whether there's buy-in from the business side, or just a new thing for management to blame on development (which kind of sounds like the situation, based on the 90% reduction in team sizes). The higher visibility and more communication between team members doesn't just mean between developers. It's important for the business side to see where your time goes, and be setting the correct priorities.

We've seen a huge increase in trust between the business and IT sides of our company, because each team now has a Product Owner that takes part in the daily stand-ups, and they see where our time goes, and they're the ones making the decisions about what we work on next. Instead of the managers getting constantly bombarded with requests, and then development getting blamed when things slip through the cracks or there's not enough time in the day to get everything done, it's now the Product Owners who are responsible for setting the priorities, and making the decisions about what gets included in a sprint.

So, if there's a commitment from Product Owners who are going to be involved in the process, then yes, the Agile process can be very effective even for a team of one. But if this is just another way to make the developers into scapegoats, then Agile will fail for everyone.