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
Given a situation where you have 2 projects that in total will provide enough work for a month for 6 developers in a ratio of 2:1.
Is it better to assign developers to each project and then they work on that project for the whole month or is it preferable for the whole team to work each project in turn?
What reasons do you have for your opinions?
Edit
To clarify, they are entirely separate systems.
It depends a lot on how related the two projects are. If they have a lot of similarities, I would say tackle them as two projects within one large group.
If they mostly unrelated from a code and architecture standpoint, it would make more sense to split into two teams for the duration of the two projects, perhaps cross-training some of the developers as is possible.
If you're an Agile shop, just run two concurrent iterations.
If the projects are in separate systems I believe it is wise to separate the developers working on the projects since humans are not entirely great at multitasking because our context switching skills are slow. So either they work one project after another or split up the team to each project.
The answer to this really depends on a lot of factors. If you're 100% certain that you won't lose a developer, and that no one will go on a long vacation, then splitting it into specific teams has some advantages. OTOH, if you don't know that for sure, it might be better to have the whole team work on each project.
Next, you have to consider deadlines - will running the projects sequentially increase your risk of missing a deadline on either one, and if it does, is that risk acceptable?
Of course, there's always the potential for developers to step on each others' toes. 2 man-months (yes, I know it's a myth) of work split amongst 6 developers is a little over one week's work per person - if that's reasonable for the size of the project, then that's fine. However, there is a limit to the size you can split the work into and still make sense.
Answer those questions for your project, and that should give you a decent answer.
I think that in the case of unrelated projects you will have a far better efficiency if you split your developers across projects. This is because there is overhead in communication, if you double the number of developers on a project you don't half the time it takes.
However if your developers need to learn both systems eventually then this overhead needs to happen at some point. time constraints should dictate whether that occurs during or after the project.
I would split them into 2 teams assuming that there are enough developers to cover each project (Each project gets 3 developers and 3 developers is enough for each project). I don't think it's effective to put more developers on a project than is necessary.
Edit:
This is not taking into account all the many other factors that go into this type of decision (developer productivity, skill, availability)
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
We just started to use scrum for our project management. We are a very small team (2 developers, 1 UI/Web-deisgner ) and we have a lot of running projects at once.
How do you handle having multiple projects running at once in the scrum model? Most of the time we have a main projects and some small ones. How do you combine multiple sprints efficiently?
edit: Don't be fixed on scrum. we are a small structure and very flexible with that. Scrum was just my starting point. If you have others systems that worked good for a or your small team i am totally open to any kind of input.
AFAIK the foundation of Scrum is that the team is involved in a single project at a time. Regardless of methodologies, task switching overhead makes it very inefficient to work on multiple projects "in parallel".
What you could do is to try to schedule the different projects into separate sprints, i.e. do a sprint dedicated entirely to project1, then the next sprint entirely on project2 etc. If the projects are of very different scope, you could consider varying the length of sprints, e.g. do a 3-week sprint on a large project, then maybe a 1 week sprint on a small one.
In pure Scrum the length of sprints is carved in stone indeed, but then again, IMO the point is not to get the "pure Scrum implementor" badge, rather a working real-life process for your team.
(disclaimer: I am not a Scrum master :-)
Update based on comment: I see your problem. You need to respond fast to small support (improvement / bug fix) requests from customers of other products, while still need to work on a bigger project in a predictable fashion.
One possibility would be to plan the sprints of the big project in Scrum, but "timebox" some of your time for incoming support tasks. E.g. if on the average you spend 5 days in each monthly sprint supporting other projects, you allocate 5 days' worth of resources (however you count time) for support in each sprint.
Another option may be to consider other methods, like Kanban, where there is no sprint or planning, instead the team works solely (or mainly) based on demand from customers.
You need 1 week sprints. 1 project only per sprint. It is a fallacy that you can deliver software faster by working on multiple projects at once. The bigger project may take several sprints to develop a release where as with your small ones, you may release after every sprint.
If your projects are for different POs / Clients it is even more important that you only work on one at a time; otherwise your priorities will almost always be in conflict.
How do you handle having multiple projects running at once in the scrum model? Most of the time we have a main projects and some small ones. How do you combine multiple sprints efficiently?
One option is to run multiple sprints in parallel and, even if it's not ideal, to be part of several teams (obviously not 100% dedicated). I'm not sure this would make sense in your context though, I'm not convinced running the small projects with Scrum adds value.
Another (maybe more appropriate) option would be to have an item in your product backlog for the work required by satellite projects/tasks and thus to allocate some time for them. If you need that time, burn it. And if not, just pick up some extra backlog items from the main project at the end of the sprint.
If you have a lot of small jobs which have to be done quickly then project management is not the right paradigm. What you are dealing with is operations management which, generally, involves well-defined tried-and-tested off-the-shelf work procedures. I suggest, therefore, that you separate, management-wise, those activities of yours which require project management and those which require operations management. If you do not have the work procedures defined (and tried and tested etc) yet, then you may have to set up a project to develop them (or to codify them if you want to think of them that way).
There is a big difference between the way in which software development projects are (or ought to be) run, and how, say, a help-desk runs. Just because you are a software developer experienced in the project-management paradigm (as I think most of us are) doesn't mean that it is the right approach for everything.
Once you've made the shift, you should find that you can continue to scrum-down (or whatever the term is) on your 1 or 2 projects, and turn the handles on the machine to deliver the rest.
Tricky. Your situation may not be a perfect match for Scrum but I think there are elements in Scrum that are applicable to you situation.
For example, the one thing that I find the most useful in Scrum is the Retrospectives since it is in those sessions where you improve the way you work. However in order to make the Retrospectives useful you need to measure the work you are doing to some set of items that you set out to do. So why not have something similar to sprints and do sprint planning for the items that you intend to do the next 1-2 weeks (shorter weeks seems to be more appropriate for your case). Do a daily Scrum meeting so that all three of you know what the others are up to and can fill in as appropriate. Then after the sprint you can sit down and think about how you can improve. If nothing else, the outcome of the Retrospectives will tell you if this worked for you or not.
I don't believe in trying to adapt a strict Scrum project scheme if that means running sprints in parallel or do shorter sprints with only one project at a time leaving the others untouched every other week.
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 have friends who have asked me to make websites and most are very small, usually I don't bother with a technical plan but one friend in particular clearly had goals larger than my own and the project is dragging on forever. If I had made a spec before the project I feel like this wouldn't have happened and our relationship would be as solid as before.
So my question is, how can you tell how small is too small? How do you tell when the project you're embarking on is going to end up in a guilt-ridden scope creep nightmare?
If you are going to be charging money (or don't want to be stuck doing the project forever), a project plan is always a good idea. Even if it's just a one-pager outlining what the web site will have (how many pages, any special features) and who is responsible for what. You should factor in that you'll spend 20% of your time (or whatever percentage past experience has taught you) on documentation or non-coding type work, you can give a better estimate of the effort needed. If it's a friend, you might want to tell them that you'll do the first X hours for free, but after that your rate is $Y per hour. Also, keep an accurate log of the time you've spent so that you can show them the amount of effort that is involved. Also, keeping an accurate log helps you estimate future projects.
As you may have already figured out, no project is too small to have at least an informal, written plan. Even if it's just a features list.
A project that does not need a plan is a project that does not need to be even started. In my opinion everything needs a plan, what changes is the extent of that plan. A plan could be just a list of deliverables and some deadline attached to each one. A more robust plan should include time charts, cost, phases, communications howto, dependencies, etc. So I think everything needs a plan, the contents of the plan is what changes depending on the project complexity.
Dwight Eisenhower on planning:
In preparing for battle I have always
found that plans are useless, but
planning is indispensable.
It seems the same in many software projects: you'll find that your plans need to be continually updated and that your first plan was quite different from what you finally completed. But that's okay, it's much better to put some planning in up front than to try something by the seat of your pants.
Agilists try to accommodate such changes in plans by breaking longer term plans into small "sprints" of 2-4 weeks. They'll have more details on the near term sprints, and fewer details on the longer term goals.
You'll especially want to be more detailed and precise if the project is bigger, if you are doing this for an external customer, or if you're attempting something new for you. It's less important (though not unimportant) for smaller projects and types of work you've done before and are very familiar with.
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 posted this question on Reddit Programming and did not get a single response. So I am hoping that Stack Overflow community will have an opinion.
Have any of you ever been on a software project that had fallen behind, where 'Crashing' or 'Fast-Tracking' the project schedule actually brought the project schedule back on track? I have never seen either of these project management techniques actually work. And all the articles on software development that I have read all state that these 2 techniques do not work and actually pushing the project further behind (for example literature on the Mythical Man Month). So who has seen it work?
Thanks Bill.
I have only ever seen it work once. It was a three or four month long project that was projected to run an extra two months over the original delivery date. The project got fast-tracked and things ended up getting back on track for the release.
...keep in mind though, that was only once. I've been on many more projects where the PM tried to use one of those two methods and they failed miserably and dragged the project out for months beyond already extended date.
It can work. But there's a price to be paid: lower quality (more bugs, less testing) and turnover of burned-out programmers.
And in many cases, a fast-tracked project will both fail to deliver on time and will still pay the full negative price, for the reasons stated in Mythical man-month.
I've seen it work but it's not the norm.
Things I'd want to see before I thought it might be feasible:
1) Staff available with suitable skills and approach. By that I don't mean ".NET programmer", I mean detailed technical skills, business domain skills (so they understand the problem), personality fit and understand the tools and the approach (source control, methodology and so on). This can happen in large companies where there are common tools, standards and knowledge but you need to be sure that they're ticking pretty much all the boxes.
2) Tasks must be nicely divisible. The best situation is where there are whole modules, applications or tasks unstarted and you can put new people on that. It minimises upskilling, additional communication and so on. If you can't separate out what the new people will do you're likely to majorly disrupt the existing team.
3) The whole team must have bought into the approach. If the existing team don't agree that bringing people on board will be right they'll likely fight it and you're doomed.
4) You need to be sure you've addressed why it was running late in the first place. If it was just bad estimates then are you confident the new estimates are good? If it was scope creep have you got the scope and change control in hand now? If it was because the deadline moved, are you sure it won't move again?
If you can't tick all four of those off, it isn't going to work.
Crashing and Fast-Tracking are two very different things...
Fast Tracking is where you take something (tasks or work packages) out of sequence and do it early. This may because of hardware delivery lead times, availability of resources, risk or whatever. So you might do things in parallel where originally you had planned to do it sequentially. I've fast tracked a lot of projects.. and yes it works.
Crashing a project is different in that you typically throw more resources at a problem to get it done quicker... this can be tricky. If it's done as a crisis response it can be painful adding extra people as you are already under the pump. In some situations you just add more problems.
Another alternative to crashing is to reduce scope. This is not always possible, but it should be considered.
With fast tracking or crashing... the sooner you know when you need to make a schedule change the easier to manage. This is why early deadlines are so important, they indicate how the rest of the project will go.
Both of these project management techniques work well to maintain a schedule, but they should be used intelligently by judiciously analyzing the network diagram:
study the variance,
study lead and lags;
decide what suits to your project: ‘Crashing’ or ‘Fast-Tracking’.
There is a software management principle that says adding manpower to a late project makes it later.
That said, as long as the measures taken are sensible it should be ok. Don't expect too much of your staff and provide reasonable incentives and don't take short cuts. It won't make miracles happen but if you're practical and want to push things just that little bit faster it can definitely be done.
When people have a stake in the potential success of something it's amazing how much more effort they're willing to put in.
It depends on what you mean by "work". I don't think I've ever seen it make a way late project deliver on time, if that's what you are asking.
However, I have seen it make way late projects deliver only a bit late. From the fuzzy perspective of management, that might be called "working". I've also seen it significantly lower the customer-based pressure on the company. Some might also call that "working".
Of course the price is rather high. Employees burn out, develop health problems or big problems in their neglected personal lives, etc. All of that has large financial repurcussions to the company. So I doubt the company comes out ahead in the long run. Is that "working"?
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
Imagine you work as a contractor in a large project involving multiple systems, and you are creating one of them. The whole project uses a traditional process, but there are smells that tell you that an agile process would be much better.
Now the question. Does it make sense to introduce an agile software development process in your own group only? There is no chance to change the whole project, but you might perhaps change the process in your own group.
What would be the major benefits and pitfalls of such a local process change? Are there specific agile processes that would work good in such a case?
Here's a great diary of how a guy changed his whole company towards Agile over a period of a couple of years - yes, starting with his own subproject, i.e. "bottom-up". But he does go into the pros and cons of trying a "top-down" change.
http://jamesshore.com/Change-Diary/
Very entertaining and intruiging stuff.
Read Effective Ways to Introduce Agile into the Workplace and Joel's seminal Getting Things Done When You're Only a Grunt.
Beyond that it's probably mostly marketing/expectation management with your superiors and customers. Both of which might resent investing in the various agile customer-inclusion "games". Both of which also might resent the "new-fangled" way of doing things.
I think the answer depends how isolated you can be from everyone else's process. If they just tell you to go get your portion done and come back with a completed widget, implementing Agile locally should be relatively easy. If, on the other hand, you are expected to follow lots of random dates and procedures, it will be more difficult.
You'll have to be flexible and make sure that whatever sprint cadence you have lands on similar dates to the rest of the system. You'll have to plan out your sprints ahead because the central planners will probably want an all-up feature list early and won't stand for the more laid back Agile approach. Just be conservative about what you'll deliver and you should be fine.
The advantages should be the same as the advantages Agile has elsewhere.
This is an interesting scenario. I had a similar situation years back, and I'd say doing this essentially doubles the project manager's (your?) workload. You will need to play double face, with one set of cards towards the customer and one set towards the developers.
If your developers are GOOD, I would go for it. If they are not, and would require kicks and handholding, be careful. If they are good but may get carried away to their own agendas, be firmly in charge.
It is sometimes funny how organizations with traditional project model emphasize minor features, irrelevant to the developer's mind, and completely ignore the real hot spots. I still don't get it - maybe it's plain stupidity and nonprofessionalism. Expect that.
And do remember test based approach is the heart of Agile development. Do tests first. This will be peculiar to the customer, but they will benefit in seeing how the subproject actually proceeds. You might get less "progress" early on but more at the final yards.
Depends on your motivations, and what you aim to achieve.
Pitfalls: the major one is that agile development works by increasing visibility. Thus, adopting agile practices in one sub-project, if the effort is at all successful, can lead to exposing issues that affect the whole project, resulting in a risk of backlash. Keep in mind the parable of the two envelopes.
Which practices you take on first depends on how you want to handle this risk. If you start by adopting the planning-related practices (task board, release plan, user stories, velocity) matters may come to a head relatively fast.
Ditto, more or less, if you start with practices in the area of requirements (user stories, automated acceptance tests).
If you start with internal quality (test-driven development, refactoring, continuous integration) you may improve the motivation of the developers on the project, at the risk of not necessarily mattering a whole lot in the larger scheme of things.
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
At what point in a team's growth must process change drastically? A lone coder can get away with source control and a brain. A team trying to ship large prepackaged software to local and international markets must have a bit more in place.
If you've experienced a large transition in 'process': Was the team's process successfully changed with the current members or was the team itself mostly replaced by the time the process change came? What were the important aspects that changed, were some unnecessary?
You are going to find it hard to get a quantitative answer to this. It really depends on how "wide" the project is. If there is one simple subsystem to work on, any more than 1 person will result in people stepping on other people's toes. If you somehow have a project with 8 segregated subsystems, then you can have 8 developers no problem. More likely, you will have several subsystems that depend on each other to varying degrees. Oh, and all of this is true regardless of the process you are using.
Choosing what type of process you want to use (spiral, scrum, waterfall, CMM, etc.), and how heavyweight a version of that process you want to implement is, is another problem, and it's difficult. This is mainly because people try to take processes that work in building construction, factory work, or some other industry that is nothing like software and apply it to software development.
In my opinion, McConnell writes the best books on software process, even though none of his books are process books, per se.
If memory serves me correctly anything above five people is where things get dicey. The number of paths of comunication between the team gets really large after that.
(2 people = 1 path, 3 = 3 paths, 4 = 6 paths, 5 = 10 paths and so on).
The last three places I've been the IT team went through a massive process change. Yes, you will lose people, probably some of the better ones too. it's not that they are stubborn and trying to stick to the old ways, it's just that a change like this will cause a mass amount of stress. There are deadlines to hit and a need for quality to be met. People will get confused about what process they are supposed to do, and many will fall back to the "old ways." (i've been guilty of this too I admit.)
The key to succeeding is to take it slow and in small steps. People need to take time to understand why the process is changing and how it benefits them. That is huge, if you don't take time to do this, it won't succeed, and key people will end up quitting causing turmoil.
One of the things to absolutely remember is that ultimately some turnover is good. It brings new ideas and people with different (and sometimes better) skill sets. You shouldn't try and force change onto people rapidly, but they shouldn't be a barrier either. If they don't agree with what is going on, they should either try and come to a middle ground with the people making the process or leave. One of the real eye openers I learned at my first job is that in reality everyone is replaceable. Someone will eventually be able to step in take the reigns.
In my experience this transition occurs at exactly the moment at which you also need management. It is hard to get above 8 developers without some over-arching coordinating function being in place, whether it is a team lead, segregation of tasks or old fashioned management. The reality I have witnessed is that even with the best, most talented, most bought-in developers you still need coordination when you get above 8 working concurrently.
And there is a discontinuous step in process as you cross that boundary. However it needn't be catastrophic. The best approach is for the team to adopt as much formal process as it can when still small so that all the necessary behaviour and infrastructure is in place. I would argue that this is synonymous with good development in any case, so even the lone developer ought to have it (source code control, unit tests and coding standards are all examples of what I am talking about). If you take this approach then the step up in process when it occurs is not so much a jolt as a rigorous coordination.
Every developer you add need to be brought in with the process already in place. When you get to 8 (or whatever the number turns out being for you) then you'll find that your team meetings get a little too loose and wordy, personalities start playing a part and it is more effective to divide activity up. At that moment your boss (or you if you are the boss) will need to appoint one or more coordinators to distribute and control work.
This process (should) scales up as well if you stick to your processes. Teams can sub-divide or you can bud teams out to perform functional tasks if necessary. This approach also works regardless of the methodology you have chosen for your project management, be it Agile or not.
Once you get up to 4 or 5 teams, i.e. 30-50 people then you will almost certainly need people who are happy that their sole task is coordination.
If you are small now and contemplating or expecting the complexity shift, then make sure you get your fundamental processes nailed down immediately and certainly before you start adding more staff.
HTH and good luck
A lot depends on the people working on the project, the integration points, etc. Even a single coder should have a code management tool and needs to interact with clients or the 'boss'. From experience, I've seen a change once there are more then 2 people and then probably any increase of 50%. If teams are organized by project teams, focused on decoupled parts of the product, the overhead increase will not exponentially increase as the team size increases (project vs. matrix organizations).