views:

566

answers:

5

Let's say that a developer is interested in learning Scrum, but nobody else on the team is interested. I realize that Scrum is made for teams, and the process would have to be modified to fit a single person.

Is there any benefit to be gained by the developer trying Scrum, even if the team doesn't? If so, how would the process be modified to suit the situation?

+10  A: 

I think there's benefit to be gained by any method that helps you develop goals, tasks, keep on top of work and deliver something often.

Your individual work-products would gain the same advantages that teams gain with scrum:

  • You'd get something done every {Sprint Iteration Period Here}, something you can hand off and say "This is now ready".
  • Your estimation technique will start to improve with reflection and retrospectives
  • You'll start to plan your day and make commitments to yourself about getting things done, so again your estimation of your capacity will increase
  • Retrospectives will formalize improvement of your personal work process. You'll start actively improving, removing and adapting to suit you and your individual needs.

You wouldn't be able to rely on other team members to help out, which is a bit annoying, and you wouldn't have a product owner, Scrum master or a backlog to pick tasks from. You may not even be in a position to make decisions on what to work on next. But I think the formal discipline and reflection is helpful for all craft practitioners, at all levels, alone or in groups.

And who knows, you might even inspire your team to Scrum it up once they see what great results you're getting.

Dylan Lacey
You make a good point about developing estimation skills.
Tom Dalling
Thanks. It's something I've noticed for all methods that include analysis, even shallow analysis: You get better at it. If you just know you're bad, but don't check how you're bad, you stay the same.
Dylan Lacey
+1: These are good points. An "individual "Scrum" may seem a bit oxymoronic, but you would learn a lot about prioritizing and estimation and tracking your progress. You'd also develop a stronger focus on the tasks that really matter. And your team is a bit like a product owner in this case.
Jim Ferrans
+1  A: 

I would suggest that you use Extreme Programming instead, as that works better for one programming than a decidely team-based process.

Then you can get the benefits of being more agile, but if your team is not agile then you will have some issues due to the use of a different paradigm.

James Black
+1. I see Scrum as more of a team/project management methodology, while XP offers much more guidance to developers.
TrueWill
Might be hard to pair program though :)
Stephen Petschulat
+1  A: 

For me, the biggest key was getting buy-in from my supervisor. It can be tough to try and have some sort of Sprint only to have it interupted multiple times (Supposedly XP teams handle this better, but I don't think any developer does.). Also, don't forget to include either power users (they could be testers) or members of other departments that could be used as Product Owners. I like to sit with other users and do a type of paired programming (OK they don't code) where I can ask questions while coding and do quick demos to get feedback. This helps when I'm struggling to create specs because those requesting the app are having a hard time telling me what they want.

Jeff O
+1  A: 

Even if it's just you in the daily stand-up, it can be scrum.

If you compare yesterday's planned with actual and define today's plans -- without talking to other people -- that's still a kind of daily stand-up.

I'd say that what you're doing probably is scrum if you're following the daily-sprint-release cycles; even if there aren't a any other people to talk to each morning.

S.Lott
A: 

G'day,

For the best thing to come out of learning Scrum is the concept of involving the customer early and often. That way there are no nasty "that's actually not what we wanted" moments when you deliver to the customer after six months hard work.

HTH

cheers,

Rob Wells