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.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I am a trainee in development sector. My Boss says that i should be an agile programmer.
I went through through the net and found some interesting things about agile programming. Being a newbee how should I start with agile?
What should be my first step in Agile programming?
At present I am in pair programming. But it's not exactly pair programming as I am just watching what my co-developer is doing.
I also wish to be an agile developer.
Can you suggest a way for me stepwise?
I wish to develop myself and also my programming skills.
The keyword is Courage.
Courage to estimate and discuss your work
Courage to start work on small stories with insufficient detail
Courage to talk to customers to elaborate said stories
Courage to constructively critique team members code
Courage to review your mistakes (in public) and learn from them
Courage to release "unfinished but good and shippable" code when it already delivers value.
Courage to stick to the agreed team processes when management has a bright idea
Courage to amend agreed processes in team when a better way is found
Courage to deliver high quality code using test driven development and continuous integration.
...
Note: The unfinished part does not mean "low quality", it means satisfying the customer, cleanly implemented, tested, ship-ready. However falling short of the developers idea of perfection, i.e. spring configuration is a bit clunky, some refactoring can be made, some auto configuration, some speed improvement, some corner cases... I found that some developers take the "user story hostage" and keep it unshippable till it is perfect. If it is good, you should let go, better is for the next sprint.
In my organization, all you have to do is declare yourself to be an Agile Programmer. Magically, the need for planning and documentation disappears.
What should be my first step in Agile programming?
Read the 12 principles of the Agile Manifesto over here. Understand and try to make sense out of each one and implement them as simply as they are stated.
Although agile principles can be adopted individually, it should be adopted on an organisation level or at least project level IMO. Urge your Team and your project to use SDLC methodologies which are more agile like Scrum for e.g. If you adopt Scrum properly you will automatically be agile.
As for Agile programming - Pair program, configure a Continuous Integration and Build system, use Test Driven Development, pay continuous attention to code quality and design best practices by doing Code Reviews, design discussions and have high unit testing code coverage.
Ask what needs to be done.
Sort that list in order of priority.
Code, test, and deliver the most important thing on the list; resist being interrupted while you're doing that: if someone tries to interrupt, explain that you're busy doing the most important thing, and that because you're concentrating on only doing that one thing it won't take long and they they'll be able ask you to do something else soon (this phase is called the "sprint").
Once you've delivered, ask for the next most important thing to be done, and then do that, etc.
As per my understanding Agile development process can be put forward ( as already told by ChrisW & Peter :-) ), something like :
There should be agility/movement/progress in the work being delivered in the specified time.
You need to be :
1) Choose yourself/ get allocated by your boss, a task with an accepted period of time
line.
2) Ready with a correct estimation of time for the bit of work to be handled and get
an agreement on that
3) Every day have a discussion in the sprint/meeting(just for : 10-15 min.) with your
boss/team and explain your goals/plans for that day.
4) It will be a best practice to not to get deviated from your bit of task until it is
finished successfully otherwise it can disturb your time lines.
5) At the end-of-the-day, send a status across, of the state of work.
6) Once your task has completed, inform and get your next task pro-actively from your boss.
6) More important is, you try to accustom to the time-line based delivery without fail.
Doing this all by yourself is going to be very difficult. If you take the principles on the agilemanifesto site you'll see that at least 6 of the items deal with groups of people and teams. You're going to need some buy-in from your co-workers and boss.
I'd start with your pair partner. Ask for a turn occasionally. You could try something like so, "lets see if I undersdand this, can I try to add the next feature point."
That being said, there's a good Ghandi quote, "Be the change you want to see in the world." There are a lot of actions you can take by yourself to raise the level of your game. Writing tests, getting a continuous build working, set achievable goals that have some basis in past experience, refactoring.
There are also tons of books that will be very helpful to someone getting started. There's probably someone at your site who would like to mentor you. If you show you're interested in continuing to learn someone would likely be able to help you. Talk to your boss too. If he wants something from you he should be able to at least point you in the direction of someone who could help.
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
Let's say that a developer is interested in learning Scrum, but nobody else on the team is interested. I realize that Scrum is made for teams, and the process would have to be modified to fit a single person.
Is there any benefit to be gained by the developer trying Scrum, even if the team doesn't? If so, how would the process be modified to suit the situation?
I think there's benefit to be gained by any method that helps you develop goals, tasks, keep on top of work and deliver something often.
Your individual work-products would gain the same advantages that teams gain with scrum:
You'd get something done every {Sprint Iteration Period Here}, something you can hand off and say "This is now ready".
Your estimation technique will start to improve with reflection and retrospectives
You'll start to plan your day and make commitments to yourself about getting things done, so again your estimation of your capacity will increase
Retrospectives will formalize improvement of your personal work process. You'll start actively improving, removing and adapting to suit you and your individual needs.
You wouldn't be able to rely on other team members to help out, which is a bit annoying, and you wouldn't have a product owner, Scrum master or a backlog to pick tasks from. You may not even be in a position to make decisions on what to work on next. But I think the formal discipline and reflection is helpful for all craft practitioners, at all levels, alone or in groups.
And who knows, you might even inspire your team to Scrum it up once they see what great results you're getting.
I would suggest that you use Extreme Programming instead, as that works better for one programming than a decidely team-based process.
Then you can get the benefits of being more agile, but if your team is not agile then you will have some issues due to the use of a different paradigm.
For me, the biggest key was getting buy-in from my supervisor. It can be tough to try and have some sort of Sprint only to have it interupted multiple times (Supposedly XP teams handle this better, but I don't think any developer does.). Also, don't forget to include either power users (they could be testers) or members of other departments that could be used as Product Owners. I like to sit with other users and do a type of paired programming (OK they don't code) where I can ask questions while coding and do quick demos to get feedback. This helps when I'm struggling to create specs because those requesting the app are having a hard time telling me what they want.
Even if it's just you in the daily stand-up, it can be scrum.
If you compare yesterday's planned with actual and define today's plans -- without talking to other people -- that's still a kind of daily stand-up.
I'd say that what you're doing probably is scrum if you're following the daily-sprint-release cycles; even if there aren't a any other people to talk to each morning.
G'day,
For the best thing to come out of learning Scrum is the concept of involving the customer early and often. That way there are no nasty "that's actually not what we wanted" moments when you deliver to the customer after six months hard work.
HTH
cheers,
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.
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.