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 11 years ago.
Improve this question
In the course of my career I've noticed that developers working on new functionality are, as a rule, more cheerful than these assigned to troubleshooting and fixing bugs.
Good tips on keeping business support a happy? Organising business support in the way that team's morale isn’t hurt?
If we start with the assumption that the reason for new function developers being happier is that they get to feel proactive or in control and the troubleshooters are reactive and pushed around by the users one answer comes to mind:
Create a model for those doing troubleshooting to fixes to generalise these from point fixes into broad, consistent fixes for a class of problem. This puts them in the situation of creating new code, even if not new functionality, and they get to think a problem through and anticipate and avoid problems rather than playing whack-a-mole.
In fast moving environments it may also be possible to rotate people through the job descriptions by have them follow their feature from new development into fix and realease and hopefully into version 2 of the feature.
Our organisation has a substantial amount of support work and we've got hit with this problem really hard. The motivation on support teams could dropping down exponentially over the time if you don't do it right.
The principles which worked for us were:
Choose the right people. Some people are happier doing new stuff. Some people are actually much more suited to a steady no-nonsense job. It means that you should have two teams - one for development and one for support. Developers only stay on a completed project until they pass their knowledge to the supporters.
Choose the right leader. Good organisation is make or break here. A good leader would help to organise good relationship with the product users and at the same time will care for his team.
Rotate. We try to keep the support people on the project for a period of less then 2 years and then move them to something new. This helps maintaining proper morale and ensure that their skills don't rust.
Relationship with the customer. Make sure that the support team know how valuable they are. The customers/users should occasionally visit the team or the team should go on-site to have a face-to-face session with the users (a friendly dinner or lunch will also help)
I have seen this too.
There are few approaches that I can think of:
1. Give some thought to selection process.
Not everyone have same career aspirations. While some people are always dying to work for the latest technology and challenging projects, there are others who are content at a stable work environment. Picking the person with right KSA (Knowledge, Skills, Attitude) is always central to good person-job match. In this case, you just need to put more stress on the Attitude part.
2. Choose the right lead
Team leads play crucial role in controlling the motivation and morale of the team. There must be an open and frank channel of communication with team lead and upper management. Ideally a person from the senior management should be made the owner of the team in formal organization chart. Team lead should actively try to foster a team-culture that suites the nature of the team.
3. Rewards
Rewards off course are key tool for managing motivational issues. Just make sure the person receiving the rewards understand that the nature of job was also taken into consideration in decision to reward. If this point is not addressed, it is likely that the person will not take this factor into account when perceiving internal equity.
Following Bell's suggestion, consider letting new or junior developers cut their teeth on fixes. Promote them from maintenance to the feature team based on their performance and ability.
Healthy competition is also a good motivator, but it must be managed to remain a positive influence.
Related
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 5 years ago.
Improve this question
How to move a team from waterfall development model to scrum model? What all are the steps that one need to follow to achieve a smooth transition. What would be the acceptance curve and will it be successful altogether?
First the team needs to want the change, and the business has to support it.
There isn't a set sequence of steps, and success can vary widely, as much depends on your particular situation.
I'd recommend getting Mike Cohn's book Succeeding with Agile, which gives some excellent advice for such a transition.
Though there are many ideas on how to implement scrum within an organization, starting with one team is certainly a consistent thread. So good work on starting that way. From there find someone with experience in implementing agile. A contractor, a colleague, or advice at meetup groups. Here's a link to one I have attended in the DC area - http://groups.google.com/group/dcnova-scrum-user-group
From there, my opinion is to adapt scrum to your team. It's size, it's need for adjustment, etc. Everyone has opinions, but if your team doesn't buy it, it's not worth it. Don't take that as a license to cut things from scrum. Keep the daily standups, the commitment, the retrospectives, the demo (etc), but adjust the size of the sprint, etc.
I recently saw a compelling presentation that advocated implementing pieces of scrum/agile as the team/business was ready. See this gentelman's site for details - http://www.dragile.com/
A big key is to not get lazy - do scrum. And have a high standard. If you're going to go it alone (which can be dangerous) - read your heart out. Read examples, talk to others, go to meetups, etc. Don't let your inexperience in scrum sour your team to it.
Another good link for an example of one team's experience implementing scrum.
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
In my experience with learning to manage a team using agile there are two critical components to making agile/scrum work. I think that Jody's point about not being lazy is really important, with the more free-flowing work pattern of agile it can be easy to succumb to skipping meetings or other such nonsense.
Get a good web based task tracker. This allows developers to login and see what they need to do and will help track progress. I've been very happy with Pivotal Tracker (www.pivotaltracker.com). Of course the tracker is only worthwhile if you actually keep it up to date, which leads me to point two.
Having meetings EVERY day. The daily standup discussed in the scrum and agile books is by far the most important aspect of the routine. Keep the meetings short, do it in the same place at the same time every day. Update the task tracker during this meeting and keep it organized.
Transitioning a team from waterfall can be difficult. Having everyone on the team read about scrum is important. Also, understand that not every aspect of the scrum model will work in your environment. Facilitate an open discussion about what aspects of the model you want to adopt as a team. The more input you get from the team the more buy-in you'll have.
How to move a team from waterfall development model to scrum model ?
Strategizing Phase:
Well, the first step off course is the thought for change. Then comes the buy-in from the Management, and the Product Development Teams.
Release Planning and Virtual Product Discovery:
Ideally, you would start by identifying all stakeholders and identifying all the requirements by using the Agile Release planning method - which is a really lean way of doing Release Planning. You would identify virtual products at this stage if not already identified.
Team Forming and Infrastructure:
Next step would be forming cross functional teams based on what virtual products need to be built. This step can be tough. It may require RE-organization. Cross functional teams mean there will be no requirements gathering team, or software development team, or QA team. You would have to pull a experienced lot of people from each department to form a cross functional team. A Scrum Master and a Product for each team will have to be appointed.
Basic infrastructure will need to be established for the cross functional teams to operate smoothly, without interruption.
Start Sprinting With Team(s):
Start following the Scrum/Agile principles and have them Sprint. Capture various artifacts and use them to inspect and adapt.
WALAH you are Agile!
What all are the steps that one need to follow to achieve a smooth transition. What would be the acceptance curve and will it be successful altogether?
Steps are mentioned above in order. Acceptance curve varies based on how well you execute the steps I mentioned above.
Lastly Yes, off course it will be successful. 100% guaranteed successful.
Kidding, I wish I could guarantee that, but I can't. :)
What I suggest is this - When you read my statement "Yes, off course it will be successful", the hope you might have got, just hold on to that hope and take that first step!
I happened to be a part of a team which was migrating from waterfall to scrum. If the teams large and distributed, I don't think its easy for everyone to migrate to scrum all at once as a change in organization takes certain amount of days/months/years.
Once such approach that you may like to try is Tracer Bullet, although this term is used more in agile world, but you can surely prove your point to get the buy-in and lead by example if you/your team is stuck in the middle of waterfall and scrum and are looking to go nowhere in quick time.
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 5 years ago.
Improve this question
I've been working on a CodeIgniter project with a friend of mine for almost a year now. We feel that our development process isn't as effective as we wanted to be, and currently we're not employing any software development methodologies. We're 2 man team, looking to have more people to work with us in the future, but we don't have enough people to start on scrum.
Right now, we're both working on this project on the side, would be nice to know which methodologies are best for us, to get our development going faster and more efficient.
Agile and Scrum won't make you faster or more efficient:
Since you tagged this with agile and scrum, I thought I'd mention this: neither agile nor Scrum has as its goal faster or more efficient development as you ask for in your question. In fact, changing to these approaches involves a significant learning curve, but if practiced well contributes toward very low defect rates, software that meets the customer's needs, and a development process that responds to changing requirements. Used long enough, Scrum can provide good data about roughly how much work a specific team can get done in a period of time.
Still, you might benefit from some practices:
All that said, there are a couple practices that may want to try:
Pair Programming and Test Driven Design (TDD)
Continuous Integration
TDD is not easy to learn, especially on your own. See if you can attend a CodeRetreat or similar event.
If you aren't already using a modern software change management tool (SCM) like Mercurial, git, or subversion, get one and learn how to use it.
Get regular feedback from "customer"
If you don't already know (you didn't say in your post), you might ask yourself who you are making the software for. Can you frequently and regularly demo it to that person and get feedback? Find out what they want next and put those items at the top of the backlog.
Try to make your product incrementally useful
Rather than making big product-wide changes, add small useful amounts of functionality. Your design will drift but if you have sufficient automated tests in place you can refactor as needed.
I'm curious why you say you don't have enough to do some form of scrum?
You're both on the team, one of you can own the process and the other or both of you can be the product owner. You do your daily scrum so you can know what each of you are doing - picking the work from the backlog you agreed to do. And as you add members you'll already have an established practice they can integrate into.
You can work in 2-4 week sprints, do sprint planning,review, and retrospective regardless of the number of members.
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 13 years ago.
Improve this question
Currently we are facing some problems with our Team Lead regarding work assignment hierarchy and responsibility of work done. It is generally seen if some targets are not met by the team the Team Lead openly starts blaming the team and sometimes pin-points some of the developers. Further during the allocation of work to the developers the Team Lead does not properly explains the work to be done but expects us to complete it completely.
The worst part is that the Project Manager and Team Lead are real cousins and the Project Manager always takes the Team Lead side when such issues are put up to him by the developers.
Please guide what best can be done by the developers to make a healthy work environment.
Thanks in advance.
This is double sided, and very objective. It might depend souly on what kind of person the Team Lead is, and if they are open for discussion/questions.
The team lead should be openly addressed about this, BUT also, if a developer is unsure about what to do they should ask.
It never hurts to ask questions, you will be amazed at what you can learn.
Well personal relationships should not not be related with professional life. The developers should first of all organize a meeting with team lead and put forward their issues in a healthy and explanatory way. Also keep in loop the Project Manager with your views. Do not wait for anybody to make a healthy environment for you... start yourself in this direction.
One should be able to adapt to various environments and culture that is different in different organization. Always be with the flow.
I'm not sure that you can avoid conflict! The challenge is deciding what to do so everyone can learn and not too many people get hurt.
A well-run team should run itself. That is to say, the team lead's role should be to get a good framework in place so the team can decide on priorities, techniques, methodologies and even process by talking together.
So good managers will ask team members "OK, so what would you do?" They'll then get the appropriate support put in place so that can happen.
I'd suggest that as a group you
Regularly get together (perhaps weekly) to review progress and learn from mistakes made in implementation.
Make sure that all tasks are given to the team as a whole, not to individual developers. Everyone should know the high-level summary of a job.
Get together daily to very quickly summarise progress. Keep this meeting limited to 10 minutes.
In these meetings it's best to avoid blaming people. Blame the code instead, or the process, but don't get personal.
And if your company culture allows it, try reading up on some of the literature around agile project management: there are many parts of that process that are designed to avoid conflict of this nature. However, it can be quite a hard shift for some organisations to devolve quite so much power to developers...
If possible, schedule a meeting with the Project Manager and Team Lead. Openly discuss the issues in a mature and positive light. Tell the Team Lead what you do like (as a group), and tell him what you think can be done to improve quality, expectations, deadlines, etc. If critical requirements are habitually missing, let him know that. Although his cousin is the Project Manager, his answers may be guarded and he could get defensive no matter what the real circumstances are.
Ultimately, in my opinion, the PM/TL relation is a formula for disaster. If the problem is the Team Lead, and the Project Manager is part of that problem, then the next logical step is to go to the PM's boss.
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 3 years ago.
Improve this question
I realize that this is a subjective question, so I've marked it as a community wiki. I think that it is pretty specific to programming teams, though, so I've posted it here as opposed to somewhere else.
I'm leading a small game development team (four people) as a side project. We are a disjoint team, with everyone in different places, but we do have some of the mainstays of an organized team.
Source Control
Continuous Integration
Bug Tracking
Document Workspace
Regular Meetings
Calendar / Schedule
How do you keep your small, disjoint teams on-track? I tend to agree with Joel's opinion about when and how to micromanage and know that my team is motivated, but it can be easy to fall off-course when everyone isn't connected in a physical way and doesn't see what other people on the team are doing. Suggestions, feedback, or criticisms are welcome!
Edit: I'm managing the team; I'm not looking for automated tools or anything to do my job for me, just ideas for approach or process that might help everyone feel more "connected" and involved.
You need a Team Leader with specific skills.
Motivator: You have to keep your team Motivated. This is really hard to do, and requires a special personality. Without this skill, small teams like yours are hopeless.
1a. Request thoughtful answers to a controversial question and then after 7 minutes accept one of few answers and go on to something else. This shows that you take the long view and is highly motivating to your contributors
Intelligence: For small projects like this, it's best if the Team Leader knows something about everything. If he knows something about everything, everyone is going to follow him.
Objective: Remaining objective is very key.
Organized: You have to be the most organized out of everyone, because when things get chaotic, people run. And I would say in small projects, this is the skill that most Team Leaders lack.
I have been part of several small projects. I would guess that 90% of them fail. I would say it's primarily due to the Team Leader lacking in certain skills.
BTW. Good Luck. I couldn't be a Team leader. :)
Be a Leader: How to Change People Without Giving Offense or Arousing Resentment from "How To Win Friends and Influence People":
Begin with praise and honest appreciation.
Call attention to other people's mistakes indirectly.
Talk about your own mistakes first.
Ask questions instead of directly giving orders.
Let the other person save face.
Praise every improvement.
Give them a fine reputation to live up to.
Encourage them by making their faults seem easy to correct.
Make the other person happy about doing what you suggest.
Those are my suggestions for some helpful tactics, even if they are rather old as the book was written in 1936.
This is an interesting article about that very topic: Gaming the System.
A manager. Someone has to keep track of where folks are at and how their progress fits in the scope and time-line of the entire project. There isn't really a good way to automate this. It must be done by a human.
Edit When I worked for a game industry company, we always had to meet certain milestones to get payments from the publisher. As the manager you can break down each persons tasks into milestones as well. This way you can track the progress of each developer without bothering those who are on track with their features. It also makes it easier for the developer to know what their deadlines are in nice bite size pieces. If they are consultants, you can even pay them upon meeting their milestones. Money is great motivator ;) Another great motivator is to make all milestones open to the whole team. So if one person falls behind, others can jump in and help her meet it.
I've worked in large and small game development teams for many years and I think the most important thing you can keep in mind to hit milestones and stay on track is discipline.
Game Development seems to suffer immensely from the desire to add more and more features or focus too much energy in something that's just not that much of the final experience. Your best tool for keeping the team on track is the word "No"
So far I've been on the development end of this equation, and by personal preference rejected attempts to place me in a managerial position. Techniques I have observed are:
Set very, perhaps impossibly short deadlines. Developers will be so rushed to achieve the goals that they won't have time for any distractions. They won't have time for refactoring, cleaning up code, indenting, code review or anything else either, but as long as their code compiles they can reach the milestone and worry about debugging it later.
Have a technical project lead so dedicated to the project he'll crack the whip on all others until they produce maximum (visible) output. Also, he'll work lots of overtime and encourage others to do the same.
Weekly meetings, all hands. Some of the information exchanged about what other folks are doing and what they've learned can actually be useful.
Provide standardized equipment, software and development environments. They may be awkward to work with and developers will hate it, but at least they won't end up playing with their configuration when they could be coding.
Have a business-savvy administrative project lead who can keep customers off the developers' backs and filter requirements for them. Anytime a customer "helps" it delays progress by many hours.
Daily standup meetings done properly help a whole lot. If you keep it to:
1 what did you do yesterday?
2 what are you doing today?
3 what problems are you having?
it should remain quick and helpful. Keep in mind #3 is just to state it not to solve it. That is done after the meeting and is facilitated by the development manager or project manager.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
There are numerous Agile software development methods. Which ones have you used in practice to deliver a successful project, and how did the method contribute to that success?
I've been involved with quite a few organisations which claimed to work in an 'agile' way, and their processed usually seemed to be base on XP (extreme programming), but none of them ever followed anywhere near all the practices.
That said, I can probably comment on a few of the XP practices
Unit testing seems to prove very useful if it's done from the start of a project, but it seems very difficult to come into an existing code-base and start trying to add unit tests. If you get the opportunity to start from scratch, test driven development is a real help.
Continuous integration seems to be a really good thing (or rather, the lack of it is really bad). That said, the organisations I've seen have usually been so small as to make any other approach seem foolish.
User story cards are nice in that it's great to have a physical object to throw around for prioritisation, but they're not nearly detailed enough unless your developer really knows the domain, or you've got an onsite customer (which I've never actually seen).
Standup meetings tend to be really useful for new team members to get to know everyone, and what they work on. The old hands very quickly slack off, and just say things like 'I'm still working on X', which they've been doing for the past week - It takes a strong leader to force them to delve into details.
Refactoring is now a really misused term, but when you've got sufficient unit tests, it's really useful to conceptually separate the activity of 'changing the design of the existing code without changing the functionality' from 'adding new functionality'
Scrum because it shows where the slackers are. It also identifies much faster that the business unit usually doesn't have a clue what they really want delivered
Scrum.
The daily standup meeting is a great way to make sure things stay on track and progress is being made. I also think it's key to get the product/market folks involved in the process in a real, meaningful way. It'll create a more collaborative environment and removes a lot of the adversarial garbage that comes up when the product team and the dev teams are separate "silos".
Having regular retrospectives is a great way to help a team become more effective/agile.
More than adhering to a specific flavor of Agile this practice can help a team identify what is working well and adapt to a changing environment.
Just make sure the person running the retrospective knows what he/she is doing otherwise it can degenerate into a complaining session.
There are a number of exercises you can take a team through to help them reflect and extract value from the retrospective. I suggest listening to the interview with Linda Rising on Software Engineering Radio for a good introduction.
Do a Google search for "Heartbeat retrospectives" for more information.
I've been working with a team using XP and Scrum practices sprinkled with some lean. It's been very productive.
Daily Standup- helps us keep complete track of what and where everyone is working on.
Pair Programming- has improved our code base and helped remove "silly" bugs being introduced into the system.
iterative development- using 1 week iterations has helped up improve our velocity by setting more direct goals which has also helped us size requirements
TDD- has helped me change my way of programming, now I don't write any code that doesn't fix a broken test and I don't write any test that doesn't have a clearly defined requirement. We've also been using executable requirements which has really helped devs and BAs reach requirements understandings.
kanban boards- show in real time where we are. We have one for the Milestone as well as the current iteration. At a glance you can see what is left to do and what's being done and what's done and accepted. If you don't report in your daily standup something pertaining to what's on the board you have explaining to do.
co-located team- everyone is up to speed and on page with what everyone else is doing. communication is just-in-time, very productive, I don't miss my cube at all.