I'm billed as the "Windows Expert" in my very small company, which consists of myself, a mechanical engineer working in a sales and training role, and the company's president, working in a design, development, and support role.

My role is equally as general, but primarily I design and implement whatever programming on our product needs to get done in order for our stuff to run on whichever versions of Windows are current.

I just finished watching a high-level overview of the Scrum paradigm, given in a webcast. My question is: Is it worth my time to learn more about this approach to product development, given that my development work items are usually given at a very high level, such as "internationalize and localize the product".

If it is, how would you suggest adapting Scrum for the use of just one programmer? What tools, cloud-based or otherwise, would be useful to that end?

If it is not, what approach would you suggest for a single programmer to organize his efforts from day to day? (Perhaps the question reduces to that simple question.)

  • Care to share the podcast url? ;o) May 2, 2011 at 17:55
  • Huh? What podcast? May 2, 2011 at 21:37
  • I think he means the webcast ;)
    – poke
    May 2, 2011 at 22:45
  • OH; sorry, no, I can't. It was one of those one-offs offered by Go To Meeting, as a by-invitation event. May 3, 2011 at 0:59
  • Such irony. Closed as "too broad" after 3 1/2 years, where the last activity was only slightly less old than that. And it's still getting upvoted! Oct 27, 2015 at 17:58

11 Answers 11


Learn Scrum: yes. If only to learn about it to add to your general skill set. (but a flavor of it "Scrum-ban" is probably what you are looking for...)

Scrum is a nice framework, but a core tenet is "Iterations (Sprints) shall be fixed duration" I've never seen this work in very small teams that are more interrupt driven than not. If you can truly sign up for and commit to work in a fixed time box (1 week?) then Scrum is a cool framework. If you can't... then Scrum is nice to learn about because it has some good concepts that translate well to other things... like....

Backlog - Scrum or not, keep a prioritized list of things you need to do. I like Excel (or Google Doc Spreadsheet...) You might like something else. I'd keep a very small tool if you are a very small team. (Spreadsheet >> Word processor because you can sort easily.)

Separation of planning and committing - Plan in an abstract notation (points) and be consistent (8pts is about 2x a 4pt story and 4x a 2 point story) When time to "do the work" re-look at the problem and sketch it out in hours. Don't change the points.

Commitment - be visible to others when you commit, and deliver on your commitments

Retrospective - after you have delivered, reflect on what could have been done better.

etc etc.

Scrum is easy enough to understand that it might be a good starting point. If you like it, I'd consider using the "Scrum-ban" variant - http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban. Nothing else strikes me as "so well documented" with a reasonably active community to support it.

I'd love to also recommended Alistair Cockburn's Crystal methodologies (http://alistair.cockburn.us/Crystal+methodologies+main+foyer and http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology-Small/dp/0201699478/ref=ntt_at_ep_dpt_3), but it involves way more reading and digging.

Things like XP provide more details on specific practices, so I'd also say read the book: http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s=books&ie=UTF8&qid=1304359834&sr=1-1

Final reading advice: So long as you agree to the Agile manifesto, and follow the principles: http://agilemanifesto.org/principles.html you should be in decent shape.

Personal recommendation: Adopt TDD (non-negotiable, IMHO) Maintain a backlog (as per Scrum) Always keep it sized and sorted on priority Decompose things "too big to do between interruptions" int smaller chunks Have someone else set/review priority (no two items get the same priority. ever.) Make your build environment able to build/test/deploy (to lab env) in 5-10min Show your customers (internal and external) the results of finishing a story Story isn't done till your customer agrees. Pull Stories from the top of the pile and work on them as you complete the current story Don't keep more than 2 things open at any one time. Finish one distraction before starting another. Take pride in your work and once a month show the team/company all the products/features you have completed.

hope this helps

  • It helps, but what do you mean by "stories"? May 2, 2011 at 21:35
  • Sorry, a "story" is a "User Story" or a description in enough detail to describe what a customer wants to achieve (a collection of requirements in a sense). Generally these are written in the form of "As a <<user role>> I want <<feature>> to achieve <<business goal>>" Wikipedia has a good summary : en.wikipedia.org/wiki/User_story
    – Al Biglan
    May 3, 2011 at 2:39
  • Nice answer. Can you recommend any other resources on Scrum-ban?
    – bentsai
    May 11, 2011 at 18:01
  • Nothing beyond a google search for background info. I liked this: infoq.com/articles/hiranabe-lean-agile-kanban and this: leansoftwareengineering.com/ksse/scrum-ban In general "try it out and iterate improvements! :-)
    – Al Biglan
    May 12, 2011 at 3:44

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".

  • 1
    I suppose that one way to look at it is whether there is a methodology or paradigm which a single programmer could use to hold himself accountable to himself and to the high-level goals, while leaving behind a trail of documentation about what was done and what is left to do. Years ago my boss and I attempted this with a massive MS Project chart, but then ended up not using it at all. Apr 27, 2011 at 23:24
  • 2
    Methodologies for small project programmers.stackexchange.com/questions/65127/…
    – DisEngaged
    Apr 28, 2011 at 1:54
  • No no. One programmer. Big project. Apr 28, 2011 at 15:40
  • To answer your question, Ladislav, yes, I'm capable and trained in top-down and object-oriented approaches to problem solving, so sorting my work into smaller deliverables is what I'm thinking of. I may also be involved next year in managing a few interns remotely. Skype makes a "stand-up" meeting possible, of course. Apr 28, 2011 at 18:16
  • @Rob: My opinion is that Scrum doesn't work when team is not on the same site - Scrum is not doing stand-ups. Scrum is more about continuous cooperation and communication. Apr 28, 2011 at 18:20

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).


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.

  • +1: "I think everyone should keep a back-log and do TDD" - Agree 100%. Scrum without TDD just eventually devolves back into waterfall due to the bugs that crop up late in the sprint.
    – Brook
    May 31, 2011 at 15:38

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.


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.


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.

  • 5
    so you're telling Rob to have a 15-minute stand up meeting with himself ;-)
    – LRE
    Apr 28, 2011 at 3:53
  • 3
    The amount of people who get this wrong and think scrum is just about having short scrum meetings everyday astounds me...
    – Doug
    Apr 28, 2011 at 6:41
  • 1
    Hah! I use a stand-up desk for work, so, y'know, this isn't all that orthogonal... Apr 28, 2011 at 15:42
  • 1
    15-minute stand up => self check up? May 2, 2011 at 17:56
  • 1
    How I wish I had 125 of rep...
    – speeder
    May 2, 2011 at 18:26

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 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...


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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.