Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
While studying a software methodologies, I often see disclaimers along the lines of "This methodology requires a mature development team."
Which development methodologies are specifically geared towards immature development teams? I'd assume this is where most teams should start.
Let's define an immature team as a team whose members haven't worked together before, are working in an unknown environment (i.e. new company), and who haven't defined their processes and controls yet.
My $0.02
It is not really the case that any methodologies are specifically geared towards immature development teams per se. However if there is a characteristic of a methodology that would be beneficial for inexperienced developers it would be "well defined process".
The reason for the disclaimer ("requires a mature development team"), and this is nearly always applied to Agile methodologies, is that they require discipline and experience (which can only be gained from working on projects and learning from mistakes) to choose the right steps and make the right choices. Mature (read: experienced) developers know when it is safe (and not safe) to cut corners that inexperienced developers might do recklessly at every turn anyway. Also experienced developers have better intuitions and make better first choices, and know how to refactor designs and code properly when required.
To recast a famous quote from Bjarne Stroustrup into matching methodologies to (in)experienced teams, you might get: "Unleash an experienced team on a methodology that allows great flexibility and they might well shot themselves in the foot, unleash an inexperienced team on the same methodology and they'll probably blow their leg off".
(Apologies to Bjarne, and anyone offended by the thought of leg injuries:)
It helps to have someone who is familiar with methodologies who can pick and choose what to add when. Trying to through a full blown methodology at an inexperienced team will likely overwhelm the team. Assigning someone senior to own the process would be a good idea.
I would start with version control and continuos build processes first. These will help identify if other changes break code. Automated testing tied to the build process would be a close second. Choosing what to build and when is also critical.
Throughout all of this communication about what is working and what is not should be occuring. Change what doesn't work, and continue adding.
The tough part is to produce stuff while this is happening.
If you have code to maintain, you may want to start with a small team working on new code to develop the methodology, and spread it to the team.
The methodology should drive getting the right information to the right person when it is needed. If the methodology is getting in the way of generating working code address the problem.
Reveiw the waterfall methodologies for things that need to be considered. Review the agile methodologies for how to consider things at the right time.
I can only advise you to set the environment, start working, and your team will adjust to the chosen methodologies. Create small release cycles, and adjust the chosen methodology at the beginning of every new release cycle.
Introducing code/design reviews can be a very valuable first step. It (if introduced correctly) can develop team bonding; can lead to "egoless" programming; lead to sharing of knowledge and learning; and picking up errors early in the process, when enthusiasm can lead to major pitfalls. Like #BillThor I think version control is valuable, but would suggest that teams generally need to experience the need for it before they will whole heartedly adopt it, and that this occurs only after they have had a versioning caused problem. The element that is useful for my answer, #Bill's and #Peter's is a capacity to have mentoring available. This (ideally) would be the role of a manager with development experience, or a senior developer.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
After working Scrum(ish) in a previous workplace, I am trying to implement it in my new place of work for a brand new project (I am no scrum expert). We have some pre-requisites to code before we can begin working on the stories (which are being groomed in the mean time). Things like database design, api design, etc. We plan to use two week iterations and it's just not clear to me how the first one (or two) can provide something useful to the customer and "potentially shippable" if we first have to "lay down some groundwork" ? Any ideas on how to treat this?
What you are experiencing is very typical of new teams wanting to move to Scrum where they are coming from more of a traditional process. Adapting to Scrum is very, very hard and we always say this, and the reason for this is there needs to be many mindset changes.
The first change the team should understand is that when bringing a PBI (requirement) into a Sprint, it only a well defined requirement with nothing else. This means there is no designs, database schemas or API's for the requirement. The team has to do all of this in the sprint, plus build and test the requirement.
If you are new to Scrum, you most probably are squirming in your seat thinking it cannot be done. You are likely right for now, but this is where the hard work comes in ... changing the way teams work. This is hard.
Some pointers :-
Small Requirements - Most teams suffer from poor, ambiguous requirements which previously took days to design, build and test. The art is to learn to break these EPIC requirements down into smaller incremental requirements where each one builds upon the previous, but explicitly adds business value. Now, I am going to be blunt here ... this is the biggest challenge for most teams. Personally, I have been training/coaching Scrum for a number of years now have not found any feature that cannot be broken down into small requirements with an average estimate of 2-3 days to fully complete.
Team composition - The team needs people in it with all the skills necessary to design, build and test the PBI. They should not have dependencies on other people outside of the team. Having dependencies, cripples teams but it highlights to management there are not enough people with the specialised skills.
Sprint Planning - Sprint planning should be used to do high level designs and discuss how the team is going to tackle delivering each requirement. Many teams waste their sprint planning by clarifying weak requirements and debating the requirement. This is a sign of weak requirements and it should be addressed. Sprint planning is about discussing How to build/test a PBI and not What.
Coach - I would really recommend you hire an experienced contract coach/consultant to get you going and do things right. Trying to do this by yourself, just leads to a world of unnecessary pain.
Architecture - At the inception of the project, there is nothing wrong for the team and architects to spend a day or two brainstorming the macro architecture of the product and discussing the technologies to be used. However, when it comes to new requirements they are designed and adjusted into the product. This sounds hard, but with the correct software engineering patterns using SOLID principles, well defined patterns as well as strong Continuous Integration and Unit Testing. The risks of a bad architecture are eliminated. There is not question that the team should have a member in it that has the skills to design an architect the new requirements. [There is lots of evidence on the web that an evolving architecture with re-factoring results in a better application than a big upfront architecture - but that another debate]
Application Lifecycle Management - Invest in strong ALM tooling with CI, unit testing, test lab, continuous deployment. Having the right tools for the team allows you to deliver quickly, and a lack of these totally cripples you. CI with automated testing is essential for an incremental product as there is fast and constant change and you want to protect that a change does not break a previous requirement.
ScrumBut - Ken and Jeff no longer support the use of the term ScrumBut as it is perceived as elitism and often comes across as belittling. Instead it is preferred that teams are on the journey to implementing Scrum and helping them through coaching.
Welcome to your journey into Scrum, hang in there as it is very hard initially. Once you fully "get it", then you and your company will be really happy that you did.
In an ideal world, Technical pre-requisites should be factored into the estimate of each story and you should only implement "just enough" to complete the story. See "Do The Simplest Thing That Could Possibly Work"
Why do you need to design the API or the Database? Try to avoid Big Up front design. Avoid building Frameworks up front, apply YAGNI
It's hard for you to understand how you could ship something in two weeks because you have the cart before the horse; that is, your priorities are wrong. The important thing is delivering customer software - not building databases or API designs.
This is a trade of against long term productivity and you should avoid accruing too much technical debt. Many Agile methodologies would argue that up-front work like this will be wrong and therefore should be avoided to minimise waste. Lean software recommends defering decisions to the Last Responsible Moment.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am a long time agile advocated but one of the things that bothers me about Agile is that a lot of agile practitioners, especially the younger ones, have thrown out or are missing a whole lot of good (non Scrum, non XP) practices. Alistair Cockburn's style of writing Use Cases springs to mind; orthogonal arrays (pairwise testing) is another.
I read mostly Agile related books and articles and work with mostly Agile folk ... is there anything I'm missing?
It might be interesting in 5-10 years time to see how maintainable these systems are when nobody wrote down why a particular decision was made and all the people involved have left.
is there anything I'm missing?
Yes, I think a lot, but only if you are interested in Softawre Development Processes.
I like this paraphrase:
Each project should be as agile as possible but not more agile.
Not every project can be agile... but I think 80%+ can.
I see Agile as "car of the year". It is very well suited for most of the people, but if you need/want something special, for example car able to speed 300KM/H or car able to carry 20 tons of goods you need something else.
There is also so many cases when one may want something else than "car of the year" that requires a book to write them down :-) I recommend you Agility and Discipline Made Easy: Practices from OpenUP and RUP. In this book you'll find many "missing parts" very well illustrated. The key to understanding is that Agility is only a (requested) property of software development process which sometimes cannot be achieved. The book describes several Key Development Principles (which are basis for RUP) and explains which level of "ceremony" and "iterativeness" follows from using them on different levels of adoption.
An example
Practice: Automate change management and change propagation
In your project you may require very advanced and strict change management and decide to "Automate change management and change propagation" by implementing custom or re-configuring existing tools and by using Change and Control Board.
Effect: This most probably increase level of "ceremony" in your project.
(...) have thrown out or are missing a whole lot of good (non Scrum, non XP) practices.
Scrum is not prescriptive, it's up to you to choose how to do things. In other words, nothing forces you to use User Stories for example (even if User Stories work for lots of teams, there is no consensus) so feel free to use (light) use-cases if you think they are more appropriate in your context. To illustrate this, Jeff Sutherland reported he would never use User Stories again for PDA device projects (they use some kind of "light specifications" in his current company). And the same applies for testing, use whatever works for you. To summarize, if you find XP not flexible enough, use something else... and inspect and adapt.
Iterative development.
In practice, agile teams may do iterations (or anything for that matter, agile is a kind of "true scotsman"), but agile processes don't require or define iterative development sufficiently.
Take RUP, for example - clumsy and bloated, it does compile a few good methods for long-term development that agile misses.
On a general note, agile is a way to steer clear of problems: how to avoid long term planning, how to keep teams small, tasks short, customers involved, etc. It works more often than not, but sometimes you have to face and solve problems: how to reach strict deadline, make big team work, achieve distant and complex goals, make customer refine requirements. That's when one needs to look beyond agile.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Looking for work at the moment, I'm seeing a lot of places asking for Agile experience, but until I get a job with a team that is using Agile, I suspect I'll never get the experience.
Is it possible to adopt Agile methodologies with just one person?
Sort of answering my own question, there's similar questions at :-
https://stackoverflow.com/questions/1407189/can-agile-scrum-be-used-by-1-or-2-developers
(I guess I should get better at searching.)
You seem to be coming at this from a work experience point of view; if you are looking to build relevant experience to get you a job on an agile project I would probably think a little more laterally.
Firstly could you work with others, maybe on an open source project? That would be a good opportunity to try out agile methods with others who may have more experience.
Secondly, you could look at using some of the common techniques or tools, even if it's just to learn how the tools work - e.g. you could set up a continues integration server to run builds and unit tests when you check in code. If you are working on your own you won't gain much in terms of productivity by doing this but you would gain some skills and have something relevant to say to future employers which would indicate you are committed to the agile style.
Yes
Check out PXP or Personal Extreme Programming.
http://portal.acm.org/citation.cfm?id=1593127
Summary from the paper:
Personal Extreme Programming (PXP) is
a software development process for a
single person team. It is based on the
values of Extreme Programming (XP)
i.e. simplicity, communication,
feedback, and courage. It works by
keeping the important aspects of XP
and refining the values so that they
can fit in a lone programmer
situation. PXP can still be refined
and improved. It is in the tradition
of XP practitioners to vary XP to
encompass whatever works. We hope
that PXP inherits these pragmatic
roots, as well. Giving up XP tenets
like pair programming is not
necessarily a tragedy. We still
believe that following XP strictly is
a more effective way to pursue
multi-person projects. But we are also
convinced that many of the XP
practices and methods can be applied
to individual work. The PXP
approach tries to balance between the
"too heavy" and the "too light"
methodologies. PXP will inject the
right amount of rigor for the
situation without overburdening the
team with unnecessary bureaucracy.
Yes - it is possible to do many agile practices as an individual.
If you already know how to do these, you can do them as a sole developer:
test-driven development - great place to start
refactoring
continuous integration
doing the simplest thing that could possibly work (and evolving it through refactoring)
automated deployment
planning meetings (a team of one plus customer)
Things you can't do on your own:
pair programming
CRC/RRC workshops (... you'd have to talk to yourself quite a lot)
Pair programming would be hard this way :)
Let's check Agile Principles:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
You can do all of those things even while working on some personal project alone. You can use also GTD while working alone, you can develop your product through iterations, you can adopt timeboxing, you can ask some family members or friends to do usability tests with you (and this works really well).
As a conclusion, you can really get tons of Agile experiences alone. I strongly recommend you to read some books first tho, as some of principles can be easily misinterpreted.
Some aspects can be done alone: running a product backlog and using a task board come to mind. See what the secretGeek is doing.
Of course some cannot: pair programming, scrums etc...
I recently interrupted a big project. It was a medical software project. While working on it, I realized some patterns about solo programming. I want to share my experiences here:
Your software's working logic must always reflect the real world. You catch fish with fishing rod, not baseball bat; so forget it.
Always start building from the project element to which all other elements refer. That makes sense if you think that like the function in a software project which is called at most. That might be database modeling. It would be useless if you model data access layer first, before modeling database.
Never mind changing variable names. That's the most written entry in a programmer's diary; so no need to be ashamed.
Methodology changes the world. Make worth of it. Make every single logical process with a function or procedure. When project gets huge you will understand thats the best way.
If you're not designing a language compiler in assembly do not hesitate using huge procedure call chains in which one calls another and that calls another and so on. Use methods everywhere, nearly resemble every single entity with classes and be modular.
Modularity is everything. Set modularity your primary goal. Have i said it is everything meanwhile?
Last word for beginning the project. If you're building an apartment you install main entrance at last. But when using, you enter the building from entrance. Be aware.
These are some of my design principles I learned and learning day by day. I hope having been useful. Do your best.
While some Agile practices are directly targeted at more than one person teams, they are just practices, they are just a mean, not an end. I mean, Agile is not about doing pair programming, stand up meetings, etc. Agile is about maximizing the customer value while minimizing waste to provide the most optimal ROI. Agile is business oriented, practices are just a way to achieve this goal in a given context. So, back to the initial question, it's definitely possible to adopt Agile practices (that make sense in your context) to maximize the delivered value: continuous planning, limiting Work In Progress, Stop-the-Line culture, time boxing, high quality, just enough specifications, just enough and just in time documentation, etc, etc.
Definately. Agile is very flexible in terms of how many people are involved. Some methodologies, like Scrum, focus mostly on doing as much as possible in a limited time, like two weeks (sprints). That includes whatever you want it to. If your team requires QA, then that is part of it. As a loner, you decide what you want to include.
After the scrum sprint, you look at what you could have done differently to get more done, and move to the next one.
Some other methodologies focus more on getting features done in each iteration, say three small features developed, tested and refactored.
As you can see, there are tons of ways to apply agile to any project. You decide which aspects you want. Though obviously one integral part is doing things in small increments.
Yes
XP/TDD scales from one to one thousand. Pair programming is optional.
YES.
Agile is more of a state of mind than just a methodology of software development like waterfall.
Scrum is one of the very popular agile methodologies. You can study below aspects of scrum in detail:
Benefits of Scrum/Agile over Waterfall
How can you create better "products" with Scrum/Agile
What are the types of projects better suited for Scrum
Pros and Cons of Scrum
Scrum Rituals and why are they necessary (What advantage do they
bring)
Different roles in scrums and their responsibilities (Scrum Master,
Product Owner and Development Team)
After you have good understanding of working of scrum and its benefits, try to create a pet project.
You will have to play all the roles yourself. You can try to distinguish between what role you are playing currently by wearing different colored hats for each role.
Example:
Product owner : Think from product perspective, what should be the features in the product and why would they be important for your users etc. Then proceed with all the scrum practices.
Scrum Master: Keep checking if you are following all scrum rituals in the right sense and spirit and are you able to derive benefits out of it.
There will be limitations,example you cannot have Daily stand-up meeting, obviously because you are the only person in the project. But if you follow above, you should be good to secure a job and play your part well in the team.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
As a developer who's never worked in Agile specifically (but have worked in TDD shops), I see employers that are running Agile shops resistant to hiring someone who hasn't worked in Agile. I've run into this a few times over the past few years. Is it really that fundamental of a philosophy change? After working in TDD, I can almost make an argument for not hiring someone who's never done TDD (when working in a heavy TDD environment). Perhaps I don't understand Agile and the difference between it and TDD.
I'd actually like to work in Agile, but this seems to be one of those times where you have to have the experience to get the experience. Sure, you can do it on your own, but that doesn't qualify if you ask me. As an employer, I wouldn't really call it applicable.
Agile is not an engineering philosophy in the strict sense - TDD, Peer Programming, etc are engineering practices that Agile uses - but rather Agile is a management methodology. As such, it's more important that someone be open to the mindset that Agile demands, rather than them actually having worked in an Agile shop before. Yes, it really is a different philosophy and approach to software development. People who expect everything up front and to be told what they need to do will be very out of place in an agile environment.
When I have interviewed people, I do ask whether they have any Agile experience or knowledge, but what I really look for are some of the following:
Flexible mindset
Confidence to allow self-empowerment (critical in any agile environment)
Ability to self-assign tasks
Communication skills (top 3 most important)
Ok with vague instructions, able to self-teach
Those are some of the qualities that I think qualify someone to work in an Agile environment.
Having an understanding of what Agile's core principles are is important to understanding Agile. TDD is just a small part of Agile and more specifically XP (Extreme Programming).
First I would take a look at the Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Then I would take a look at the SCRUM process (which is also a small part of Agile) to see what's involved there.
When I interview developers I look to see that they have an understanding of Agile and what that entails so that I can then determine if the Agile enviroment/mentality is one what they would enjoy working in.
I've hired developers into agile teams quite a few times. I'm not at all resistant to hiring a developer with no prior agile experience - they'll be slightly cheaper ;-)
However there are questions that I would ask such a candidate and there are certain responses that set off alarm bells - letting me know that this person is going to be too much work to re-train.
For instance being precious about their code and designs - a sure sign they'll be a 'mare in scrums and code reviews.
Agile is an extreme democracy - everyone is equal, but that doesn't suit everyone. Some developers just seem happier in an autocracy (tell me what to do and how to do it), monarchy (layers of middle management) or bureaucracy (specs and development by rote) - those guys just don't work in agile.
Some developers are much happier with the agile ideas, and those guys can get hired whether they have have prior agile or not.
I wouldn't worry about not knowing all the process details - good developers read up and stay current on the technologies they use, not process methodology. Since every company tailors their agile model anyway (if they don't they're doing it wrong) it really doesn't matter which variant they started with. You should know some of the terminology, but that takes a day of reading up before the interview at most.
The brand of agile that we use is composed of Project Management Practices as defined by SCRUM and Engineering Practices as defined by XP. If we are starting a new team, we will look for key roles to serve as embedded coaches for the team (an Iteration Manager/ Scrum Master Coach, Analyst Coach, Technical Coach and Testing Coach). For an existing team, given that we use pairing, we are more interested in developers that work well with others than a super programmer.
Because we using pairing, a new developer will become productive within a month with the agile engineering practices as well as the business and application domains. It provides the team with little value if a strong programmer joins the team but is unable to pair effectively.
When we interview, we ask the candidates to pair with several team members. Through pairing, we learn if the developer works well with others in a pair. In addition, we gain insight into the developer's technical skills. Because the candidate works in several pairs, we get the perspective of a number of team members.
All of our agile teams have been very effective and their projects successful. We have trained more team members to become effective with agile than we have hired experienced agile personnel.
I think it is a typical case of over-insisting on a specific skill set. Like employers who don't want someone who knows JBoss when they use BEA for their application server.
A good employer will recognize if someone is adaptable to an agile method or not. Now if they have two otherwise equal candidates in front of them, perhaps that is a bit different.
It is certainly a handy way out of having to explain other reasons that may play a more important role in the decision.
Any company or opportunity that dictates SDLC by practice instead of best fit for the current project/situation is already showing signs of it's limitations and you are probably better served continuing your job search.
Absolutely YES
There's a lot of teamwork and trusting your peers in agile and specifically in extreme programming. You need to know other people are writing decent tests and not breaking your code. Good XP developers don't want people on the team that are going to make their job much harder.
Nothing wrong with being a beginner, or somebody new to a team - but there is an element of building trust just like you would to get committer rights in open source.
These days everybody says they are agile and if you offer enough money, practically everybody with the slightest tech skill will apply for the job... so expect people to put you through a pair-programming interview.
Typically we need to know:
Can you really pair program?
Do you really know how to do TDD?
Are you just saying these things or can you demonstrate you do them?
Are you going to take the initiative or are you waiting for an old-school "project manager"-type to tell you what to do?
Stuff that will help get you hired in an agile shop:
You have tried to introduce test-driven development somewhere even if you didn't get buy-in. (It worked for me...)
You have sample code you wrote - or an open source project on which you can demonstrate test-driven development, automated builds...
You find that you've worked in teams with short release cycles ...
In your current job, can you implement some form of Agile Developement to show you are interested, have looked into it and actually have some experience? You may be able to find some non-developers to work with you. A power-user could sit with you during some coding. I'm sure no one would get in the way of using some of the Agile documentation (sprint log, burn chart).
I'd likely put forth this question: What development methodologies have you been using up to this point in your career? Do any of them encompass the spirit of Agile's ideals?
If you are someone that loves to develop via Waterfall and think it is just absolutely perfect for your world of development, then going Agile would be like going from driving a car to flying a plane or a boat. It is that fundamental a difference as you aren't going to necessarily know where you are going and deal with changes very differently than a waterfall style where each stage goes in order and there isn't any reprioritizing without jeopardizing the whole process.
When a company uses the umbrella term "Agile" in recruiting without being more specific (e.g, by asking for XP or Scrum experience), it's often a placeholder for something else they're looking for. They may want "developers who will pair program" or "developers who won't dig in their heels about not having requirement and design documents before they get started" or "developers who won't go off into a dark corner for weeks on end". The trick is to figure out what they mean.
From a narrow Silicon Valley hiring perspective, a candidate who is familiar with Agile practices (e.g., knows what XP is), has done some of them (e.g., pair programming and TDD), and who wants to work in an Agile environment gets past that hurdle.
Employers most likely stick to hiring people who are knowledgeable of agile, rather than not, because agile methodologies require that almost every team member know about the processes required by each agile methodology (SCRUM, Crystal, XP). For example, SCRUM requires that all team members, including management, understand and follow the concept of self-organization. They’ll need to understand that they won’t be dictated on their current performance: They need to instead address their issues openly (or what typically happens at the daily SCRUM). If you put someone on the team who does not know agile, they may immediately assume that since this methodology has low documentation, they can run in and code-and-fix to build a project. However, agile methodologies are process-heavy, rather than documentation-heavy.
I understand your frustration but the truth is, if you never worked in an Agile environment you are very likely to behave in counter-agile ways (so to speak), and you will likely not even understand what is it that you are doing wrong.
Since Agile is so much about work philosophy it's not something you can learn merely by reading a book, you need to have intimate understanding of how non-Agile firms operate, what issues this causes, how Agile changes that, and how you to fight the entropy (the attempts of the external world to introduce the non-agility back in).
My advice is that you first read more about Agile and start analyzing your own behavior and behavior of whatever firm you currently working at from the Agility/non-Agility perspective. Once you're able to discern the patterns, you can start trying to change your firm from within. When you fail with that, go to an Agile company and they will hire you, I promise.
Maybe they take the mentality of the barkeep in the Mos Eisley cantina (paraphrased):
We don't want your kind here.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We have proposed to use Scrum in our IT Project and our Adviser asks us if it is appropriate to us because we are still amateurs.
Is it appropriate to us Scrum even if we are amateurs?
The discussion is usually agile vs. waterfall, right? I am linking an article, but it is in Portuguese, so I'll try to transmit some of its ideas:
Waterfall is like chess. You think and plan a lot, try to foresee every possible issue as soon as possible. There's a lot of planning, but makes sense only on stable and well-known domains, where change isn't much expected.
Agile is like soccer (or many collective sports): decisions are made in-game and should be done fast. There's no much time to analyze every consequence. It is "ideal" for dynamic and unstable domains, where change is always expected (web applications, for instance, tend to fall in this category). Another point to note is: even if you have the best players, if they don't do well as a team, you won't be the winner.
IMHO, Scrum would be useful, because:
Once every two weeks (or every month, depending on iteration time) you'll be able to see what's working or not. And this is very valuable, specially as an "amateur" team, which is expected to be learning and finding things out much more constantly.
As amateurs, you probably won't be able to foresee everything (and that's something agile embraces)
There's more space for sharing experience (stand-up meeting, retrospective, and even planning meeting). And you share REAL experience (you must write code every week rather than just plan)
Here's the rub. I think Scrum is going to be tricky not because your team is a bunch of amateur developers but because your team is a bunch of Scrum amateurs. If you have an experienced Scrum Master, your team may reap the benefits of Scrum. Without a point person with Scrum experience, however, there's going to be overhead in learning as you go and more than likely you will get off the Scrum path quickly. At best, you will exercise a modified-Scrum approach (which isn't necessarily a bad thing.) I don't mean to sound negative or doubt your team's ability to practice Scrum, it's just best to have someone with prior Scrum experience before your team dives in. Best of luck.
Scrum, along with other agile methodologies, is not appropriate for a team that consists of students or otherwise inexperienced people.
Wikipedia has a good section on the suitability of agile software development. Barry Bohem and Richard Turner, leading software engineers, wrote a book that includes factors that can help determine if a plan-driven or agile methodology is better on a given project. One of the cases where plan-driven methodologies stands out is with junior developers, which includes students and amateurs.
Now, this doesn't mean that you need to use only a plan-driven approach. I personally think that the most important thing you can do is to find a process that works for your team. You can probably incorporate agile approaches - test driven development, continuous integration, pair programming - into a plan-driven environment that visits each lifecycle stage once.
I disagree. Scrum is better in a situation where
you can depend on the "players"; and,
the requirements might very well be changing underneath you.
A college type project generally has pretty good requirements AND the potential of flaky team members.
Further, you have to think about the purpose of even doing the project in that setting. The students need to think, plan, and discuss how things are going to work before they start diving in. Finally, scrum works best in a close knit, fast paced environment with constant communication. Which is unlikely to happen on a school assignment.
Scrum encourages a "let's just start" programming attitude which, again, is fine when you have experienced professionals working on it that through experience know the pitfalls to avoid up front.
No one says you have to fully implement SCRUM.
I can say from personal experience that SCRUM is great for 'amateurs' :) . At my 4th semester, we had to make a project in the scope of 4 months. Our group of 4 managed "semi-SCRUM" like this:
Sprints were of 2 weeks
No daily stand-up meetings (We were physically close, so we took everything on the fly)
All sprints had a headline from the start of the project. These were our milestones.
We had 2 weeks of buffer time, since we expected to delay :)
SCRUM itself is rather complex, but the ideas of sprints, part-deleverances, leadership and the likes are great. It doesn't really take more than a day for everyone to understand these concepts. For us, SCRUM made sure we had a top-notch project ready by the deadline, with tons of feedback during the development. Top grade too :)
There will always be some team dynamics to get worked out for how things like the daily stand-ups, storyboard and other Agile practices mature in a group. The big question to my mind is whether or not you have enough time to reap some of the benefits that comes after a few sprints and some rhythms have formed within a group. I would suggest at some point calling in someone more experienced with Scrum to give feedback about how to improve what you have as part of the methodology is to grow and evolve over time, IMO.
So, it is fine for you to use Scrum and see how it goes. After all, everyone has to get started somewhere and various modifications on the methodology are common to my mind. There is something to be said for how you'll walk the walk which may be easier or harder than you imagine. Good luck and I do realize this is echoing a lot of Ben's excellent answer.
I think your main problem is going to be in the estimation and tracking to the planned sprint duration. In the past, I’ve found that when resources are not intimately familiar with the coding environment they’ll be working in (this can happen with professionals adopting a new technology), it’s very easy for sprints to go off the rails. Task breakout estimation becomes guesswork and consequently it becomes very difficult to run sprints to plan.
Having said that, there are elements of Scrum which would be very useful in this environment; daily standup meetings and iterative releases are the ones that come immediately to mind. Personally, I don’t subscribe to the “do all of Scrum or you’re not doing Scrum” mantra. Be pragmatic in your approach and pick elements of the methodology which will work for you. Make sure you incorporate the continuous improvement component of doing sprint retrospectives so you can proceed with the assumption of refining and enhancing and you’ll be heading in the right direction.