SoloScrum

From SPA Wiki

Solo Scrum Workshop Materials

At SPA 2009 I led a workshop on solo scrum. The abstract was as follows:

"Whether we're throwing together a side project, starting our own open source offering or doing smaller consulting projects, most of us spend at least some time working on projects where we are the only programmer.

XP engineering practices and Lean and Scrum methodologies have been successful at improving the performance of programming teams, but can we re-purpose elements of these approaches for the solo developer?"

Structure Started by introducing the premise: "Lean, agile, scrum, and XP engineering practices can add value to projects where you *are* the team" The question: "how?!" And the objectives: "Share/develop specific adaptions of agile for the developer working on their own techniques, practices, attitudes, technologies""

Sample user stories 1. As a full time developer I want to add some patches to my favorite OSS project in the evenings so I can improve the project and maybe get a better job! 2. As a solo consultant I want to build web apps for my non-technical clients 3. As a "work at home" contractor I want to manage the consulting I do for multiple clients 4. "Maverick" (only agile/xp dev in bigger team/company) 8 people in workshop, 5 identified with #1, 3 identified with #3.

We then brainstormed problems in those use cases. The problems listed were: 1. As a full time developer I want to add some patches to my favorite OSS project in the evenings so I can improve the project and maybe get a better job! - Time management - Too tired to work - Working long hours - No communication - No-one to delegate to - No support setting up CO, source control, wiki, etc - Issues with TDD - No pair leading to poorer code quality, poorer productivity and lack of motivation

3. As a "work at home" contractor I want to manage the consulting I do for multiple clients - COnflicts of interests (yours and theirs) - Prioritization - Context switching - Remote from customer (communication and isolation) - Separating work and home - Loss of immediacy (team) - Adaptability required (e.g. lack of network support)

From there, each person wrote down the problems they might be interested in investigating further on a large card. The problems that got that far were: - Time management - Noone to solve your problems - Prioritization - Have to provide own infrastructure - Nobody challenges my perspective & decisions when I work on my own - Context switching

People then voted using colored stickies on the problems they were most interested in investigating. The following three most popular problems were investigated: 1. Nobody challenges my perspectives and decisions when I'm on my own - 2 people 2. Time manageement - 2 people 3. Context Switching - 4 people

Proposed Solutions:

Problem: Nobody challenges perspectives Be publicly vocal - keep a blog, get involved in discussions around the topics as much as you can as may not want to be open, so may limit ability to chat about it with people you don't know What's Good? Attracts debate, but you might have to do other things to get people interested in what you are doing May just get bashing - not positive Alternatives are if you're working on something proprietary, get involved with OSS, communities. etc with networking and may get a partner from there.

Don't do it alone! Alternatives to that are reuse - design patterns to avoid common design traps. Also can look to see how others have done that - e.g. OSS projects - difficulty is aligning what you're doing with the problems

Problem: Context switching when working alone Some deep problems take a long time and require focus, but how balance that with the everyday stuff you need to knock out

Distinguish between deep and shallow projects - break deep projects into milestones - even if you don;t know what the next milestone will be. Allows time-slicing more easily of projects. Also a bit of breathing space so not a vicious circle.

Context spike - a spike of papers for each context - could be a virtual spike - e.g. a wiki page. Quickly refreshes your memory and might act as a useful task history. Bad because catching enough detail takes too long, and can take too long to catch up. Also how store, etc . . . (Things is a GTD style solution on a mac that allows you to do this kind of stuff - also iPhone synchronization) Maybe do all of the work in second life :-)

Pairing - Maybe out of bounds. Good stuff is constant feedback and questioning. They implicitly act as a context to some extent. But need proximity. Needn't be physical - could pair over IM, etc. But not sure who to pair with as nobody to share with

Alternatives, Online forums for sharing with people in same area, keep an engineering log book every day. Maybe physical cues like hats for different jobs!

On a deep problem, even phone call can lose 25 minutes. Like to do a wall planner chart of the day (even if just in head) where can put solid blocks of time to work on important deeper tasks. If working at home can switch everything off. Avoid other sources of interruption. But also need to firmly time box do don't over run. Sometimes have to stop at wrong point or need to overrun. Bad things: very difficult to do, lots of distractions, meals to prepare, having to do everything yourself

Time management

Never plan formally, maybe write a list or have it in your head, get distracted and forget.

Need to do a formal plan, know what all the tasks are. Nobody to manage the time plan, how do you make it almost automatic to do that kind of stuff. Auto update plan. Fail to plan, plan to fail. Really need to plan. IBM rational have jazz platform - "team concert" Trac/mylyn

Other technique - time boxing for time management. Take stock. Is it complete enough. Are the priority tasks finished? Can you deliver acceptably to the client? Think should have completed task. If nowhere near it, maybe need some help. Maybe not time-boxed, because if don't deliver, don't get paid, then need outside help. Cheaper than failing to deliver. Also, if working on lots of stuff, should branch more in source control.

Also Suggested: Conference Pairing - pair with people at conferences - doesn't help with projects that may be proprietary, but *does* help with skill development to become a better programmer. Get networking - One of biggest benefits of team is a ready built network. Get to know great devs you can bounce problems off over IM. Planning - Time management and planning is key. Also starting to play with pomodoro technique for "short sprints" Efficiency - Very easy to get overwhelmed and because no PM's, need to have lightweight tracking and management tools so don't waste too much time documenting instead of doing.

A google group has been set up for anyone interested in continuing the conversation and all of the attendees who were interested were invited. Please feel free to join us at http://groups.google.com/group/solo-scrum

Thanks everyone for the great input! Peter