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 6 years ago.
Improve this question
When I installed MS-TFS 2008, I started to get myself prepared to use the Agile Process Guidance template, that was shipped with the TFS server. With a little googling, I went through Mike Cohn materials:
I watched his conference in youtube "sponsored by google":
http://www.youtube.com/watch?v=fb9Rzyi8b90
http://www.youtube.com/watch?v=jeT0pOVg0EI
Read his book "Agile Estimating and Planning"
Watched the video series in his website: http://www.mountaingoatsoftware.com/presentations-tag/video-recorded
I was very happy while absorbing and eating the techniques he uses with the teams and how agile and Scrum are both such a great software process/methodology, until I saw Mike answer a question regarding the architect role and talking about the requirements document... at that point everything start falling apart, due to the following:
Last year I had been assigned to make full analysis "including requirements gathering" for big project, "very high priority project".
Within 2 months of hard work, dedication and commitment I delivered the whole analysis with full satisfaction of the customer and my BOSS and ZERO amendments.
Later on, the project entered the architecture, development ... phases.
Due to the fact that the system included many competitive and exciting features, I requested patenting it and its going in the process...
So imagine you are the kind of person who used to love facing all kinds of challenges and returning with excellent experience and results for the stakeholders and yourself, How fairly agile and scrum processes will credit and admit your talent and passion while the scrum master/coach treat the team as one unit that accomplish user stories and converge through trial and error approach??!!!!
With those dark thoughts about agile and Scrum I found many people "anti agile" and on top of them is "Crispin Rogers Johnson":
http://agile-crispin.blogspot.com/
That guy made an anti-statement for everything Mike Cohn used to talk about.
I really don't know what to do next! So any guidance will be appreciated.
Thanks,
For every project there is a correct development strategy. If NASA used agile or scrum they would not have the 1 in 100,000 lines of code defect rates that satelite system requires. You can't release and iterate away the bugs. If you do you wind up watching your system crash into Mars.
That said, you shouldn't have to spec out in excruciating detail every nuance of a website which is related to some Hollywood mogul's dog or fansite. That's something you'd iterate and fix while the customer gave you feedback.
There is a balance to everything and every a balance. Perhaps you should read a book like, Rapid Development. While it's slightly dated so is the mythical man month but both have lasting values. What these should teach is that there is no one way to do things but many. The project should dictate your approach not some evangelical software guru.
Disclaimer: This is in no way meant to imply that non-Agile are for "real" uses while Agile should be relegated to Scruffy McPointless projects.
As Wheaties mentioned, one strategy does not fit all situations. Agile approaches are usually well suited for products where either requirements are not known very well at the start and/or will be changing. The product is refined as the system is build iteratively and brought in-line with the customer's vision through collaboration with the customer. Now at the same time, from what I have seen, safety or something really expensive and unrecoverable e.g., a satellite, is usually not among the list of concerns for these projects.
Scrum and XP provide best practices for dealing with the management and engineering effort of being Agile respectively. You should freely adopt/modify these best practices for your circumstances but at the same time keep checking your implimentation against the spirit of Agile Manifesto.
Lastly, this interview with Linda Rising on InfoQ looks into if Agile is scientifically proven. Basically, are people in the Agile community giving themselves a "Sugar Pill"?
Interview Excerpt
Science is about experiments, about holding an idea for a short period of time and testing it and then examining the results of that test to find out whether or not the hypothesis holds up. That's really what Agile is about. Agile is about small experiments. I now believe that everything we do, not just software development, but our lives should be a series of small experiments.
We bring in every possible stakeholder, we bring in customers, we bring in users, testers work with developers. We are always examining carefully those sugar pills. Does it really work? What do you think? Are you happy with the results? That's the only thing that saves us - Agile itself. This series of small experiments.
How fairly agile and scrum processes will credit and admit your talent and passion while the scrum master/coach treat the team as one unit that accomplish user stories and converge through trial and error approach??!!!
If your PO is happy, the customers are happy, your BOSS is happy and your product is successful; then you should expect to see yourself and the team justly rewarded through increased pay and or other incentives (like vacation, stock, free lunch).
If you are looking to have Sunshine blown up you ass every day because of your "heroic" efforts that saved the day again then scrum will greatly disappoint you since agile processes by nature look to eliminate the hero position.
By the way you described your successful "2 month analysis" I would guess that your project was so well defined and or your niche so slow that you would have been successful no matter what process you used. Scrum shows its true advantage when you can't spend 2 months and come up with all the requirements and design.
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'm considering running a project using the Agile methodology but the project is roughly 9 months work for 6 developers. Is this project too big to run under as Agile?
Obviously ignoring the risks associated with running the first Agile project on this size.
Thanks,
Mike
Edit
Thanks for all the answers. I have no experience of Agile neither do I have a Scrum Master or anyone with much xp. My original thoughts were how to run an agile project as I haven't architected the system yet. So how do I run a team on a project which doesn't have architecture when the project will last 9-12 months.
Clearly I need to dedicate more time to understanding the principles before I dive in.
No, it's not too big at all. However, your question to me seems to imply a kind of casual approach to methodology choice and perhaps an unfamilarity with Agile generally, or you wouldn't ask it - which Agile methodology were you intending to use? Have you experience in that or in other Agile development approaches? How are you proposing to train peoole in what to do?
You have a typical setup here. 6 devs, room for several iterations.
If you had more developers, I would have recommended you to split them into smaller teams.
Project duration is less important since the approach is iterative and let you develop tbe most useful features first.
The project isn't too big to run as an Agile project.
However, you haven't mentioned any other team members.
Do you have testers and either business users or a BA who can act as a proxy, sat with your developers?
Do you have stakeholders who are prepared to engage and give you regular feedback?
Are your infrastructure team ready to provide you with the environments you'll need for more frequent testing, continuous integration, etc?
Are your architects happy to work in an incremental, evolutionary way?
Do you have a facilitator or coach who can make a safe environment to run retrospectives in?
Are the project board prepared to receive different kinds of reports and metrics?
Are you in a good place to learn and will the people around you make it safe for you to do so?
On an Agile project, the word "team" can be misleading, and the impact of the first Agile project is usually a lot bigger than anyone thinks it will be. Still not too big, though - good luck with it!
The Scrum Guide states:
The optimal size for a Team is seven people, plus or minus two. When
there are fewer than five Team members, there is less interaction and
as a result less productivity gain. What’s more, the Team may
encounter skill constraints during parts of the Sprint and be unable to
deliver a releasable piece of the product. If there are more than nine
members, there is simply too much coordination required.
Keep in mind "Team" in this context is part of the Scrum Team which also includes the Scrum Master and the Product owner, who are just as key. Do you have a person for each of those roles?
Granted, the Scrum Guide may not be a bible, but it's a good starting reference, especially for someone new to Scrum. But I'd say 6 is a good size for your team.
Are you working with a coach or someone on the Scrum Team who is experienced in Scrum? If not, there's a fair chance that you won't understand a number of key concepts. Said a different way, it's difficult to learn scrum from reading about it and trying it. Often teams that take that approach run into barriers, abandon Scrum, then tell people that "Agile doesn't work" because their project failed.
Is this project too big to run under as Agile?
No. Since you seem to be in the Agile and Estimation and Planning phase it, watch this video.
http://www.youtube.com/watch?v=FkWglejhJZM
Mike Cohn (author of Agile Estimation and Planning) talks about a 700 people Scrum Project, divided into roughly 100 Teams, which clearly is a several month project.
Now would you think of your project being big? :)
I would call your project and team as relatively small. Agile methodologies are better for small teams, but the project size doesn't really matter.
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
Our team is debating whether we want to become Agile or not. None of us are really fluent in Agile. I'd like some thoughts on when Agile works well, and when it doesn't.
To give a little background, we are a small group of developers, six in total. We have far more work that we can handle. Our priorities change often. What is a high priority today, may not be tomorrow. We have many applications to create and maintain. We have started to dabble in Agile practices to the extent that we have daily scrums and two-week Sprint cycles.
If you need more information to answer this, please feel free to ask.
Thanks.
Ralph Stacey's complexity matrix is commonly used to illustrate the sweet spot for Agile:
(source: typepad.com)
For simple projects (where both the requirements and the technologies are well known), the predictability is high so a predictive methodology (waterfall) works well.
For complicated and complex projects (and the vast majority of IT projects are), predictability is low and a predictive methodology won't work, an adaptive approach should be preferred. This is where Agile works well.
When both the requirements and the technologies are unknown, you're close to the chaos and the odds of failure are very high, regardless of the methodology.
I'm speaking only from experience; YMMV.
My team was unsuccessful at making agile work. IMO, it was because:
The very first time the dev team
would hear about a project, it was in
the form of a requirements document
and a deadline.
Stakeholders were often reluctant
to take time to look at the result
of a sprint's work, thus they would not take action between sprints if they thought the project was headed in the wrong direction.
When we showed stakeholders our work,
they generally just OK'd it. They
would talk about what they would
like, to which we would reply "That
can be done in about X amount of
time," to which they would reply,
"Well no need to go over the deadline
for that."
The deployment process was long and
complicated, discouraging frequent
deployments. So in practice, we
often deployed things when a 2-month
project was done, not at the end of a
sprint.
Our sprint planning meetings were
long and inefficient.
It seems everyone was confused about what scrum is (and about what our process was), except for the scrum evangelists.
So I'm pretty sure we were doing it all wrong. Don't you do it wrong, too.
Some things that have sped us up, which we continue to use:
automated builds that work on
everyone's machine (HUGE help!)
a formal arrangement for our code
repository
learning how to apply apply
abstraction mechanisms to UI code
refactoring
unit and integration tests
continuous integration
I guess you could say that our code is more agile, though our methodology is less agile. Whereas before we could not keep pace with demands, now we can.
(I'm not saying agile is bad; I'm just reporting my experience. Also, please understand that I do not choose what methodology we use.)
Reposting a related answer of mine:
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)
It appears your priorities are changing far too frequently for either methodology Agile or Waterfall. With priorities changing frequently, you are likely churning in and out of projects leaving a lot of them partly done. The Agile alway be ready to release may help. It has been my experience that getting a methodology in place will improve productivity.
Your situation reminds me of a project I worked on. The developer on the project asked one question at the start, "Do you want me to be do it right or be responsive?" I was on the project when it was two years into a six month project. One week the same functionality was implemented Monday, Wednesday, and Friday. Tuesday and Thursday were spent removing the functionality.
I would suggest you start adopting practices from Agile. Scheduling a short sprint period could help with changing priorites. It may be easier to maintain priorities for a period of a week or two and may make it easier to stabilize priorities. You will also need a backlog (sounds like you have a large one already).
Management may be more willing to hold off new priorities if you can slot them into a sprint in a week or two. You will also be able to identify the priority tradeoffs. If you add something to the next sprint, what will be removed.
Consider having part of the team working Agile while the others maintain the status quo. Rotate one team member each sprint as you are gaining experience. Consider having the whole team participate in a daily stand up status meeting, and the post sprint review. Once you have demonstrated increased productivity and returns to the company you should be able to increase the amount of work being done using your methodology.
Agile is a adaptive methology. Expect to be making major changes to your methodoly for the new year or two. Eventually, you should reach a stage where you are fine tuning.
In my experience, you absolutely need the following for agile (XP or Scrum at least) to work. Without these prerequisites you are likely to fail. Hard.
Team must be stable and 100% dedicated to this.
Team must be colocated in one workspace.
Customer/product owner must be available on site at all times.
Support from management. This means providing funds and courage to ensure the points above.
Give these points, you can probably tackle anything as long as you keep to the values.
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
What are the myths or misconceptions related to Agile?
There are lot of misconceptions related to Agile that an average new comer may fall into. What are the misconceptions in the Agile world and how do you justify that it is truly a misconception?
Update: Summary of Agile Myths
Agile doesn't allow documentation
Agile methods do not scale
Agile means no plan
TDD covers all the unit testing needs
Pair programming always results in better code
Agile is a silver bullet solution to software engineering problems (There is a silver bullet solution)
Agile doesn't need up front design
We're doing scrum so we don't need to do TDD, Refactoring Pair Programming, etc.
One can learn Agile from a book
Agile only works for trivial projects
Agile always uses "User Stories"
Read the following answers for more information about above myths and for more myths.
"Working software over comprehensive documentation" means you do not need a functional spec...
Wrong!!! It just means that you can iron out the wrinkles iteratively with the users - speaking as a vendor, you still need good documentation to assist with the QA and sign-off phases...
"We're doing Scrum - so we don't need to (pair | refactor | do TDD | ...)" Actually the Scrum founders - Ken and Jeff have been saying that all the high-productivity scrum teams implement the full range of Extreme Programming practices.
Test-driven development won't find all the bugs / isn't easy to apply to everything - so we're not going to try! - Learning TDD isn't an "all or nothing deal" and you get better at judging what to test and how to do it efficiently. I've been doing it for ten years now and I'm still finding better ways to do it and new things to consider.
I can learn all I need to apply agile methods from a book. - You need to learn by doing and that often means coaching and meeting other people that can help. Lots of things go wrong when people just try to learn it from a book.
Hysterical (and quite real) "The candidate must take direction from, and support the scrum master" (From a job spec I was sent last week...) - The scrum master isn't supposed to tell people what to do. He/She is there to facilitate - i.e. to help the team learn to sort things out themselves. It's a massive failure mode - having a scrum master that "commands" people!
Talking about "the agile methodology" - big cluelessness indicator. Firstly, talking about "agile" like it's a specific thing whereas it's a very vague umbrella terms for many different things. Secondly, use of "the" agile methodology - there are loads of them, and loads of different ways of doing many of them! Thirdly, a lot of people in the agile community got here in the backlash against the big, heavy UML-laden methods of the nineties. These people don't tend to use the word "methodology"...
You need especially talented people to develop software the agile way. Jeff Sutherland says that they considered using the "chief programmer team" model for managing teams in banks - but found they didn't have anything like enough "chiefs". Scrum is designed to get best productivity out of a lot of moderately able programmers. In fact removing one, disproportionately productive team member that doesn't want to help the others can "unblock" the mediocre team members and bring their combined productivity up to more than compensate for the super-productive former team member... That's what Jeff says anyway...
There are quite a few other XP-related ones that we came up with in an open space workshop that I led recently: http://xpday-london.editme.com/WhereHasXpGone
Myth: using Agile development practices is a silver bullet solution to software engineering problems.
Myth: Test-first development forces your project to have adequate unit testing.
Fact: Many developers get lazy, and the unit tests they write before their code are often weak and inadequate.
Myth: Pair programming always results in better code.
Fact: Programmers tend to be slightly anti-social and to have significantly different thought processes from one another. Having someone breathing down your neck as you code is very unpleasant, and the result is often a tense work atmosphere with a reduction in both code quality and quantity.
Myth: Agile means no documentation
Fact: Agile value working software more than comprehensive documentation but this doesn't mean no documentation at all. Documentation should be written just in time, and just enough. And no, Agile doesn't say one should always using user stories. Use them if, and only, if they are appropriate!
Myth: Agile means no plan
Fact: Agile does not support development without planning. Agile uses continuous planning and estimating to maximize the ROI. Actually, Agile is about scope management.
Myth: Agile means no discipline
Fact: Agile developers must be more disciplined for success.
Myth: Agile only works for trivial projects
Fact: Agile (actually Scrum here) has been used for
FDA-approved, life-critical software for x-rays and MRIs,
Financial payment applications,
24x7 with 99.99999% uptime requirements,
Multi-terabyte database applications,
etc
Myth: Agile doesn't scale
Fact: Sutherland used Scrum in groups of 500+, Cohn used Scrum in groups of 100+
Myth: "No Big Design Up Front" means no design.
Myth: Waterfall always fails.
Reality: Most of the software you're using on your agile project was developed with waterfall. Even BDUF waterfall, in many cases.
There's no real myths - but anything taken to an extreme will be wrong. An Agile project that does zero design in the hopes of "designing as it goes" will likely fail. A Waterfall project that designs everything down to the last semicolon will likely fail due to budget, time or changed user requirements.
It has been repeatedly said "Agile design methods do not scale" whereas Agile development will effectively scale to any size if implemented and thought out properly.
Myth: You need to carefully plan and schedule each sprint.
This leads you to do lots and lots of up-front planning so that you can fully plan each sprint.
This leads you to defeat agility and create a waterfall called "Agile".
The biggest myth I have seen is that people think it is better than other development processes.
It is the usual silver-bullet snake-oil that we have been seeing in this industry for years.
https://stackoverflow.com/questions/301993/is-agile-development-dead/302060#302060
Myth: Agile is always a better option when compared to other alternatives.
Fact: depending on project size, requirements (particularly flexibility of such), external schedule, and customer attitude, it may not always be more productive compared to orthodox methodology.
Myth: Agile means XP and Scrum
Fact: There are other practices like OpenUP, AMDD, etc.
It's easy to know what to charge your customer. This is alway the biggest problems for us, because we don't know the scope of the project we can't give the customer a fixed price, and most customers demands a fixed price.
Great thread. While I offer nothing new in my related blog post, I do illustrate the top two reasons why Agile fails when it does fail. 1) Lack of upfront requirements (taking the 'begin coding with incomplete requirements' to an extreme) and
2) Lack of adequate unit tests (because CHANGE will happen - and unit tests are the quickest way of catching all the breaking points resulting from the CHANGE).
http://www.anujvarma.com/BlogEngine.net/post/2010/11/03/Agile-versus-Flat-Footed-development.aspx
You're completely right that there are a lot of myths around Agile, some coming from outside, and others from inside. Here are a few more I thought of to add to the list:
"You don't need project managers or business analysts any more"
Although we're not doing BDUF and teams are self-directing, as things scale up there is still a need for people whose job is coordinating what's going on. And if you have a very complex business scenario, you may well need someone to help you make sense of it. IME, a lot of the projects that really needed PMs and BAs still need them (and those that don't need them now, probably never needed them!). But, of course, the roles of the PMs and BAs tend to be different in the Agile world, and that can make people uneasy.
"Agile can't be used for fixed price projects"
It can, but it is quite a bit harder. Especially since we all know that "fixed price" really means "fixed price, scope and time"...
"We don't do BDUF, we do it all as we go along"
The only way to work is JEDUF (Just Enough Design Up Front). Sometimes you need more, sometimes you can get by with less, but you don't do more than you need at that point.
Myth: Agile is anti-thetical to security.
Fact: This is only true, if you try to force a full-blown waterfall-style SDL (security development lifecycle) onto supposedly Agile teams. In fact, I have designed and implemented Agile-SDL variants in numerous organizations, and I can say that putting the Agile into the Security, can actually afford a higher, more robust level of security. it just takes a change of security mindset - from control to visibility and guidance.
If you don't show real value with agile, it will fail. And fail miserably as in bankrupt a company miserably. Going to agile just because it is 'agile' makes you look as silly as the CIO in this video:
http://www.youtube.com/watch?v=nvks70PD0Rs
John
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.