I would like to ask about which one is the best and appropriate methodology to approach. I am currently doing a final year report and had develop an mobile (android) application for the project. The problem is; I am bit confused how do I choose and know if the methodology that I am going to choose is the appropriate one?
A brief about my project; As I said it is a mobile application developing in android platform. It has between 5-6 phases and every now and again I did some iteration on some the phases (e.g coding, design, implementation etc) to make the app ‘better’. Of course this project is run and develop alone so there is no team involve but me.
Can anyone please suggest me if Rapid, Sprint or Scrum be ideal for this? It would be good to hear any suggestion and inputs for you.
Scrum is a team methodology. It doesn't scale down well to being alone because the product owner/team/scrum master roles introduce conflicts. Iterations are still good to do as you have the opportunity to revisit what you are working on.
Actually, Scrum is a process framework, not a methodology -- this is straight from the co-inventor himself, Ken Schwaber. Being a framework, I don't see that you can't use parts of Scrum to manage a single-person project. A daily standup meeting will probably not make sense unless you really like talking to yourself but the practice of daily, weekly, monthly planning can still be used to guide your work. Having a regular retrospective can also be useful. Committing to completing a set of features in a timebox can also be used. Of course, a prioritized backlog is always a good thing, regardless of the size of the team. So I wouldn't say a solo development effort precludes using Scrum but rather that you just have to figure out what makes sense in that context.
BTW, I don't believe there's one "best" approach. It all depends on the context. Scrum is a good process management framework. XP has some really good technical practices. Kanban and Lean have good things about them too. And so do the rest of the Agile flavors, techniques, practices. I subscribe to the assertion that "Agile" is not so much a noun as it is a verb. Agile is a way of thinking and approaching a problem that is guided by a core set of values and principles. (Ok, the linguists among you might argue that I just contradicted myself there by saying that "Agile is a way of thinking" which, technically, makes it a noun but whatever). See also: http://agilemanifesto.org
author & internet detective
Junilu Lacar wrote:Actually, Scrum is a process framework, not a methodology
Junilu Lacar wrote: I don't see that you can't use parts of Scrum to manage a single-person project.
Agreed. But I don't think it is still Scrum. I think it is "elements of Scrum that you like." Retrospectives aren't specific to Scrum. Using the spirit of timeboxing makes sense. The reason I don't think it is Scrum is that I think removing at least one major role (product owner) really changes the experience.
Good points made by Jeanne re the different experience when developing solo and using parts of Scrum vs. doing Scrum with a team.
As to the OP though, if I were doing a solo project, I would pay attention to using good Agile practices instead of worrying about what particular flavor of Agile I'm using. I would at least have the following:
1. A good understanding of the features that I want to deliver, the order in which I want to develop/deliver them, and the timeframes that I want to deliver them.
2. A good way to track my progress. The old-school stickies on a board should work fine. If you really want to go electronic, there are lots of open source project management / issue tracking applications out there, such as Trac. Rally and Mingle have community versions that teams with 5 or fewer people can use for free. Maybe VersionOne has a community edition too, I don't know for sure.
3. A good development/test environment: source/version control (Git or SVN), a continuous integration server (Jenkins/Hudson)
I would also pay attention to the technical practices I'm using:
1. Doing Test-Driven Development
2. Automating unit and acceptance tests
As for your comment re the "5 or 6 phases" that your solo project has, you mention coding and design as separate activities. Creating a high-level design may be done as a distinct and separate activity from coding but if you practice Test-Driven Development, detailed design, unit testing, and coding are done in lock-step. There is practically no separation between these activities.