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 need a methodology to organize my team for a university assignment.
I am a university student and already have some programming experience. My experience of working in teams of more then 2 people on a relatively large project is that everything usually gets done very quickly and badly in last week or so because of planning, organization and communication issues. In January I will have to do a (quite challenging for my skill) programming project (Java application on Oracle) in a team of 6. I already know my team members and was elected the project leader. It won't be realistic to expect people to get together for any meaningful-sized amount of time - everyone is free at different time and probably nothing more then weekly 1-hour meetings is realistic. People are hard-working and devoted to success, but everyone has their own circumstances. Mostly distributed work is the likely way to go.
I've looked through XP, Scrum, but they all require to sit together (unlikely), aimed at full-time development of a project (people have other assignments and part-time jobs) and customer involvement (we will have written specs and as far as experience goes, emails from tutor will be answered at best in 2-3 days).
Any suggestions how to organize people and divide the work? I am serious on researching this topic, because there will be much more of this kind of works later on.
Any help appreciated.
While not a programming project, I am currently in a position similar to you - elected group leader in a 5-person group assignment. We will be finished two weeks early, so I would say that the group has been a success. A few things that I did, as group leader, to ensure that this happened (I am also drawing on experience of managing projects in a 'real world' situation, so perhaps have a little more advantage):
Set ground rules from the offset. Make sure that everyone knows what is expected of them: Meeting attendance, work deadlines, what to do if they are struggling. We have a system at our university where people can be removed from groups if they are not 'pulling their weight.' If your uni has a similar thing, the steps taken for you to initiate that procedure should also be outlined. For example, miss two meetings and you will be 'yellow carded'. Miss another, then it's a 'red card'.
Break the assignment into manageable chunks and then decide on a time line. If you already know what should be done each week, it will be much easier to assign tasks each week. Or, of course, whatever time frame you decide on.
Meetings. There should be an initial meeting where everything above is decided on, probably a rather long meeting (our first meeting took 90 minutes). In that meeting, set out tasks to be completed before the next meeting. Then, in each subsequent meeting, validate the work that has been done by each person, ensuring it is both complete and correct. And then, of course, delegate tasks to be completed for the next meeting. And so on...
Each person, pair, or whatever, should go away and do the work themselves, independently. Because meeting times are so short (as were ours), they should be about making sure everything is completed, plans are made and tasks are delegated.
Communication. I set up a forum for the members of my group to communicate about the work they are doing and to upload completed material. I also have a specific sub-forum where people can post up any problems they might have - with a rule that they should do so within plenty of time of the next meeting - so that others can help, or tasks can be re-assigned. It's important that each meeting has minutes taken and an agenda set for the next meeting. I get these uploaded to the forum so that anyone who did miss a meeting isn't left in the dark and know exactly what they need to do.
Because your project is a programming project, the following may well help the group stay organised and cohesive:
Early on - preferably in the first meeting - break your program into 'modules' or classes/procedures/whatever; basically, manageable, stand-alone chunks of code to be written. These can then be assigned to someone each week. To make sure that time won't be wasted on changing code needlessly later on, decide on your global variables, if any. It might be a good idea to also decide on the methods and properties of each class before any coding starts.
As sgolodetz suggested, you might also want to use version control to keep track of code as it's being written. Again, if you do this, make sure that rules/guidelines are in place for when/how often to update.
Perhaps arrange that people working on related tasks meet up between meetings to make sure their code integrates well. This way, they can work together to make sure each person's code 'cooperates' with the other's.
I think the key here is to be organised. Have a strict, detailed plan and stick to it as much as possible.
In university, at least, I think it's important to have a certain amount of ruthlessness - remember that if people don't pull their weight it will affect your grade as well. It might just be me, but once the rules are set, they should be abided by and breaking them (ie: Not completing work or not letting people know you're struggling, not turning up for meetings, etc) should always result in the 'card' system - as would have been agreed at the start. It's your future on the line, so don't let people who don't care jeopardise that.
I was one of the leaders of a team project (6 people) last year at university. Based on my experience, I have a couple of key points.
While forums, online chat, email, SVN commit messages etc. are all very good communication mechanisms (and I do recommend them), nothing is more important than weekly meetings. These should involve delegating/discussing/monitoring tasks, talking about general issues and the bigger picture, making group decisions, and simply using your app and identifying issues with it as a group. By doing this, it becomes instantly obvious where people are at with their tasks, where they might be confused, and whether they understand what needs to be done. This is crucial because the feeling of being 'lost' and having no idea where to start is often the biggest obstacle to making progress, rather than laziness. And besides, group decisions are best made in person where you can bounce ideas off each other... and this all helps to establish a sense of shared ownership.
There is no one best way to formulate, delegate and monitor tasks. But it is important that you can divide and parallelise (as much as possible) the workload into sensibly sized tasks and identify dependencies between them. Our group maintained a TODO file in our repository which consisted of a list of tasks, dates, and bugs. We prioritised tasks according to factors such as whether they were mandatory requirements or optional niceties (think MoSCoW), whether they were on the critical path, how much risk/uncertainty was attached to them etc. We allocated one or two people to most tasks based on their strengths and whether they actually wanted to do the task, but we also left some tasks open to whoever wanted them (this is potentially dangerous too). A couple of us stronger programmers also played 'floating roles' meaning we could help out with any task. A key point is that the task descriptions should contain anything discussed in the meeting... the what, the why and a couple of 'how' sentences as a kickstart (i.e. "to accomplish this, you might want to read up on blablabla")... anything which makes it easy for your teammates to slip into a task.
A few thoughts:
Communication - perhaps use IRC or a wiki
Assigning people to tasks - you need to figure out where people's strengths and weaknesses lie, break down the project into chunks and assign them accordingly
Monitoring - a big problem with projects where people are working remotely is that they may not do the work on time; you need to think about how to keep on top of this (e.g. use version control, and look at the check-ins) - to make this work, everyone needs to buy into it up-front
Strategic reserve - it might be worth having one person (perhaps you if you're the strongest programmer) who takes on tasks across the project that other people are finding difficult to prevent people getting bogged down
First, set up a version control system for the project. This serves the purpose of the code that has been checked in is available to all the team, you can revert to earlier versions if someone breaks something, and all decent professional shops use source control, so it is a job skill it is good to be in the habit of using.
Now you have a way to check on progress. If Joe hasn't cheked anything in, you know he is not doing the work. IF Sally quits in mid_term, you have a record of everything she already did.
Another thing you want to so is code review. Everybody's code gets reviewed by one or more other people. You will all learn a lot from this and this too is a necessary skill for the professional developer.
Plan what has to be done in what order. Make sure the people developing the stuff that everything else depends on are the most reliable devs on your team and that they will meet their early deadlines or nobody else will be able to do their parts.
Weekly progress meetings and don't be afraid to call someone out for not doing his or her part. The sooner you identify a person not pulling his weight, the sooner you can address the issue.
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
How to deal with a project manager that imposes really tight deadlines but with a day or so before the deadline brings in new features and spec changes to implement, with another tight deadline.
The worst thing about this is that most of the new stuff leads to major rewriting of the existing code, as previously implemented business rules are no longer applicable or "gain" strange corner cases that need to be treated separately.
It seems that no matter how hard we try to make the system extensible, there always are things that come up literally in the last moment and need to be implemented and supported quickly.
How could I deal with such a situation? It's being really demoralizing and one colleague has already quit the team.
It's true that no matter what you do, you're human and you'll make mistakes or miss things. That said, regular changes to your requirements are most often the result of either poor requirements or poor develoment process, or both.
Some Design Up Front?
Business analysis is regularly given the short shrift by developers, project managers, etc. Most devs just want to start hacking away on day 1, and most PMs love to let them: "Wow, we can move from the project initiation phase to the construction phase in 1 day without any of that ridiculous business analysis stuff taking up time! That'll look great for completion bonuses!" But remember that the PM's primary job is to keep the project under control (on time and on budget) ...not necessarily to make users happy and certainly not to make developers happy. That's not to say they are totally heartless; good PMs will achieve their goals by enforcing scope control and fostering communication, both of which are helpful.
But taking the time to really think about what's needed and stepping through possible scenarios can make a serious difference in the issues you're dealing with.
If you have made an effort to do thorough business analysis and you're still ending up with last minute changes, then perhaps your problem is another classic challenge: disengaged users. Your subject matter experts are your top weapon in dealing with and identifying those corner cases. If you have users that are not engaged in the analysis process, get better subject matter experts.
It's also possible users are disengaged because they are too busy doing their regular work. In that case it's a management issue and they need to be given instructions that project participation is part of their jobs; that's hard sometimes because often the same management that told you to "get it done yesterday" is the same group of knuckleheads that is expecting the project to happen magically with no hiccups and without any resources (they are common in that they don't understand the complexities of custom software development and assume it is easy). If management is clueless and won't change...well, you have to either work overtime and deal with the issues you've described, or get a new job.
Can Agile Help?
It'd sure be nice if your users would tell you about those corner cases earlier rather than later, right? This is related to what Toby Hede discussed in his post. Perhaps a methodology that gets the software in front of the users as soon as possible, even in an unpolished state, can trigger feedback sooner. That was one of the inspirations for all the agile concepts. The creators were tired of dealing with the issues you describe and they also realized that if management and users weren't going to change, then maybe the development could. It's still development, but there's an emphasis on getting early feedback through a variety of techniques (have subject matter experts co-located with the dev team, getting rough prototypes into user hands sooner, pair programming to captalize on developer experience, and lots more). All this is because it's understood we're human and we're going to miss things.
Finally, you mention you're trying to make the system extensible to help with the rapid changes, but how? Are you separating presentation logic from business logic? Are you encapsulating business logic in objects, partitioned appropriately to minimize dependencies and coupling? All of those things are tough to do and can take time to plan and build.
You're not alone, by the way. Lots (maybe all) shops have these challenges.
Don't let them impose the deadline in the first place.
You have 2 options
The PM gives you a list of features and you tell them when it'll be ready.
The PM gives you a list of features and a deadline. You then tell them which features you'll implement in the given time.
If the PM is your manager or has the authority to impose deadlines + number of features, then I'd be looking for a new job. careers.stackoverflow.com
If the PM isn't your manager then you need to get your manager on board and have them give the PM their options from the above list.
This stuff is really challenging to deal with. The real problem here is that you don't actualy have a process.
The answer really depends on the political situation in your organisation and how much eneergy you have to drive change.
In the past I have attempted to introduce process change to several organisations and it has always been a struggle. It is possible, however.
I would have a look around at some methodologies for managing software development. I use and recommend Scrum, for example.
In a situation with rapid change, working on short iterations that have clearly accountable goals can be really helpful. You will probably need to champion and manage your Project Manager, but it sounds like the current "process" is clearly not working, so selling a new process actually becomes easier - you have solid business case for improvement.
A solid process will help you "push-back" on changing requirements. Rapid reactionary change is often a symptom of broader issues in organisational direction and strategy and it is in everyone's interest to fix this problem within the organisation.
This is one of the major challenges you will face as a developer.
One good technique I've used in the past is to ask questions. When you get the specs, find something in them which needs clarification from the final users. This always slows things down, and raises the possibility in managers minds of risks.
Make sure that your project manager knows the risks involved in implementing late changes for a project.
Have you and your team tried discussing about this with the manager himself? That's the first thing you should do.
He might not have that much experience with the development process, hence the constant tight deadlines and very late major changes. I've seen such cases, people who couldn't develop but thought they could do a better job at PM.
From sitting and talking to him there could come out two thing, depending on his personality/professionalism. He'd accept your points and try change the situation for the future or he'll be a smartboy and won't give in a bit, in which case it is worth escalating the situation to a higher level. I don't think there is any company that will happily accept losing developers.
Alternatively, his manager could be all over him. And that's a problem.
If nothing works out, as already suggested, changing the job is a fair thing to do.
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 2 years ago.
Improve this question
Lately I've been feeling like I'm being pulled in different directions. In my company there are a lot of forces demanding my time and I'm having a hard time deciding which direction to focus my energies.
I have the choice of several different coding projects, some of which could demand a lot more work over time, and present unknown challenges.
How do you decide what to work on next in the big picture? Grease the squeakier wheels? Low hanging fruit? (translation: easier projects)
Do you have a system for determining and reaching your goals?
We've used a value graph to identify projects based on value vs. effort, as a part of lean.
A few of the things I ask that affect what I work on :
Are any of my tasks holding up other developers or keeping other people from being able to do their work? If so, it'll probably get done first.
Do I have any tasks with deadlines coming up? If so, it might be the next candidate to work on, unless I can justify something else being worth the task slipping schedule.
Will work on any of the tasks affect (make obsolete / make easier / make more difficult) any of the other tasks I have? If so, it might get moved up.
Is there a good chance that any of the tasks will change (requirements still not concrete / other tasks out there that might affect it), making time spent on it now likely wasted? If so, it gets moved down.
Are there any things that just really bug me, that I think I can get done before anyone notices that I'm not working on whatever my boss thinks is the highest priority. (which is justified because it'll distract me from thinking about the other things).
Are there any tasks I should work on while things are still fresh in my mind?
... other than that, we go with a combination of whatever sort of fixed deadlines I have, what tasks I have that might be holding up other people, what the boss wants first (I like this boss, and I only have one giving me tasks ... in the past, I'd've answered differently), which ones seem more interesting, which ones I can get done quickly to just get them off the list, etc.
There have been times when I've had more than one manager, and I just had to put everything on a list on a whiteboard, and told them to number them (17 items, which kept growing). Management balked, but I was sick of getting bitched out at meetings week after week with stuff not being done, and having to go through the list of every 'emergency' task I was given. (and being told that any manager in the department was allowed to task me in the case of an emergency ... which was something like 30 people ... and being bitched at when I asked who got to decide if it was an emergency or not.)
When I have the choice: whatever seems to be the biggest challenge with the most fun attached.
Fun + challenge = rapid learning, to me.
And sometimes that takes me away from the technical stuff - people can be a fun challenge too.
I tend to weigh 4 items based on things when deciding what to work on next:
Is this item a requirement for something else?
Can I work on this item yet (ie, am I waiting on something for it)?
How fast/easily can I get this item done?
How interesting do I find the work required for this item?
I my current team (working on a variety of Business Intelligence software projects), we've recently started adopting a variant of classical "agile" project planning and estimating -- everybody seems to be pretty happy with it so far, including us (developers of different levels of experience), the product managers (highly technical people, typically also with some development experience, but mostly interested in the business side of things), management (pretty technical at the level we report to, but also less-technical, more-businessy directors and VPs), and other stakeholders (users and would-be users of our software). But, of course, it is early times, and we'll adjust as we go along. (In the past few years I used other variants of this in very different application areas, such as cluster management software; but I've often also used more ad-hoc, less-structured approaches).
The outline is as follows. At each iteration (we're currently on 2-week iteration cycles), the PMs choose some "elementary units of business value" that they might like to get from projects in our area -- a typical unit would be one feature, a bug fix, some optimization aspect, etc. In a small meeting with tech leads and one or two senior engineers, each unit is decomposed into engineering tasks (and dependencies among tasks are identified). In a larger whole-team meeting, the relative "cost" of each task (how much time, roughly, it will take to perform that task relative to other tasks) is collectively assessed (we're using completely abstract units of effort we call "points", though I've seen other teams use less abstract units such as "ideal engineering-days"). The costs assessed include unit testing and technical documentation.
The tasks, each with its assessed cost, go on what's called "the backlog" for the team, together with "internal restructuring" tasks (typically refactorings that will deliver no new user-observable plus, but will make further development and maintenance more productive), also with assessed costs and a summary of expected benefits (which must be expressed in ways understandable to the PMs -- fortunately, as I said, ours are highly technical people). A refactoring may also, by engineering team consensus, be deemed a prerequisite of certain business-requested tasks (e.g. "makes no sense to work further on component X until class Y, too large, is properly split, which will take N points").
The PMs now get to order the tasks in the backlog in any way they prefer, based on the business value that completing the units those tasks make up would deliver, subject to the dependency constraints. They have a good idea of roughly how many "points" the team may accomplish in a 2-week iteration (our "velocity") based on past results, so they try to make sure some business-valuable release can be performed at the end of the iteration (as opposed to having many business-valuable thingies "in flight"... but none completed and deliverable to stakeholders yet!-).
The team then devotes about 80% of its time and effort to tackling the top-priority tasks as designed by the PMs (including pair programming some of the time, for particularly urgent tasks or for situations where one team member needs to learn more about some technology or some part of the codebase, and another team member who's an expert in those is available for pairing up with them for a while). The priority order is an important indication, but it's not entirey rigid (e.g. if the top task requires extensive work in Java, and the second one requires it in Python, I may well pick the second one, as my relative productivity will be enormously higher that way -- and vice versa for a team member who's a Java guru, etc etc).
"Priority 0" aka "Code Red" issues may arise at any time, and, if they do, by definition they will take priority over any other task (and be accounted for only retroactively in the planning, to make sure velocity is assessed properly). But, as we do a pretty good job with testing, release engineering, and other quality-assurance practices, those emergencies are fortunately few and far between.
This, plus other "mandatory" ways for engineers to spend their time (training courses, all-hands meetings, quarterly performance self-evaluations and peer reviews, etc), is supposed to account for about 80% of engineers' time -- the remaining 20% being time each engineer should devote to "something completely different" ("blue-sky" exploratory projects, "egineering community" efforts, open-source contributions, etc, etc), not directly related to the projects at hand. Nobody actually measures the hours precisely, but that's still a useful guideline (I keep thinking of ways to make measurement easy and painless that I could implement in my 20% time, to help me allocate time and effort more precisely, but I haven't actually gotten any round tuits yet;-).
Easy. I ask my boss.
High value + Low risk.
Only go on high value + something with higher risk if you already have a track record in the company / credibility.
Easy: What is the highest and best use of my time.
If I am involved in a project and that isn't the answer to that question, I ask myself why I'm working on it and how soon can I finish it.
:) On Job i left this decision n my Project Leader and Team Leader, As they know better
"What is project priority"
At home, i do where i see fun, learning and challenge
When I have a choice about which job to start next I try to find a balance between two things: quick, easy fixes that are highly visible (e.g. fix the non-critical bug that a user has been complaining about) and taking on a project where I can use something I've been learning about. I find if I alternate between those types of jobs I can keep myself and my co-workers happy.
I'd look at what has the highest priority from management's perspective for an intial prioritizing of upcoming projects. If they are all priority 1 projects, then there are a few other factors that may help my decision:
Do I see how valuable the project will be to the organization? Is this the type of thing that really helps with the competitive advantage that we have?
Does there seem to be a buildup of projects of a specific size? For example, are lots of little projects being ignored for the few really big ones? If so, I may take some of the little ones that may be seen as quick wins that may help my team look good.
Do any of these projects use my strengths? This can be a bit hard to determine but it could help a lot with motivation, at least using the Marcus Buckingham interpretation of a strength.
What teams and structures are in place for the other projects? I don't think I'd want to join a project that looks like a massive train wreck about to happen. Is there enough structure so that I won't go off and do my own thing that may hurt the project's chances of success? Do I believe I could handle working with X using methodology Y and technology Z?
Those are a few of how I'd look at making the decision, along with talking to my manager as part of this is his job, right?
You should ask yourself a question. Are you pursuing a general IT career path which may or may not include your current company, or, do you intend to have a long career with your current employer?
If you intend to have a succesful IT career moving around differnet employers then, sadly, the most succesful strategy is "buzzword collecting". Identify the current/next big thing and try to get it on your CV. e.g. FInd a trivial AJAX with SOA back end project which may never go to production, this will enhance your value to future employers even if the project had little value to your current temployer.
If you plan on a long career with your current employer, the most succesful strategey would be to align your goals with the business. For instance the most critical project for the business may be upgrading an old unsexy VB/Oracle stock control package to include an ancient EDIFACT interface with a new supplier. If you are seen as a key player in the success of such a project you will rank very highly (and rightly so) in your employers esteem, and your opinions and advice will be taken seriously.
Since you didn't specify whether you talk from developer or manager perspective, I'll try to cover both.
Providing a framework for prioritisation of efforts is a management’s direct job. The immediate day-to-day prioritisation may stay with management or be handed over to developers.
The decision who should work on what and when in average company is likely to be perceived as a matter of power, control and prestige by both groups and one who makes the most prioritisation decisions as clearly more important player.
In shrewd companies, however, it is well understood that decisions have several interesting properties:
Each takes time and effort to make, which is diverted from doing the actual work.
Every decision is a trade off
To make a good trade off one who makes the decision needs all the right information in her or his disposal
Subsequently, management doesn’t have all the information to make every decision and nor they likely to have right information to make a good trade off in each case, but developers cannot spend their time doing hundreds of prioritisation decisions per day instead of producing software, nor do all necessary co-ordination.
Hence the solution is for management to create a simple framework for task assessment and prioritisation and hand it to developers who will quickly apply it on case by case basis, filling the gaps. In management lingo such framework is called strategy; it saves time by removing repetitive redundant decision making, gives focus and consistency to the efforts, and provides direction. It should be detailed enough to remove the burden of re-assessing the situation each time, but loose enough to allow developers to make right choices when it matters.
The framework itself may give very straightforward rules for making decisions or, alternatively, provide some analytical methods such as Pareto, SWOT, Cost Benefit, Expected Return analysis or Porter Five Forces etc. However, it is worth keeping the rules simple, unambiguous and as straightforward as possible.
Joel Spolsky made available to the world several very good internal software strategy documents written in plain English. Not all documents are directly to do with developing software (showing that it viable actually to have a different unrelated decision frameworks for various aspects of the company life). Also since the documents are several years apart it’s actually possible to see how these frameworks kept changing to suit the situation:
Fog Creek Compensation
Our .NET Strategy
Set Your Priorities
Fruity treats, customization, and supersonics: FogBugz 7 is here
If you're intrested in choosing what things to work on from a personal point of view one of the best advices around in my opinion is the one given by Paul Graham in his essay "What You'll Wish You'd Known".
Fundamentally as software developers we are business enablers. Your priorities should be in tandem with business priorities and be pragmatic between quick wins and larger strategic initiatives. Effort and Priority make an excellent matrix in which to score projects taking the least effort/highest priority first.
From the tone of your question it sounds like business priorities are either unclear or there is conflicting direction between stakeholders. This is the place to start and it will make your decisions much easier once it is resolved.
You really need to discuss this with the business because only they can tell you what has the highest value to them. After that, I would go after the items that carry the most risk because if something is going to cause a schedule to slip it's best to know early rather than late.
If you're having trouble with what the business priorities - usually caused by being on multiple projects with different stakeholders who all think that their project is the most important - you can try getting both stakeholders in a room to discuss which project is higher priority. Or you could delegate that negotiation to your manager as that is actually his job.
I tend to work on multiple projects at one time, so I will work on a harder project, make some headway, and when I get stuck and need to think about how to do the next part, I will go to some low-hanging fruit, so that I can continue to make headway, as I give my subconscious time to work on the harder problem.
But, it really depends on your priorities. I have never been good at just trying to impress people, so I just quietly go about trying to get work done.
If we're talking in a work environment, i go through and just prioritise things - what is mission critical, what is urgent, and then anything else just gets put into the list and it gets done in the order it comes in.
As for picking the next big project at work, i like to do what offers the greatest challenge. I had been working as a developer for a year and i had the opportunity to do some work for a very large company working with some security experts and doing things i'd never done. So i chose that, and it looks great on my resume.
In terms of personal development work (not as in self help), again i'll offer something that challenges me. It's got to be something that i haven't done before. It doesn't matter if someone else has done it - i haven't, and i can learn from that.
In the end, it all comes down to what value it holds for you, and what value it holds for the client. Luckily, i've got a few years of sales experience under my belt as well, so i can easily sell the products i need to to clients.
If your problem is one of procrastination, then perhaps you need to focus on getting rid of those jobs that you fear tackling most - or at least making some forward progress on them to reduce the stress of considering how far behind you are.
This book, by Mark Forster, provides some good tips.
Failing that, you might want to produce an iteration plan. Let everyone vote for jobs - whatever gets the most gets scheduled right away. that way every stakeholder, including yourself gets some input into scheduling.
I would ask the boss, if they wont make the decision then I would go for the project which I felt was going to be best for the company, in profit and moral of the team.
If I was torn between too projects i would go for the one that sounds like I can develop my skills more and be interested in most.
If a project sounds exciting I become more driven and determined too :)
Given the nature of your question, I'm assuming this is all work that somebody thinks you should be doing, but there clearly isn't enough time to do it all. Therefore, you are just looking for priority knowing full well that some items are likely not to get done.
Impact/Risk if the item isn't done.
Visibility - Does anybody else really care about this task
Alignment with department goals - weed out things that really aren't your job
Alignment with company goals - weed out things that aren't important to your company's business.
Enjoyment factor
Alignment with career goals - Many people would rank this item significantly higher. Depends how important your career is versus what you do today. I've rank today's enjoyment a bit higher than long term career goals. Some projects may be horrible, but they can move along your career.
I guess it depends on how much is on the list. If there's a lot of low hanging fruit that's been on the list for a while, it may be worth while to take some time and clean some of it off. That way, there would be less demands on the available time and potentially more time or incentive available to work on the big projects.
Plus it can be cathartic to be able to cross a bunch of stuff off the list.
I will usually start working on a larger project first. Then when I feel I need to step away from it for a bit, usually so I can approach it with a clear mind later, I try to kick out some of the quick one-off tasks or simple projects.
I know that isn't very descriptive, but calling the occasional audible for distraction seems to work out well for me when tackling a big project list.
I tend to look at project from a learner prospective. I tend to choose a project that will help me learn something new, I also look for "cool" and intersting as well.
On tthe other hand you can choose your next project according to where it would lead you. Ask yourself if you have a career goal that project X will help you achieve. Perhaps a high profile project is better then intersting - at least for a short while.
One way to defide is to define several key pints that matter to you (i.e. new technology, intersting etc.) and try to rate each opportunity and see which gets the higher score.
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 3 years ago.
Improve this question
I am a reasonably experienced C# developer (about 5 year experience) that has recently been put in charge of my first development team as technical lead (varying between 3-5 other developers). Over the last 4 months in this role, one dilemma that keeps arising is trying to find the right degree of sharing awareness of the communication that goes on between the project manager, account manager, clients, designers, CEO and myself (especially via emails).
On the one hand, I know the more awareness each developer has of the overall direction of the project, the better they can understand the scope that their particular functionality has in the big picture.
However on the other hand, a lot of my time seems to be lost in the sea of emails between all the different stakeholders and managers, so I like to think that isolating the developers to just "what they need to do their current bit of work" will keep them free from interruptions.
I have considered just BCCing all the developers so they can filter these emails and essentially "opt in" to all the emails, but I'm concerned that some of the developers will just see this as extra noise to deal with. It may open the door to "too many cooks" if all the developers want to contribute to too many discussions. Yet on the other hand, other opinions can help me reach better decisions (i.e. House MD style).
Phew... so much to consider. Anyone have some wise guidance in this area?
Answering late, but still believe there is something to add to the superb advice given so far. To answer your question we need to go a level higher, hence the long response.
You’ve been made a tech lead responsible for team and although many aspects of your everyday job might seem to resemble your dev days the way you need to go about them has changed. In software development environment there is usually not that much of a tangible change when you appointed a tech lead (you’re probably still seating at the same desk, wearing the same outfit) as opposed to becoming a foreman on construction site or a factory. The flattering change though is that you now get invited into all these meeting and start getting all these e-mails and phone calls from people outside the dev team.
The lack of tangible change might trick your mind into thinking that you just need to keep treating your job mostly the same. This is not the case and you need to be conscious about your actions and re-actions in the new capacity. It might seem you’re now a bit “more respected” externally and you might be inclined to share some of that “respect” coming your way internally, play a bit of democracy and generally be fair.
Well, this is not that much about fairness or respect, the new job is to:
Direct the dev team (mostly by personal example and creating imagery depicting the goal).
Be an abstraction layer between the team and other organisational units.
Pretty much like in programming you often create an abstraction layer to encapsulate and hide complexity, the same happens in organisations. You’re the layer, the interface that has to encapsulate the dev team. And any good encapsulation from an outsider point of view:
Hides inner complexity that is not relevant to the task at hand (such as concrete implementation of an algorithm) from the outside observer.
Makes things that could affect the outside user explicit (exceptions that can be thrown, any limitations and constraints etc).
Always gives meaningful feedback.
Acts consistently.
These principles are equally applicable to the team’s outward communication. It’s not an easy task to follow these principles; actually it involves a lot of concrete work, such as deciding what details are internal and what facts need to be communicated and when, how the feedback needs to be best structured and be presented in a consistent manner and who should be notified externally of what, and who needs to followed up and when. This is a lot of work, even if some of it seems to be just trivial admin.
Now to internal, inward communication. One way is to broadcast. But it clogs the internal network and everyone has to spend their time on deciding whether the communication bears any relevance to them. It is like having a very generic algorithm that regardless of input always does the exact same amount of work. It’s sure possible, but why would you want to do that? A more efficient way is obviously to adjust processing depending on the input and here it has to be someone’s job to make a decision how the team should go about something, to dispatch, or convert the input:
Decide what sequence of actions needs to be taken,
or just acknowledge and store for future reference,
or follow up,
or put an issue off for a later review and then make sure it is reviewed and fed back into the decision-making loop.
This is not a small job either and someone has to do it. Obviously now it’s your job to manage the outward and inward communication, and you have to spend some of your brain’s processing power to do it well, so no one else has to and devs can concentrate on their tasks.
There are some other good reasons for not CC-ing or BCC-ing everyone regardless of your job title:
TO means “take action”, CC — “take note for future reference”, BCC — “eavesdrop or mass mail”. You should be careful when you use one or another e-mailing a group of people:
E-mailing a single person is a straight forward “TO”, when E-mailing a group of people only “TO” these who you need to take action (including a simple acknowledgement). This is default meaning, in any other case explicitly tell them what is expected (i.e. FYI, no action needed etc).
CC only these who you want to take note of the information for the future reference. If you expect a number of e-mails to go back and forth before an agreement is reached or issue is resolved don’t “CC”, it’s best to send a summary confirmation later to other parties that need to be notified. Besides saving everyone’s time and avoiding misinterpretation due to someone taking note of a non-final communication that will help make exchange more personal, flow more naturally, and reduce formalism and red-tape. Often CC-d e-mails treated formally and this isn’t always a good thing (but sometimes exactly what you want).
Using BCC is almost never ok. The knowledge of someone eavesdropping on your conversations if come to light will easily ruin your trustworthiness. It is simply a question of “when”. And should your team worry then that you might be BCC-ing their conversations to someone else? Mass mailing through BCC in most cases is also wrong, it creates an impression that e-mail is specifically addressed to the recipient.
Forwarding, CC-ing and BCC-ing require little effort, but multiply noise and dilutes signal. It is worth to give some thought to what exactly you need a person to do and what they should know to act on your communication before composing it.
Some conversations are best taken completely "off line" (phone or better still face-to-face), because it gives you more room for maneveour. Broadcasting or formalising in writting is just like putting yourself into a corner. You can always confirm in writing latter.
Moving to the second part of a tech lead responsibility (directing the team through personal example and imagery depicting the goal). To accomplish that you don’t need to pass on to the team every single piece of information that happen to end in your inbox. You have to create a story and any good story is an abstraction of real events that consists of only relevant and interesting detail for a particular audience. Creating this brief story on the basis of your everyday experience and judging what is relevant and interesting and then presenting it regularly to the team is also quite a job.
But don't forget that by directing the team and serving as abstraction layer you help developers and outside world to interact more efficiently, accomplish more and tackle greater complexity, the job has a point.
The engineering team needs to understand the business reasons of why they are asked to do things on a macro-level. The engineering team will gain understanding and motivation from this. But too much chatter is a no-no, as you note, part of your job is to filter, and part of that means not exposing them to tons of noise. Your developers likely have opinions and insights as to how to do particular things or why to pick particular technologies, and they should be fielded for their expertise in those areas.
Definitely don't create a culture of BCCing.
One option is to have separate mailing lists that interested parties can subscribe to, but of course, not all chatter will be on those lists.
And of course, a regular company meeting is a must. Let the engineering guys know why the business depends on delivery of a stable, complete product (or whatever the upcoming milestones require). 20 minutes, no slides, no bullshit is what works for me. Your team & situation may vary.
It sounds like you're technical so I would give you this advice: Follow Joel Spolsky's advice on what Program Managers do. Basically, try to isolate your developers as much as possible so they can be as productive as possible.
He just mentioned this briefly in this recent article, How to be a program manager, but he has gone into more depth on this topic before. Look through his past writings for more info:
Once the spec was finished and the development team got down to work, I had two responsibilities: resolving any questions that came up about the design, and talking to all the other teams so that the developers didn’t have to.
If you aren't technical then you need to select someone from your team to help with the design work and they will have to interface with the customer a little to figure out what the requirements are and what the best design is.
EDIT:
On Joel's home page there are two sections titled Tech Lead and Program Manager. Look at the articles there for some more info on program managers, especially Human Task Switches Considered Harmful.
I'd be using a Wiki, you don't want to add to the email storm, and your developers can also contribute and change things. It's also really useful for sharing documents, and if done well it will become self-supporting.
BTW Cut/Paste from email to wiki seems like an odd thing to have to do, does anyone know a lightwieght .Net wiki that I can email content too?
One way might be to not forward all those emails and once a week compile all the relevant information, design changes, and so forth into a weekly meeting. I definitely wouldn't send out a barrage of emails to the developers. Of course, if something critical is discussed, then that should be put to their attention. However, try for a weekly recap and discussion of relevant details.
I'm seeing this question one year after it's been posted, however I can add my experience with some specific data for my case. For 2-3 developers on the project, I mostly do one-on-ones. Lot of times I do this over the IM or phone since most of my team spends a lot of time in home office. Meeting from time to time is inevitable, mostly when project is starting (1-2 developer meetings tend to be enough to kick off reasonably complicated project), but as a rule, all communication with the rest of the company goes through me and developers get a digest. Only exception is when I connect developer directly with the user (not management!) to work out details of the project.
I tend to avoid regular meetings (weekly or daily) and schedule meetings only when at least two of these happen, in this order:
Important info comes in (depending on urgency this can wait up to a week)
Developers are in the office, preferably for other reasons (developer-to-developer meetings)
Client is available (not much choice there, but I try to do meetings and connect developers with single hands-on expert on the client's side later)
I need design advice (since I'm a technical lead, I'm responsible for most of the high-level architectural decisions)
For teams of 4-8 people (8 people usually means two teams) I found out that short 30-minute meeting roughly once a week is more then enough to keep everyone up to date. This, of course, is in addition to one-on-ones which I do daily for junior developer and about twice a week for senior developers.
For one-on-ones, I prefer that developers contact me when they're looking for more to do or when they're have questions on task they just started doing. This is also a great way for me to keep eye on how things are going without developers needing to think about keeping me up to date. I tend to avoid e-mail when IM is enough, otherwise switch to phone (when there's something to explain or discuss) and to e-mail when:
Customer reported bug via e-mail
There are a lot of important small details and developer will probably go through that e-mail a lot of times during implementation
There are also developer-to-developer meetings when they need to coordinate on something (for example, when Java and Javascript developer need to work out interface details).
This way of working means that I have to respond to IM as fast as possible, and that I usually deal with a lot of interruptions so that developers have to deal only with interruptions for me or other developers. Which is OK, since important part of my job is to make developers effective.
If I need peace for coding (and can afford it) I found that delegating client communication to non-technical project managers and even beta testers (who are much better with distractions than programmers).
Ask them what they'd prefer. I assume they would rather not be cc'd on every email and would opt for a short verbal update on a regular basis.
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
We're generally familiar with code smells here, but just as damaging if not more so are when the business side of things - as much as it falls within our domain - is going wrong.
As examples, the inverse of anything on the Joel test would be considered a major process smell (i.e. no source control, no testers) but those are obvious ones and the point of "smells" is that they're subtle and build into something destructive. I'm looking for granularity here.
To start off with here's a couple (which can be turned into a list as the answers come in)
Writing code before you have a signed contract with the client
Being asked for on-the-fly estimates ("just a rough one will do") for anything which will take more than a day (a few hours?)
Ancient cargo-cult wisdom prevails (personal example - VisStudio sourcesafe integration is banned)
You've stopped having non-project specific group meetings (or lack any similar forum for discussion)
So what are some other process smells, and just how bad are they?
The book "Antipatterns" by William J. Brown et. al. has a bunch of project-related smells. They aren't always disasters in progress; mitigating circumstances exist for just about any smell.
The Portland Pattern Repository also has a page on Antipatterns, covering many of the same topics as the "Antipatterns" book. Visit http://c2.com/cgi/wiki?AntiPatternsCatalog and scroll down to "Management Antipatterns." A few examples:
Analysis Paralysis - a team of otherwise intelligent and well-meaning analysts enter into a phase of analysis that only ends when the project is cancelled.
Give Me Estimates Now - a client (or PointyHairedBoss) demands estimates before you have enough data to deliver it. You accept the "challenge" and give out of the head estimates (i.e. guesses). The client/boss then treats the estimate as an iron-clad commitment.
Ground Hog Day Project - meetings are held which seem to discuss the same things over and over and over again. At the end of said meetings, decisions are made that "something must be done."
Design By Committee - Given a political environment in which no one person has enough clout to present a design for a system and get it approved, how do you get a design done? Put together a big committee to solve the problem. Let them battle it out amongst themselves and finally take whatever comes out the end.
Collect them all! :-)
Back Dating - being given an end date and then told what needs to get done
Inverse QA Coverage - QA focuses on the non-essential items (because that's all they know how to test)
Environmental Alignment Issues - the various environments (Dev, Test, Staging, Production) are not in sync for code and data - therefore any testing prior to production is invalid
Delivery Date Detachment - no one believes in the end date because: it was made up to begin with and 100% of prior projects never met their delivery dates
Old Grumpy Code - old code is feared because there's no desire to refactor
the evil pm triangle (scope, cost, resources and/or quality) - to adjust the project you need to add people, reduce quality, reduce scope, etc....once a project is in motion, most changes (even reduction in scope) will increase time and cost and reduce quality..once the train tracks are down, it's tough just hanging a left turn
One smell I have a real problem with (because I work with it): Not ditching tools, dev software, methodologies, or anything else that doesn't work.
Many times, there is one (or more than one) piece of software that clearly, blatantly, doesn't work and likely interferes with the development process, but which a project manager simply refuses to replace/upgrade "because it would cost too much {time, money, whatever} to replace."
Edit: This also extends to machines and other infrastructure too (examples: a build server that takes an hour to do a two-minute build, or a version control system - ahem CVS - that takes 15 minutes to find out whether there have been any updates on a 50MB source tree).
Shipping a prototype - "we'll productize it later"
I suggesting checking out the Organizational section of the wikipedia page on Anti-Patterns. The I've had to deal with are 'Crisis mode' and the 'on-the-fly estimates' you mentioned.
You haven't had a post project review....when the project ended 6 months ago.
Some smells I have seen:
Optimistic management, but they can't pay your salary this month. This is real bad. I left the company in time but it died a few months later.
Extreme fanatic team building sessions. Focussing on how great the company is. But in the end it all goes down.
Good new people are laid of because they tried to change the process. Real shame. I have seen some people that really tried to improve the company, but old habits never dies so it often ends in a big desillusion.
The boss is always right mentality...
There is more but I won't spoil the fun for others.
Changes to process are made with no thought to timing or current deliverables, then immediately reversed when deliverables turn up late due to instituting new process.
Someone goes on medical leave and the team as a result is behind trying to pick up that person's work as well as their own and when the managers or clients or client sales reps are told things will be delayed as a result, they are only concerned about when things will happen and can you work nights and weekends in the meantime and never even ask about the person with the emergency and how he or she is doing.
When overtime for low level people is expected but the people who want this urgently leave on time and are not availble to answer questions. Or when they make you work overtime to be ready by 8 am and then don't look at it on QA for three more days. Hello I could have done it by then in regular hours.
Delivery of needed files (for data import for example) or information minutes before the due date and then blaming developers when due date is not met.
What I call: NIH (Process edition), a.k.a. Choose your own adventure.
Evidence of this:
you spend endless meetings debugging the process. And refactoring it.
nothing really gets done, because no one knows what they should be doing.
I guess this is an antipattern, rather than a smell.
Interesting question and even more interesting answers. Thanks for those.
I have been in almost all roles of software development (Developer, QA, Tech Lead, Project Manager - even client) and I can safely list the following smells
How quickly does the team react to new inputs (and how accepting are they of change)
How many layers does it pass through to get things done (beaurucracy)
How clear are the features/tasking - and are the goals SMART and do we have any KPIs.
How serious is the team working on the project about it
Is the team meeting regularly (read daily) to discuss achievements, goals and issues.
Most important, however, and the most evident (to a good nose) is the hygiene level of the project management tool being used (excel sheet, piece of paper, agile tools, email, whatever in whichever methodology you use). That is the first thing I notice while evaluating projects.
Do I know where the project stands at the moment?
Can I tell (Without asking the team) what needs to be done next?
Can I tell what the team is working on right now?
Can I tell when the next release is and if its achieveable?
Can I tell if client is getting regular updates?
Can I tell if client is giving approvals and if his feedback is taken care of in time?
Can I tell just from looking the load distribution of the project on the engineers?
Obviously, all this is well covered if you pick any modern Agile methodology, but depending on the market and kind of work, the mileage may vary. So keeping myself methodology agnostic, this is the bare minimum set of smells that should be rid of.
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 want to avoid the situations when my developers do not share the common knowledge (solutions for the problems they encountered, cool tips, common mistakes, shortcuts for achieving particular goal, configuration issues, partial requirements, etc.) with each others. I'm taking about the situation when such lack of communication is accidental (a result of the misunderstanding or improper management) - I'm not thinking about the situations when developers deliberately keep the knowledge for themselves.
I believe that the following techniques are extremely useful to improve the information flow within the developers team:
XP pair programming - due to the knowledge exchange within the pair (and due to the regular pair mixing).
stand-up meetings - due to the occasion to tell the others on what you're working on and what problems you encountered.
trainings/presentations/coaching prepared by the lead-developers to the rest of the team/department.
"web 2.0 tools" - techie blogs for the company/department, dedicated twitter account of team leader, wiki's and stuff like that.
Any further ideas? What techniques do you use (or did you) in your company? How would you encourage developers to share the knowledge between themselves?
Trust.
You are allowed to 'seem stupid', but please ask if you don't know, or don't fully understand what I'm saying. And please tell me if I'm wrong (I didn't realize it because I'm equally stupid.)
I worked at one company where every Friday we had lunch meetings for developers. Management would provide food while developers had to share their knowledge; present some tool or technique one learned recently, or give a demo of a project you are working on, etc.
It wasn't restricted to the technologies that were being used by the team at that time, developers were encourage to learn new technologies and give a demo to the team.
And at my current job we have monthly IT group meeting, where sometimes developers from different teams demo off the projects they've been working on.
An internal twitter-esque utility. Maybe a wiki if you can get it to work, I personally find it a little too much. But twitter is different. "just added an extention method to escape a like clause in a rowfilter" and stuff like that.
Some people may find it a little overbearing, but a common location for utilities so you know where to look and string.CountOccurrences isn't scattered throughout the codebase.
I'll add a few more
Hire the right people - This is essential if you want to create a great dynamic (asocial people require a lot more effort)
Pre-mortem and post-mortem. We use the wiki for this, create a page for each of your projects, split it into section of recurring things (both goods and bad). At the end of each milestone, have the team meet to do a post-mortem. At the end of the project (or after a fix lenght of time), have project coordinator compile this into something easy to read for posterity (and put it on your wiki)
Daily stand-up are a must! You already said it, but I find it so helpful!
If you have multiple teams in the company, organize conference about one of their greatest achievements. If possible on a regular basis, even accros department, you would be surprised how artists can be interested into programmers work.
Lunch is a good time to share, in our company we have the president breakfast, project leads lunch, end of projects supper. I love them all, mix and match for greater results.
Offsite meeting with the whole company is great, we do it at least once a year (morning we present what's coming up in the futur, afternoon, is activities to learn about the projects)
Wikis are great, but beware of informations that can become false over time (this is a reccuring problem with any written informations)
A few more things to my mind:
Patterns & Practices meetings - These don't have to be every week but there should be some time devoted to where the team can discuss various outstanding questions and have concensus for things that may save a lot of people headaches.
Culture factor - Does the work place provide enough socializing to help the team gel or could some team-building exercises, e.g. an obstacle course or cooking together, be useful in getting some dynamics established. Is there a humility among developers so that there aren't big egos that can be a problem. Another factor here is to think about how you'd answer this: Would you go to a local pub and have a drink with your fellow teammates? If yes, then you have some good points here while if not, then there may be some investigation to do here.
Retrospective follow-up - How are ideas presented during retrospectives considered and implemented? How are meetings handled in general?
Demos within the team - If some story got finished and involved some big code points, then perhaps there should be a little demonstration of this for the team to see what was done and allow others to see what was done so that the knowledge does get spread around. This can dovetail with my first point in terms of being something that helps to further communication.
I'm a big proponent of working in pairs. It is a good way to transfer knowledge and keep communication lines open. Try mixing up the pairs for each project as well.
I've tried many approaches, and am a big fan of working in pairs on projects, as well as doing regular discussions or meetings with the team.
However, I've also found that the single best thing I can do is foster a culture of constant communication between the developers. I try to have all of my developers communicate with each other as they work - not even necessarily waiting until a weekly or monthly meeting.
For me, this is a little trickier as most of my developers are not in the same location, so we have a single XMPP chat room setup, and all of us are always logged in when we're working on the project. Some of the developers (including myself) will login during our off hours, as well.
I do the same with the people in my office - we tend to be a fairly quiet bunch, but I'm very open to having people interrupt each other with questions, or grab a chair and sit down to brainstorm at any time.
Part of why this works, though, is I try not to restrict the communication to the work at hand, or any specific project. My feeling is that people are going to talk about other, non-work related things, whether or not I foster that. I'd rather have the "water cooler" talk in an official channel, though, than outside.
This makes everybody feel more at ease to ask the questions that "seem obvious". Also, people ask questions continually, since they're right there, and used to talking to everybody. It's easy to ignore if needed, but also much easier to just throw out a general question and see if anybody has ideas without feeling like a pain, etc.
My experience is that the time lost due to interruption is much smaller than the time saved due to having a group that is always eager to help solve a problem at hand.
If you have a small enough team, using adequately SVN commit comments, and exploit them a tool that generates an RSS feed (like Trac for instance) can be an easy and efficient way to promote communication.
There are several requirements for this to work, which are quite easy to attain:
- commit frequently (that is good in itself, as it allows everybody to benefit from each programmer's local changes, and to identify problems early);
- use verbose comments (which is good to, as it allows to trace more easily what was changed, in case anything breaks down);
- ensure everybody actually reads (better even, keeps posted to, through an RSS reader) the feeds.
Of course, there is no way to "reply" to such comments, but if someone really needs to reply, it's probably between that person and the committer, so mail is usually enough.
An other useful tool is to ask each developer to, let's say, once a week, write a 10 or so bullet point list of recommendations for fellow coders, on a topic he/she is really familiar with.
Time.
Official
Getting out of your dusty office to clear your mind, really taking the time to go to a lecture or training, it all helps to spread knowledge.
It's also easy to budget: N developers go to meeting for T hours.
Unofficial
"On the job" training... The things you need for your specific job can only be taught by someone who knows the job.
In the current climate, under the current pressure (must ship now), no-one takes time to fully explain something. Only when people are relaxed, they are readyfor information sharing. People are relaxed when they have enough time.
Apart from that, you need to bump into some specific linker error before you really start thinking about it. Without the time to think, ask, read, you won't be able to get the knowledge. You can't postpone it to an official linker-training.
Way harder to budget: developer Mary asked developer Sophie about dynamic linkage for an hour and a half. The day after, she went back with some questions. Experienced developers will spend more time distributing, while younger will need more time learning.
no walls - Have all of your developers in one large, non-walled room - where everyone can see and talk with each other.
common goals - ensuring your team has a good understanding of goals INCLUDING the goal of self-improvement
rewarding - rewarding - even if nothing more then communication - reinforces what you are looking to accomplish
Socialization and common goal always encourages exchanege of information.