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.
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
I am working in a dev team where we religiously follow agile.
However, I have not had to change how I work (unit testing etc doesn't count as I do that anyway). I mean, do I need to change how or how often I communicate? This soft skill side of things with agile is what I am interested in.
Thanks
If your team is utilizing agile well, then you probably should see some changes in how you work. It's possible that you already developed with a fairly "agile-compatible" mindset, even if your previous work experience was in a more waterfall-style methodology.
Some specific things that I think agile developers ought to be doing (and in a well-run agile team, will naturally find they need to do)
Focus on incremental, complete changes rather than massive architectures - This is a core tenant of agile from the macro planning side, but it's also important to practice even for an individual developer. With a 2 or 3 week iteration, you'll find you simply don't have the time to spend 1 1/2 weeks developing something, and half a week integrating it all together.
Check in early, check in often, and check in working code - Don't do this, and you'll soon find you're that guy famous for breaking the build with a day left before the iteration ends.
Know what's blocking you, and what is likely to block you in the upcoming week or two, and tell people about it - No one in an agile team likes hearing at the last second that a developer working on a critical piece is held up waiting for something to complete his work.
Think about the end of an iteration throughout the iteration - Every line of code you write should be done with the consideration of whether this is realistic to complete before the iteration is over.
Always Be Crunching (hey, I couldn't have a pithy list of advice without a cute, Glengarry Glen Ross ripped off acronym!) You'll learn by your second or third iteration that slacking off for a week followed by some all nighters is going to bite you in the ass.
If you're already following all these - great! They're certainly general best practices rather than being specific to Agile. I think most developers do have a bad habit or two that this list addresses, though (I know I do on occasion.)
In addition to Ryan's great points here are a couple more.
Discuss your ideas with other members of your team. Your fellow developers will quickly point out potential flaws in your thinking and suggest alternatives (be ready to listen and not get offended). I found this works best during planning/story tasking. In a 2-3 week sprint it is painfully obvious when you go down the wrong path. It might even stop you from successfully finishing all you tasks/stories. If others know your plan of attack up front it makes it easier for them to step in and help you out finishing your work if you need it.
Do not hesitate to suggest new ways of doing things. One of the great things about agile is that team processes are not set in stone but evolve from a series of retrospectives. If you have developers who never speak up, the process never changes and things do not get better.
Put your user's hat on. Every application has an end user. Sometimes (especially when you do not have a close contact with your users) you have to step back and question decisions (even if made by a product owner). If you can make a good case, not only your users but the entire team will benefit from it since the product will be better received. Developers do not do this often enough. We want to make things better, faster and leaner in the expense of other, sometimes more important things like delivering on time or adding more features.
I hope this helps.
The specifics of agile will be different for every person you ask. Yes, you probably want to communicate regularly, but you don't want to take it to extremes that keep you (or your coworkers) from being productive.
But like I said, it will be different for everybody. The only people who know how best to match your team are the people on your team. Just tell them you aren't used to agile and you were wondering how you've been handling it. They're really the only ones who will be able to say for sure.
Short answer but was very useful to all developers that asked me that question:
There is a book called Practices of an agile developer,http://www.pragprog.com/titles/pad/practices-of-an-agile-developer.
This book will specifically answer to your question. I like it very much because it's not just about the process, but behaviors and psychology.
Attitude-related things:
1) Good pair programming means making an effort to explain things really well and listening carefully. That's a skill in itself. You have to learn how other people tackle things and be patient when other people tackle things differently from you.
2) Being prepared to be flexible and change your mind. The smaller the ego, the easier and less painful it is to handle this.
3) To do agile well, you need to be communicating continuously with everybody in the wider team (i.e. not just devs - sysadmins, managers, customers, network admins, hardware people...) Part of this is feeling comfortable, safe and confident - i.e. there needs to be real trust in the team, not just phoney trust - real trust
4) Be prepared to work outside your specialism and comfort zone. I often have to pair with graphic designers, system admins and DBAs. Saying "that's not my job" isn't part of agile. We're part of a multidisciplinary team and getting the product released in a useful state is the whole team's problem - not just looking after my pet specialism.
5) Try to keep things simple and minimal - no "we'll make it totally generic" or "we'll need it later". Think "you aren't gonna need it." We're shooting for small, simple, concrete steps informed by feedback.
6) Tackle the difficult things and the things that aren't clear first - so that the you get feedback on the problems as early as possible so you if you have to revise estimates or cancel the work the customer gets informed as soon as possible.
7) Try to keep the team dynamics co-operative rather than competitive. Pitting people against each other pulls the team apart - and it gets you well-polished fragments and a broken product rather than a cohesive whole made by people that give-and-take as they find necessary to be successful.
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 5 years ago.
Improve this question
I'm in a new contract where they seem to have gone overboard with Agile, including hiring a consultant merely for facilitating Agile processes. Something he is instituting is a notion of "core hours" where we will all actually be in the same room together. Is this really what "core hours" constitutes? I ask because it's highly inconvenient to pick up my laptop and go to this shared location for half the day; I always thought "core hours" meant you were available, not necessarily in the same room, from 9:30 to 4, for instance.
Yes and no.
Core hours are the period(s) when all team members commit to working on the project (and not doing administrative stuff or other projects). For many teams, this will imply being in the same room, but with proper planning and the necessary infrastructure, the team can work well from different locations.
I think what you have is an extension of the "core hours" where you are. The idea of being in the shared location is that ad-hoc meetings could occur as well as possibly being within earshot of various discussions so that you can jump in if it is something where you think your opinion or knowledge would be useful, e.g. why was this coded like that? or why do we have this requirement? kind of thing.
I'd like to think that I'm up to date on the Agile world. In reality I am not. With that being said, I'm not so sure this is an agile concept but rather a convenient way for the team to collaborate. It sounds more like something out of Peopleware.
As goes with any team and trying something new, one, there will be resistance to change and two, the team should really have buy in to the new process and working methodology. The Agile consultant shouldn't just be barking orders of what you need to do. He should also be explaining and convincing you why this is a good thing. If you already think the company has gone "overboard" then I think something is wrong. Agile is a great way to work for a many (but not all) teams and shouldn't evoke a reaction like that
Having core hours makes sense so that there is an overlap for collaboration. Having people work in a more open space, maybe 4 people per large cube instead of 1 per small cube, also helps foster collaboration. At work I can just spin my chair around and there are 2 people right there who can help me out or answer questions. However, trying to force something that is uncomfortable and inconvenient defeats the purpose.
I think it would be better to tear down the cubicle walls and rearrange the cubes to make the evirnonment more collaborative.
Slightly off topic but won't fit in a comment:
Agile is extremely disruptive of a programmers "Normal Practices". The word Agile means you are going to have to adapt to changes, I recommend you try to accept them and not fight, because one of adaptations is to cut out team members that cause disruptions in the team.
A consultant is virtually required for a smooth, quick transition.
If your consultant is doing it right, you should be much more unhappy than you seem. During those core hours, none of you should have your own computer--you should be sharing a group. If things are done right, you should be coding in a "Bullpen" without cube walls (facilitates pairing and general communication).
But there are various levels to Agile, and it's intended to be adaptable. Many programmers have a problem with pairing, so often it isn't forced, or is just recommended.
At any rate, it sounds like your consultant is taking it pretty easy on you guys. Try to drink the cool-aid and relax, it'll all be over soon.
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.