Is Scrum useful for developing a single programmer?

Question

I lead a team of six programmers, and we are currently implementing a number of flexible development methods. I am very interested in Scrum, however, it seems to suggest that there will be several developers in your project. Most of my projects are smaller, and they involve one developer. We run 3 or 4 of these projects in parrallel at any time.

From reading Schwaber, much of Scrum seems to come from self-organizing teams to achieve a difficult task. If you have one developer doing all the work, will Scrum bring more value?

Answer 1

Scrum may be more than you need as a single developer, but if you have a stake holder and a QA person, then Scrum can still be useful. Remember that they are separate from your team and must be at your racks in order to trade information with the team.

If you are truly alone, there are other flexible practices that may make more sense to you. For example, Kanban may be better suited. You do not have the overhead of iteration, flashback, sprint planning, etc. You just have a lag from which you get jobs. This is good for organizing your work, allows stockholders to adjust priorities, and works well for a single developer or small team where you can split your work without requiring synchronization between developers. Perhaps you have a product that has only small features that don't require a lot of architecture to support new features. Or many small projects that are independent for advertising firms, etc.

Answer 2

The only important advantage of Scrum that exists even if there is only one developer is not daily synchronization (meeting), but the restriction of restrictions on context switches. When working in a sprint, this single developer can focus on set stories in his (supposedly short) sprint, knowing that he will not be interrupted or will not insist on anything else before ending it.

Less context switching == less waste == more performance.

BTW - Kanban offers less overhead than Scrum, but it's easier to get around and get the developer to switch to context. This can be helpful, but it can also be a problem.

Answer 3

I think that the value you can get can come from battle or other nimble concepts.

For example, instead of a weird meeting, ask one developer to tell you why he made the decision about task y. You may or may not offer things (it depends on your background as a developer, I think), but the fact that the developer hears his own explanation can be useful for finding errors or dead-end reasoning.

As one professor of mine once commented a question out loud: "If you ask the universe to answer, it will give you one."

Answer 4

Although, as others have pointed out, the daily standup may be strange, but the value for an individual developer is that he accepts a process similar to a fight.

Temporary, potentially freed up, iterations and a stack lag can help an individual developer focus on actually doing something, rather than endlessly ratholing.