Scrum for a single programmer?

I would suggest trying Kanban, and starting with the basics: visualization and limiting work-in-progress (WIP).

Even if you discontinue it later, you'll get more agile in the process. And while Kanban is good for "normal" software development, Kanban + a flow-based process (as opposed to iterations) outshines other process tools when you have a situation with both developing new features and maintenance.

I second the recommendation of David Anderson's Kanban book, and you can also take a look at my slides from a local meetup on why and how to get started with simple Kanban, or crisp.se/kanban for a short intro.

For your context I have a few thoughts:

• visibility is key, so rather use a physical whiteboard than a digital tool if you can't show it on a (big) screen permanently (if you're co-located)
• start with your current process
• start with your sphere of influence only, including upstream and downstrean hand-off phases (becoming queue for you, e.g., designed features ready for dev, or queue from you, e.g., finished features, ready for sales)
• if your colleagues are interested in expanding the visualizing upstream or downstream, all the better. Maybe you'll end up visualizing the whole value stream (or network) for your company, i.e., how value flows from concept to cash
• minimize multitasking (!) by limiting WIP. If the flow of work is visible to your colleagues, they should understand why, and easily see what's on your plate
• maybe it'll be useful to separate work into 3 or 4 work types (classes of service), which have different demands upon them: f.ex. bugs, critical issues, work w/hard deadlines, work without deadlines
• observe how your work flows, e.g., if you get bottlenecks somewhere, or work are blocked or you are "starved" for work in somewhat predictable patterns. This is easier for the long term if you use a digital tool, ref some of my last slides.
• improve the flow of work step by step

If you want to try something right now, today, while you make your decision, I'd recommend trying a personal kanban on the wall or window or cupboard beside you, like I did last week...

Unless you have the following in place

• Means to organize and prioritize the the incoming requirements.

• To estimate accurately the effort that will be taken so that you'll know what you can commit in an iteration

• Iterations and Continuous Improvement - The concept of iterations in which one is continually inspecting and adapting is invaluable. This practice encourages experimentation and it builds in continued learning. Scrum in Church, page 4

• Well, you cannot do a daily scrum meeting, but at least you can remind yourself of the task that you'll commit today. Daily scrum meeting is used so that teams can get in sync with one another on what they are doing.

• Reflection after a sprint - in scrum it's called Sprint Retrospective, at the end of each iteration, you can reflect on what happen after the iteration, and think of what went wrong and how you can improve it, what are the best practice to keep them doing

I would suggest that you take a minimalist approach, and by continuous improvement, you can have a scrum that fits well to your needs.

Scrum is not scrum if you cannot fit it to your needs and adapt to your current situation.

A lot of these answers are missing an important point.

A scrum team doesn't need to consist purely out of programmers.

One of your colleagues does 'design' / 'development' and one does 'sales'.

Perhaps your 'sales' colleague can be a product owner (proxy). What are the customer's expectations?

The design and development of your other colleague really sound like scrum team disciplines to me. Scrum development is not phased but vertical (iron out requirements, design and implement in one sprint).

You could do the scrum process with the three of you.

What does it take to get 'this' done? Scrum's sprint planning meetings zoom in on the question what 'this' is. What does the product owner expect to see for it to be considered done?

During a sprint planning meeting you can give your other colleagues context on why 'internationalize and localize the product' might be technically difficult to implement.

Tons of reasons to use scrum imho.

I did try this when I was working alone at one point. The things that worked well were:

1. Having all of the work-items on a whiteboard. I could very quickly see what outstanding work there was; where dependencies and blockages were. Also, a lot of people would stop by my board and read it - and we'd have a chat about it. I think it helped them understand what "the geek" was doing all day ;-)
2. The burn-down chart was also great. I just used Excel for this. It allowed me to get better at making estimates in that environment. It gave me a great overview of where I was heading with the iteration. My manager, who wasn't a technical person, also loved this as she could see all of the different things involved in a feature, and where they were at.
3. Daily stand ups. Well as best I could. Each morning, I updated all of the work-items and the burn-down chart and made a note of all impediments that needed to be resolved.
4. Automated testing and continuous integration (MSTest/TFS), preferably TDD, will help any development team, using any methodology - but worth mentioning here.
5. Short iterations (1 week) really helped me to focus on delivering something.
6. Maintaining a backlog was great as when I was given new work I was able to place it in the context of all of the other work and get the product owner to re-prioritise.

What didn't work was:

1. Working by yourself, you never get that boost from collaborating with like-minded people; or that sense of competition and focus which comes from a team with really great morale and culture. There's no other brains to pick when you get stuck, so blockages like that can't be eliminated by a scrum master in the daily stand up.
2. There's no scrum master - so there's nobody to stop interruptions. I had a lot of trouble with people constantly asking questions about other things and breaking my flow. Under a good scrum master, stuff like that gets intercepted and you can get on. I never wanted to be rude to people (maybe I'm soft) so it was problem. Also, without a scrum master you can wander off the process easily.

It was an interesting exercise, but I stopped doing it after a bit. I think the benefits of Scrum should be seen in contrast to traditional waterfall teams. But both are kind of moot when you're on your own. There's no communication, or collaboration issues - you just plough through the work that is set and then you're done.

I think everyone should keep a back-log, and do TDD though.

After reading all the other answers here, I think the simple pragmatic answer is:

Use processes or techniques or methods that are in use to LEARN something that will help you do your job better.

Now this might mean to prioritise your tasks - every day - religiously.

It might mean to work out the backlog.

It might mean to report progress - to your boss (even if he does not care... doing it is a good thing to mentally allow YOU to take stock of where you are).

You might use all sorts of methods or techniques because they ultimately let you work better, which = sleeping better at night.

Do stuff that works (for you, in your current circumstances), discard stuff that that does not.

I've read some blog about this and I think it can help you with your question.

First part: http://www.21apps.com/agile/doing-agile-in-a-team-of-one/

Second part: http://www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/

You might find some more info on this blog.

I am in no way connected; just something I had in my favorites. Hope it may help you.

Elements of Agile/Scrum/Kanban that I think make sense in a single developer world:

1. Have a board on which you organize your user stories/active-backlog-items, on index cards, like kanban.

2. Get buy-in from the non-developers on the value of these principles:

   • Give me time to work without changing my priorities on me or micromanaging (the point of sprints). Give me time and I'll try to figure out beforehand exactly how much I can do, and I'll do my best to do that much.

   • If I need something (I get blocked), and I come to you, and you can't sort it for me, then the sprint might have to be cancelled abnormally. (That just means we need a new plan.)

   • Nobody changes anything in the middle of the sprint. Or, if we do, we just cancel the sprint, and we create a new one. if this happens a lot, productivity drops.

   • communication between people who are stake-holders can happen at regular daily stand-up meetings, that communicate most of the same things as a regular scrum would be, including your developer accomplishments for the day. Essentially, you can report things that took longer than you thought, or went well, and any adjustments you are making to your implementation plans. (I found four new bugs and logged them, I think they're more important than this optional feature, and so I'm thinking I'll spend the time and fix them and push out this optional feature.)

I've done a lot of work as a single developer, and I can say for sure, that trust between the single developer and his non-developer supervisors/bosses, and good communication are the keys, not a methodology. But you can always be more effective, if you follow good principles.

While I will not say anything for or against 1-man Srum, I will say that a 1-man Kanban pull system works very well. Kanban combined with automated Unit-Testing has made me much more productive and "documented". Although neither are reallyh methodologies, but more tools (and very different ones at that), both force me to break down large solo projects into bite-size pieces, as well giving me a sort of ritual to encourage me to get more things done each day. There is nothing quite as satisfying as clicking "run all tests" and seeing each item go green... nothing except taking a card from the "In Progress" column on my Kanban board to "In Testing" (or off the board entirely).

I think the real issue with working solo, is that you have pick and choose from multiple methodolgies, that are really meant for groups of developers, and tailor it to best fit you. The end goal is really just to keep you accountable, productive, and happy. Who knows how to do that better than yourself (with a bit pulled from here and a bit from there).

Yes. And keep in mind that the Scrum doesn't have to involve fancy tools, it can just be a simple 15 minute stand-up meeting where everyone talks about what they're working on. The advantage of Scrum is that everyone knows what's going on, and that makes it easier to solve problems before they arise, and anticipate problems down the road.

You can use some practices used in Scrum like product backlog, prioritization, relative estimation, incremental delivery but using whole Scrum as a process for managing product development by a team of self organized cross functional members isn't probably way to go for one man show.

The question is if you are able to break your work items to small pieces which can be delivered incrementally? If not using most of practices doesn't make sense. Also Scrum is about high cooperation with Product owner / customer. It should not be like: "Here you have an assignment and get back once it is done".