Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

At our company we have a team working on 3 different projects at the same time, where typically only one or two people are involved in each project. Project work often involves mastering new technologies and or solving bugs, both leading to tasks which are very hard to estimate. In this situation, the management still insists on using SCRUM and does not allow allocating a safety buffer at the end of the sprint for unexpected situations. The stand-up meeting happens for the whole team, although pretty much everyone works on unrelated software components or different software projects all together.

  • I was wondering if someone have seen SCRUM working well for a project with a single developer and fuzzy tasks, and how you made the process work well?

  • How to estimate tasks which involved research/mastering new technologies (this involves learning new programming languages, platforms, and development tools)?

  • Has anyone succeeded in convincing management not to use SCRUM for particular projects, and if yes, which arguments were most successful?

Thanks!

share|improve this question

migrated from stackoverflow.com Jul 2 '11 at 20:45

This question came from our site for professional and enthusiast programmers.

    
Looks like your management likes to use fancy word without even understand what is behind that word. No Scrum is not for your environment and it sound like you should look for another job. Doing every task in another technology is most probably waste of your time. –  Ladislav Mrnka Jul 2 '11 at 21:02
1  
possible duplicate of Using Agile development in a one person team –  vartec Jul 4 '11 at 11:06
    
1-person scrum = discipline. You simply have to learn to do most important/risky things first. This is ... common sense. –  Job Jul 21 '11 at 18:35
    
it sounds like, "the management", don't understand Scrum from an organisational perspective. The projects should get a time slice each and you should work as a team. Give "the management" a copy of Succeeding with Agile: Software Development Using Scrum –  Dave Hillier Aug 27 '13 at 9:13

6 Answers 6

Of course not. Your daily scrums would be very short, and incredibly boring!

You can cherry-pick the bits you think would help you though, cards make sense though you don't have to fill them out so fully; stopping after a set amount of time to check your progress makes sense too. But if you're doing that, check out Kanban, Crystal and all the other Agile methods too for bits that would help you.

share|improve this answer

Look up "Personal Scrum"... I've seen a couple or three blog posts of people doing this. Full Scrum has some notions that won't translate perfectly to single person teams. (My experience -- a certain "critical mass" of about 4 people seems to make team-stuff work well.)

http://blog.jgpruitt.com/tag/personal-scrum/ for example.

But things like task estimation, velocity, and time-bound sprints during which the task-list is "protected" work well even for 1.

share|improve this answer
    
+1 for a good link to a whole graduate project using personal Scrum: "the entire project has been chronicled in the materials below. To my knowledge, this is the first fully documented instance of a Personal Scrum project, and it is certainly the most open." –  Hugo Jul 3 '11 at 7:45

I am working in a similar shop. As others here noted, what you describe may be agile but not scrum. I would also add that whether or not back logs and sprints makes sense depends on if it is new work or maintenance and on-going support. If the former, then a waterfall approach would make more sense for a one-person team. If not, from a PM perspective, what they are doing seems like a good approach if they have multiple projects in their portfolio.

To Agile enthusiasts, the mere mention of using waterfall is sacrilege. But people need to use common sense.

Let me give an example from a recent project of mine. I was leading a team of 3 developers on an aggressive 5-month timeline to redesign two major websites. We had daily stand-up meetings. But it was a waterfall project because it was a small team, limited life cycle, and the developers were all short-term contractors committed to the project only until launch. The project followed a very traditional waterfall life cycle. Absolutely nothing wrong with that. Except we did work in an "agile" way, we kept the stand-up meetings and we kept agile development best practices. Our small team was exempted from the larger team's weekly sprint planning meetings. Why? Because we didn't have weekly deployments. And our team didn't depend on or influence the work being done by any other team. In fact, we worked almost autonomously. After the websites launched, we then transitioned over to an agile process for on-going maintenance and support. The other developers are now working elsewhere. All enhancements are planned according to periodic deployments.

The point is, it is better to use the processes that makes the most sense for the size, complexity, and the maturity of each project. If you're doing a lot of research, then it's hard to make an estimate for the next five months, so agile is probably a better approach than waterfall.

Part of the problem is that some people seem to think you be able to plan the next five sprints out in advance. That's been the case with me before. You should not be planning more than two sprints out because if you are then you are defeating the whole purpose of having sprints. A sprint is supposed to be a commitment to deliver a realistic quantity of enhancements within a set amount of time. You should not commit to something you're not sure of. Sprint planning is by its nature short-term planning, but that's kind of the point. If you have a long-term schedule, then think about breaking things down into smaller deliverables. Or setting up checkpoint meetings based on where you are in the SDLC.

Sprint planning is supposed to be a realistic commitment about what is guaranteed to be completed within a certain time frame. If you find that the planning is not accounting for unknown variables, perhaps you should start giving ranges or pessimistic estimates. Or as other suggested, use story points. Sprints also should not be booked completely to allow for slippage and other important tasks that come up.

share|improve this answer

There shouldn't just be one person on your team and I doubt there actually is. A "team" in SCRUM is not just the developers. Are you the customer representative, scrum master, developer, etc...? Are you really the only person doing anything related to this product, making decisions about it, or trying to sell it?

As to estimating research, you do it as a story. You make a story specifically for, "Research XXX," and give story points for it (remember, you're not estimating time here, but difficulty). You should also be able to fairly adequately estimate the difficulty of implementing some feature even if you need to research technologies. Sometimes this latter fact simply turns a story into "maximum difficulty".

No, you really shouldn't be meeting with all developers as your standup. You should be meeting with your team, which again is not just the developers.

Good luck. Hope you guys get it figured out.

share|improve this answer

No you cannot do scrum without a team. Team defined by SCRUM is "A cross-functional group of people responsible for managing itself to develop the product" which is an important role in SCRUM.

According to http://www.scrum.org/storage/scrumguides/Scrum_Guide%202011.pdf

Development Team Size Optimal Development Team size is small enough to remain nimble and large enough to complete significant work. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog

However you can still be agile, and maybe use the other characteristics of the SCRUM like maintaining product/sprint backlog and planning & working under sprints/iterations, reviewing and getting feedback from all stakeholders and re-planning and so on. Please read more about scrum as it is much more to it as described here.

share|improve this answer

Assuming you do have a product owner and a scrum master (if not then its not scrum), scrum can work for one man team. Scrum artifacts (backlogs, burddown charts) will be used just like they are used in multi-people team. Now about meetings:

Daily Standups: You would use daily standup to update everyone i.e. product owner, scrum master or anyone else interested in the progress. Scrum master will use this meetings to learn about any impediments you have. Product owner can help you with scope revisit if/when needed.

Sprint Review: At the end of each sprint you would handover working increment of your software to product owner or client. If goal of sprint was to learn "something" you will demonstrate a PoC that can be used by management (i.e. generally client for PoCs).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.