Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I would like to start a small part time business other than my full time programming job. Have you guys done that before? I know programmers who teach in evening schools after work. But then again, that is not business. What would you recommend to get another income stream going?
I have a full time programming day job, and I just started a small software enterprise this year.
My advice would be to start small, and make sure you have the time & energy to work on something after your day job is done. If possible, choose a business in which the code you write will be different from the code you write at work. A different language is a good start, but different types of problems would be a much better goal. If you end up working on the same thing 12 hours a day (8 at work, and 4 on the side-job), you will go absolutely crazy in less than two weeks.
As for what type of business to start, take a few things into consideration:
What kind of project would you enjoy working on?
What skills do you have, or can you learn in order to get this done?
How much time do you have available?
How much money is your time worth?
Once you have this figured out, you will know which projects make sense for you.
The only other piece of advice I can think of is to specialize. If you are a one-man operation, you can't compete with Microsoft. Choose a market in which you offer something really good to a small group of people. These little niche markets are the best place for small software companies to thrive.
Good luck and have fun!
I'm assuming you mean consulting when you say 'small business'. Network with people you know in real life. Communication skills are king. Find out exactly what your client needs and deliver promptly. Never promise something you can't deliver, it'll reflect poorly on you. Outline all of the requirements of the project and start drawing mocks/specs on a sheet of paper with your client. Outline their budget and see if their requirements are feasible for their budget. If you're developing software for a mid-sized business, talk to the staff who'll be using your product as an end user. If they currently have a solution, ask them what they don't like about it in terms of features and usability. See how it can be improved.
Be as genuinely helpful and knowledgeable as you can. If the project is out of your scope, lead them to someone who can help. You might not land that gig, but they'll probably tell three or four of their friends about you who might come back a year or two from now.
One relatively untapped market I've found is locating people who've recently outsourced. Not to make any generalizations but the "outsourcing boom" produced a bunch of sub-par software, leaving tons of code needing to be salvaged. I've found a bit of business by finding people with half-finished software and re-writing their code into something workable.
I would recommend having some sort of business plan. Don't just start writing some application or creating some web site and think it will sell. Do some research on the actual market for your product.
Also, having done it before, I would suggest having at least 1 other partner in the business. Doing it all yourself quickly becomes a waste of effort. You can do it, but it sure is a heck of a lot easier if you have someone to help with ideas, programming, accounting, web design, etc.
Also, think hard about whether you really want another job outside of your current job. I don't know what your life is like outside of your day job, but having another job (particularly one that requires daily attention like a website that has to be constantly updated) can be a real drain on your life.
If you do come up with a business plan and start a business, make it something you thoroughly enjoy! It can be very rewarding if you do.
I don't know why you reject teaching "out of hand". After working in industry for 10 years, I started teaching "Adult Education" night courses at a community college. I found it an excellent revenue stream that did not conflict with my day job (IT consulting). It was also and excellent way to remain "fresh" in my chosen languages (originally C).
Teaching keeps you on your toes, and lets you meet lots of interesting people (teachers and students) in a very fun atmosphere.
Also, when you are ready to seek another career down the road, teaching is an excellent choice. Teaching is also remarkably insulated from economic turmoil, as downturns often send people into training as a way forward.
Plus - you are giving something back.
Cheers,
-Richard
I did some work on an opensource project (DotNetNuke) as a developer and made some good contacts through that and became a consultant doing DNN work for various clients.
You obvisouly have to make the investment to learn whatever the OSS project is that you're working on, but on the other hand, there's a good chance you could carve out a pretty nice niche for yourself.
Related
I am looking for ways to measure and prove that our team is improving, but I can't just blankly state that, I need ways to prove it.
For example we are using coldfusion 8 and sql server 2005, and I can easily prove that the number of error's each day, week is getting less and less.
But what other figures, can i use to show what areas as a team, and programmer's of a site, that we need to either improve upon, or that we are making good progress on.
I am just a part time programmer, but I have far more programming experience, then my manager or the lead programmer.
So i want to help us identify and focus on areas we can improve upon, and ways to pay ourself on the back, for things we do good at.
Thank You...
First, a tip: Be careful with trying to improve you departments work if you are not one of the leaders. It's a good intention but be diplomatic.
Good ways to improve your output are code reviews. It worth much to have a group looking at code and share ideas to improve.
Another way is pair programming. In my opinion it doesn't have to be too often, but it is really helpful.
Third, do some occasional self education days where teams do some research on new technologies and stuff like this.
Hope this helps, Flo
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 are starting to adopt agile in a project we are about to begin.
Although I am not actually involved in the development of this project, I am involved in the stand up meetings.
Is it acceptable to say how you are learning a new technology (eg C# 4.0) as one of your tasks, alongside the actual deliverables?
My task is constant everyday so it is embarassing to say how I am doing the same thing (which is not a fun task - more admin type) while the other team members are doing C#/ASP.NET - the fun stuff. This obviously dents my morale.
How should I approach these meetings?
Thanks
Is it acceptable to say how you are
learning a new technology (eg C# 4.0)
as one of your tasks, alongside the
actual deliverables?
Learning time is legitimate, and if the company sees it that way you can make it a task.
Full disclosure: although the company I work for sees learning as a part of the process of software development, I don't actually put individual learning tasks into my weekly reports; I just build it in as a part of the larger development task.
My task is constant everyday so it is
embarassing to say how I am doing the
same thing (which is not a fun task -
more admin type) while the other team
members are doing C#/ASP.NET - the fun
stuff. This obviously dents my morale
Where I work the people that have ongoing "areas of achievement" list the individual tasks they achieved when we meet each week. Some of these tasks can be quite mundane, such as "I went to this meeting," or "I ran this script that took 2 hours," or even, "I read this chapter of that book because I needed to know how to do this." Our company understands that this is the nature of the work. You shouldn't be embarrassed about this.
Full disclosure: I break my "areas of achievement" into smaller goals that can be completed in roughly a week's time, so that each week I can say that I completed something.
I'd try to embrace the three questions:
What did I do yesterday? (Did you
learn about some of the dynamic new
features of C#?)
What are you going
to do today? (Do something with what
you have learnt that challenges you)
What is impeding you? (If you lack a
skill look to the senior guys to
help teach you.)
Kindness,
Dan
Suggest that you are a "chicken" in the process, which is an agile term for being an observer to the meeting but not a participant. http://www.agilejedi.com/chickenandpig
Since you consider your present task 'embaressing', I am assuming that you want some more development responsibility.
In my opinion is the stand up is probably a good time to ask for this.
I suggest that you say something passive like: before the next standup I will try to put what I have learned thus far in C# 4.0 to good use within some area of the project.
You in short order, you will be given something to do... then instead of having nothing to say during the stand ups, you will be too tired to go to them.
be careful what you wish for... because some day, you might get it.
As a junior, you're expected to learn. So, unless you feel admitting to learning would imply you're not doing your other tasks, I say go for it.
You can still report what you learned yesterday, what you plan to learn / try out today, and if you have any blockers that are preventing you from learning.
You will not spend the whole career as "Junior" (and everyone too). How do the team know that you can do higher responsibility? of course by showing that you're capable of. As it's Agile meeting, I believe everyone will have chance to show his idea.
Do your best to answer questions and show your "out of the box" idea to the team.
One day once they think that you can handle higher responsibility, you will out from your current position to more challenging works.
Learning/knowing something doesn't show that you can use it. There are some way to let the team know about your C# 4.0, by talk about it at lunch, writing on your blog then let your team know, write some tool for your daily tasks, etc.
Not only on the meeting :-)
Good luck!
Where I work, we do have people that will say in the stand up that their day will be spent on non-project work as the stand up is for a specific project that almost everyone speaking in the stand-up has a part.
If you repeat the same task a few days in a row in stand-up, you may be asked why you are taking so long on a card, if you have enough resources, etc. as there may be some thought that you are off on a tangent or spike.
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been reading about the various forms and aspects of agile development, but all focused on the corporate environment. I am on a student project team at my university, and I'd like to see if some agile concepts could work in an environment other than 'everyone works full/part time'.
We do have our own project server, with Subversion for version control, and Sharepoint for documents, wiki, and action items.
Some challenges
It's hard enough to arrange a weekly meeting, daily standups are infeasable
We're our own customers for the most part (we're part of a competition, but we can't work closely with the organizers)
Not just programmers, also mechanical/electrical team members
Sharepoint's action items don't have the best interface. Are there any extensions available? Would it make sense to switch to something else (like Trac) at the expense of a unified interface for everything non-svn?
Procrastination. As students, the most natural thing to do is wait to the last minute
We have our own space, but often, it's easier to do work elsewhere, and there's no way to predict if anyone else will be there except by making explicit arrangements
Other classes (still have to pass them, so total commitment to the team is limited)
Perhaps our team could benefit from more than just agile techniques, so all suggestions are welcome.
EDIT Thanks for all the great answers. I'm going to start asking my teammates how they feel about some of these ideas, and see what they buy into. Should I link them to this question? You can edit your answer or just leave a comment to answer this secondary question.
I wouldn't try to force a full, corporate environment style Agile programming workflow onto your team, but I do think that some level of Agile methodology could be valuable. I actually think that some of your "challenges" would be mitigated somewhat by some of the Agile ideas, but would require some level of commitment from every one on the team.
For example - the daily standups/weekly meetings issue.
This doesn't have to be a large thing (and, especially in a student project case, I'd say making it smaller is better). Having a Trac site (which I'd recommend over sharepoint if you're using SVN already) with a single place (like a wiki page) to just track the standup info in one sentence can still be valuable, without taking more than 1-2 minutes per day / person.
If somebody misses a day or two here and there, it's not a big deal, but if the team agrees to doing this, it can actually help the procrastination issue (forcing people to just say "I did nothing. I'm doing nothing" has a benefit - it keeps people at least thinking about your project, which tends to reduce the amount of procrastination), as well as having people work in different locations but still stay in communication.
This is also easy enough for non-programmers to do, and can help keep the mechanical and electrical teams working together, and everybody moving forward.
That being said, I'd make sure to keep it short and sweet - Try to keep the burden to a minimum, but I still think there's value in some of the Agile programming ideas, even in a student setting.
If you ask me you're adding too much overhead to your student project. Methodologies are generally only used in corporate environments because of the need to monitor and control human resources (control isn't the right word - but I needed one stronger than co-ordinate). In a group of students, there's absolutely no need to bother with anything like that. Adhering to a methodology will only slow you down.
You have identified your challenges. Make your peers aware of them and talk about how best to deal with them. Use methodologies as a source of ideas, but don't bend to one in your situation.
You can do a weekly or bi-weekly meeting that simulate a daily. Start your meeting with the three questions:
What did you accomplish since thelast time we met?
What do you plan to do until next time?
Is there anything blocking your progress?
Note that these can also be answered by your non-programmer teammate. In the company I work for, we have multidisciplinary team using scrum (programmer and artists) and it's working well.
If you don't want to do your meeting standing up, at least don't go for comfortable sofas. This should make your meeting shorter by making people more attentive.
You should use the method to your advantage and minimize procrastination by making interim milestones. Build your task list (excel, any other spreadsheet software is fine). Split them in milestone. When comes the time to review, sit with your team and look at your product like a client do, maybe involve your teacher.
Poker planning is fun, and a nice way to clarify your what you have to do, and how you plan on doing it. Breaking down objectives into tasks will involve people from all disciplines. But only people that can do the task should evaluate it.
IMO, SharePoint and agile don't really mix well. Pick something that's more "throw-it-up-there". I'd go with something like Trac, which has great Subversion integration.
It sounds like communication and procrastination is going to be your biggest challenge. If you don't give yourself enough time to do the work and do good testing, you're not going to have a good result. This is only logical, and doesn't really have anything to do with whether you're agile or not.
In your situation, not all of the Principles behind the Agile Manifesto will be easy to apply You might be able to apply some ideas that come from the principles, specifically:
short iterations at the end of which you always have a "working" project, even if some desired features have not been implemented yet.
maximize the amount of work not done - rather than designing a grand framework that you hope will cover all the needs of the project, start small and do just what is needed as you go.
If you have milestones during your project, consider having a meeting (called a retrospective) after each milestone just to look back and see how your process worked / didn't work and how you might improve it.
On the software parts, you could consider TDD and pair programming
I would say go with SCRUM. Skip the daily meetings and instead make a private forum and require each member to check it at least once a day. Try to make your sprint retrospective and planning meetings an "in-person" event over drinks or coffee.
The whole who is doing (and has done) aspect of SCRUM is amazing once everyone gets used to doing it. The 'sprint release' concept also helps team members from 'going dark' for too long and keeps the project based in reality ("What can we do in two weeks" vs. "I have this idea I am going to start and who knows when I can finish it").
Also, if your team has more then 8 people, skip SCRUM =)
Lastly, if you have the talent and someone on your team has the means (and desire), consider TFS workgroup (I think it comes free with academic MSDNs). If you don't have someone on your team who REALLY wants to take on that burden, skip it tho.
When I was in college, I took several courses that encouraged the adoption and use of Agile practices. They were mostly a mess and although I learned a lot of from them they generally weren't the things the professor was expecting us to learn. I do agile development professionally now and love it, but here are the things I wish that I had known when I was doing agile in school:
Getting things squared with your schedule is really, really hard, which makes daily standups more important, not less. If you can't sit in the same room (very hard) then use Twitter or Yammer or just email.
A lot of Agile's benefit is simply in getting you into a rhythm. That doesn't just mean weekly meetings; it means set goals, commitment to points, and weekly deliverables. This is tough to pull off in an academic context but should go a way towards helping you with your procrastination problem.
It's tough to get used to pairing; everyone has their own computer and style of development. Try to hook a second keyboard/monitor/mouse up to your existing laptops if possible, or use screen sharing software, and standardize on an IDE. Pairing also really, really helps with procrastination but trying to do it without good tools is an awful lot of trouble.
Don't skimp on unit testing, even if you think of it as a silly, academic, one-off project. I've done projects before that I figured were too small to bother with testing and it's never failed to come back and bite me on the ass.
Sharepoint might be a bit heavyweight. Believe it or not, we still do an awful lot of things on whiteboards or with index cards. You may be your own customer but that doesn't mean you can't have stories (discrete, estimable features, basically) and goals. It's helpful to be able to visualize it: these features are planned, these are in development, these are ready for testing. If you'd like software recommendations I can give you those but I do recommend simple paper for a lot of the planning process.
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 8 years ago.
Improve this question
I'm the second dev and a recent hire here at a PHP/MySQL shop. I was hired mostly due to my experience in wrangling some sort of process out of a chaotic mess. At least, that's what I did at my last company. ;)
Since I've been here (a few months now), I've brought on board my boss, my product manager and several other key figures (But mostly chickens, if you pardon the Scrum-based stereotyping). I've also helped bring in some visibility to the development cycle of a major product that has been lagging for over a year. People are loving it!
However, my coworker (the only other dev here for now) is not into it. She prefers to close her door and focus on her work and be left alone. Me? I'm into the whole Agile approach of collaboration, cooperation and openness. Without her input, I started the Scrum practices (daily scrums, burndown charts and other things I've found that worked for me and my previous teams (ala H. Kniberg's cool wall chart). During our daily stand up she slinks by and ignores us as if we actually weren't standing right outside her door (we are actually). It's pretty amazing. I've never seen such resistance.
Question... how do I get her onboard? Peer pressure is not working.
Thanks from fellow Scrum-borg,
beaudetious
While Scrum other agile methodologies like it embody a lot of good practices, sometimes giving it a name and making it (as many bloggers have commented on) a "religion" that must be adopted in the workplace is rather offputting to a lot of people, including myself.
It depends on what your options and commitments are, but I know I'd be a lot more keen on accepting ideas because they are good ideas, not because they are a bandwagon. Try implementing/drawing her in to the practices one at a time, by showing her how they can improve her life and workflow as well.
Programmers love cool things that help them get stuff done. They hate being preached at or being asked to board what they see as a bandwagon. Present it as the former rather than the latter. (It goes without saying, make sure it actually IS the former)
Edit: another question
I've never actually worked for a place that used a specific agile methodology, though I'm pretty happy where I'm at now in that we incorporate a lot of agile practices without the hype and the dogma (best of both worlds, IMHO).
But I was just reading about Scrum and, is a system like that even beneficial for a 2 person team? Scrum does add a certain amount of overhead to a project, it seems, and that might outweigh the benefits when you have a very small team where communication and planning is already easy.
Without her input, I started the Scrum practices (daily scrums, burndown charts and other things I've found that worked for me and my previous teams (ala H. Kniberg's cool wall chart). During out daily stand up she slinks by and ignores us as if we actually weren't standing right outside her door (we are actually). It's pretty amazing. I've never seen such resistance.
Question... how do I get her onboard? Peer pressure is not working.
Yikes! Who would ever want to work in such an oppressive environment? If you're lucky, she's sending around her resume and you'll be able to hire someone who is on board with your development process.
Assuming you want to hang on to her, I'd turn down (or off) the rhetoric and work on being a friend and co-worker first. If the project is a year late, she can't be feeling good about herself and it sounds like you aren't afraid to trumpet your success. That can be intimidating.
I know nothing about Scrum, however. I'm just imagining what it would be like to walk around in your co-worker's shoes.
beaudetious, buddy,
I would really suggest you read Steve Yegge's blog called "Good Agile, Bad Agile". It's an oldy but a goody, and I think it's a must read for anyone - like myself about 2 months ago - who gets a little let's say "over-eager" to agile-up their workplace. Agile offers a lot of good practices, but you have to take them all with a grain of salt and adopt what you're lacking and skip out on all the other crud that might be unuseful for a particular situation - e.g. the daily scrum. If your co-worker would just like to code in quiet (read Peopleware for why this is a good thing) and she's being a productive team member quit bugging her with your scrumming a let her work in whatever way she likes most.
People are usually less "hostile" about these practices if you just approach them and simply say "Do you have a sec? Listen, communication is really a problem right now, I feel like I don't know what you're doing and I really don't want to step on your toes again and spend two days writing something you already did like last week, so let's work on this. I'd like to try X, what do you think?". Be compassionate and don't tolerate "bad apples", that's literally how I agiled up my workplace, and many problems have started evaporating. We're by no means an 100% XP or 100% Scrum compliant place, because we just use whatever works and was needed.
Simple. Don't talk about scrum. Don't use scrum on her. Instead take the underlying principles of scrum (e.g. the purpose as opposed to the application) and create different approaches that accommodate her way of working but have subtle tints of scrum.
All humans are different and a lot of programmers dislike scrum. I wouldn't force it upon them as that would just be counter-productive. I'd suggest identifying the problems in the development process (in a non-scrum fashion), see if you can get her to agree that the issues exist, then ask her what she thinks would be a good solution. Her co-operation and input into the process is essential to her co-operation, if she doesn't have buy-in she wont become a citizen.
From there on in you can hopefully create some sort of quasi-hybrid scrum + her approach to the process where you can both agree on the way forward.
I think the key would be to help her understand why you are doing Scrum in the first place. I guess you have your reasons, so why not tell her? You are likely to get resistance towards any change if the people involved don't understand why there is change or what they will benefit from it. If you can explain your reasons for using Scrum, and the following benefits, to her in a way that relates to her everyday work, I think she is more likely to adapt a more positive attitude towards it.
If she sees no value in the Scrum process, or doesn't understand how it relates to her, she probably won't care about it.
I think one of the most important concepts for someone to understand regarding Scrum is the fact that you are working as a group and commit to your project as a group, not as individuals. For many people, this is the hardest thing to grasp, since they are so used to living in "their own World".
I'm not sure Scrum is the central issue here; I'm guessing she feels threatened by the new guy bringing in a lot of new ideas and stirring things up. I've been in that situation before as the new person bringing in a new perspective on things, and sometimes it's just difficult to immediately bring those existing people around to a new way of thinking. It often requires a culture shift which doesn't happen overnight.
Try to get her input and opinion on things as much as possible, and try to show that you respect that she has been on the team longer than you. If after a while she still doesn't participate, then all you can do is mention it to your Manager and let them take it from there.
Continue your efforts to involve the other developer. Remember you are the one who wants to make this change. Ask for help with problems you have. Invite them to the daily stand up meeting. I currently do the planning for the daily stand up and I make sure all the pigs and chickens are invited. If you are the lead on the project it is up to you to address the situation and take a risk. Put yourself out there.