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'm interested in what constitutes a big team and what ratio of developers, Architects, Testers, Managers etc.
Does anyone have any figures for team sizes on well known projects like windows or SQL Server for instance?
If you ask Jeff Bezos, you optimally want a "two-pizza team": If you can't feed a team with two pizzas, it's too large. That limits you to five to seven people, depending on their appetites.
I dream of the day when all the different stages of development are part of a single team, instead of having team "conveniently" broken by job description. This organizational view tends to lean processes heavily towards the dreadful waterfall (god I hate this process!).
But to answer your question, I think the team should not exceed 10ish people with a few more gravitating around it without being full time part of it (training, marketing, clients, implementation, support). In all 80% - 20% devs vs management/QA should tend towards good productivity. If your architects can also dig in the code a bit all the better. Frequent design reviews with the whole team should also allow everyone to have good oversight over the whole project and not just their pile of bananas.
Here is an example of team break down that had worked really good for me :
2 Sr devs that have a good grasp on architecture
4 Jr devs that can handle the grunt work
1 code ninja that can do some technological exploration (while also participating in the whole)
1 project manager, team lead, interface to the outside world to bring in the 2 pizzas
1 noisy QA guy to poke around the application, write acceptance tests etc. The noisy part was for the WTF/day metric. The quieter he was the better we did our job and the less ibuprofen we consumed.
Around this gravitated some clients on whom we did frequent usability testing.
ha the good old days !!!
It depends on what you mean by "team". I worked for a large US bank on a .NET "team" of more than 60 developers, plus architects, managers, and QA.
My current "team" is roughly 12 developers of varying levels, a handful of QA, and one solutions architect.
But in both situations, I never work with more than ~3 people at a time. Usually only 1 or 2. So in that sense, we are broken into teams of 2-4 depending on the tasks at hand. For a single project, that seems to be about the limit.
You may find the following article of interest.
http://www.qsm.com/process_01.html
But, to answer your question is difficult without understanding the process you are using. For example, the waterfall model will call for a larger team than the XP agile method.
I have been on a team with 13 members but that tends to break down into smaller teams each working on certain tasks. If the team is large enough that politics comes into play then it is too large. You may have a large number of people that can work well together, all focused on finishing the project, and not looking out for their own self-interests, and the large number may not cause a problem, but, that having those types of people are unlikely.
Anything larger than 9 people is probably too large as it will break up into smaller teams, so, if a team is large enough that it will break up into small teams, then just have the small teams be the team size, and realize that what you started with was too large.
Teams should be as big as necessary for the project at hand, when I read "big" I get the impression you are looking for "how much is too big". I worked for projects with hundreds of developers for a phone switch development but they were always allocated into teams of 5 or 6 with a team leader each - hardware, software, documentation, testing & QA, installation, training and so forth. For the teams themselves anything more than 5 becomes hard to manage.
What I've typically seen is a ratio of 2 developers for every 1 architect (analyst) and 1 QA (tester) - so 25% architect, 50% developers, 25% QA - depending on how the team is broken up
functional - you would have 1 manager per area for every 6-9 people - so 1 for architects, 1 for developers 1 for QA min.
project - you have 1 manager heading up every project, if the project exceeds 9 people you sub-divide with team leads (part manager/part architect or developer or tester)
A team usually changes over time - up front you'll have more Architects and then move to more developers and near end of project life more testers come on board.
I've managed teams from 6 up to 100 and the ratio is usually about the same.
Where I work uses Scrum and to have a 15 minute effective Standup, there can't be more than 6 or 7 developers along with a few other managers each taking about 1.5 minutes to fit within the time frame. The other managers include some end users of our systems, quality assurance, and the team lead to give a few examples.
I think if the team was much bigger, the work would have to be more finely defined as I have a little trouble already trying to keep in my head all the stuff of the current project.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I work with a small team (4 developers) writing firmware and software for our custom hardware. I'm looking into better ways to organise the team and better define processes.
Our Current Setup
Developers are generally working on 2-3 projects at a time.
We have projects that work in an iterative sort of way, where a developer is in regular contact with the customer and features are slowly added and bugs fixed.
We also have projects with fixed delivery dates, and with long lead times, final hardware might appear only a few weeks before delivery. The fixed projects are usually small changes to an existing product or implementation and the work is somehow intermingled.
We are also moving from consulting to products, so we are occasionally adding features that we think will add value, at our own cost.
The Issues
We have a weekly meeting where proportions of time are allotted to each project. "Customer A wants to test feature X next week", so the required time is allotted. "Customer B is having issues with Y, could developer P drive down and take a look?", etc.
When we're busy, these plans are very loosely followed. Issues arise and lower priority stuff gets pushed back. Sometimes, priorities are not clear to developers so there is friction when priorities appear to change. The next week there will be a realisation that we're getting behind on project Z and we all pull-off some long days.
I'm told that this is all quite common for a small start-up in our industry, but I'm just looking for ways to limit the number of "pizza in the office" all-nighters.
Developers are generally working on 2-3 projects at a time.
Multitasking is incredibly inefficient. Switching the brain from one task to another requires time for the gears to change over.
When we're busy, these plans are very loosely followed.
Then why create plans at all?
Is it all possible to dedicate just one developer to one task / product / customer? So developer P is the only one who talks to customer B? (Certainly the developer would need to document exactly what he's doing in case he gets hit by a bus, but he should be recording issues and roadmaps anyway.)
The next week there will be a realisation that we're getting behind on project Z and we all pull-off some long days.
If there had been only one developer on project Z anyway, he wouldn't have been distracted by customer A's problems.
Don't think in terms of a pool of developers serving a pool of customers, think of one developer for a given customer. (This can make vacation planning a little tougher, but if you're constantly pulling all-nighters, you aren't spending enough time away from the office anyhow.)
I'm told that this is all quite common for a small start-up in our industry, but I'm just looking for ways to limit the number of "pizza in the office" all-nighters.
Aren't we all.
"Customer A wants to test feature X next week", so the required time is allotted.
Allotted by whom?
Do you create your own schedules? If not, the only response to management creating a schedule for you is all-nighters.
Realistic non-all-nighter schedules will bother management. Until you can prove that your customers want a better schedule with fewer all-nighters, there isn't much you can do.
The only way to reduce the all-nighters is to get stuff done sooner. But if the hardware doesn't arrive sooner, there isn't much you can do, is there?
Two thoughts: drive quality and improve estimates.
I work in a small software shop that produces a product. The most significant difference between us and other shops of a similar size I've worked in a is full time QA (now more than one). The value this person should bring on day one is not testing until the tests are written out. We use TestLink. There are several reasons for this approach:
Repeating tests to find regression bugs. You change something, what did it break?
Thinking through how to test functionality ahead of time - this is a cheek-by-jowl activity between developer and QA, and if it doesn't hurt, you're probably doing it wrong.
Having someone else test and validate your code is a Good Idea.
Put some structure around you estimation activity. Reuse a format, be it Excel, MS Project or something else (at least do it digitally). Do so, and you'll start to see patterns repeating around what you do building software. Generally speaking include time in your estimates for thinking about it (a.k.a. design), building, testing (QA), fixing and deployment. Also, read McConnell's book Software Estimation, use anything you think is worthwhile from it, it's a great book.
Poor quality means longer development cycles. Most effective step is QA, short of that unit tests. If it were a web app I'd also suggest something like Selenium, but you're dealing with hardware so not sure what can be done. Improving estimates means the ability to attempt forecasting when things will suck, which may not sound like much, but knowing ahead of time can be cathartic.
I suggest you follow the Scrum Framework. Create a Scrum Environment with an enterprise product. Have product Teams working on the features for their own individual products, which is a part of the combined enterprise product. If you have the resources have a production/issues support and infrastructure Scrum Team. If the issues are coming your way too quickly, have the infrastructure Team try following Kanban or Scrumban.
The Scrum Framework in itself will solve most of your problems if adopted properly.
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 off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Suppose you're the product manager for an internal enterprise web application that has 2000 users and 7 developers. You have a list of 350 future features, each ranging from 5 to 150 developer days of work.
How do you choose what features to work on, and how do you run the release process?
Here's what I'm thinking: (skip if boring)
Release Process. Work on several features at once, release each individually when it's ready. The other option (what we've been doing up to this point) is to pick out a certain set of features, designate them as "a release", and release them all at once (announcing via mass email).
The advantage of a shorter release process is that we can release features as soon as we finish development. The advantage of a bigger process is that it's easier to organize.
Feature Prioritization. Put all the future features in a spreadsheet with columns for feature, description, comments, estimate, benefit, (your) estimate, (your) benefit. Give copies to 2 senior engineers, the other senior project manager and yourself.
The engineers estimate all the features (how precisely? consulting each other?). To determine benefit, everyone allocates points (total = 10 * [number of future features]) among the future features (without consulting each other?), compare scores and average (?).
Another potential strategy here is to just rank each feature on an absolute (say) 1-100 scale. Having an absolute ranking is nice because it makes prioritizing as our feature list changes easier (we don't want to have to redistribute points every time someone proposes a new feature).
What's your strategy? Do any books / websites attack the problem at this level of detail?
There's a great book that helps cover this topic called Agile Estimating and Planning by Mike Cohn. It has some great ways to estimate and plan releases. Including a planning game called planning poker where the engineering team gets together with cards to estaimate user stories. Each engineer plays a card 1,2,3,5,8,13 face down. The high and low card explains and you do it again. After 1 or 2 repeats there is generally convergence on the same estimate.
There's also Beyond Software Architecture: Creating and Sustaining Winning Solutions by Luke Hohmann which might help with some of the product management related pieces and the reasoning to use to prioritization. I have not yet read the book but I went to a talk by Luke Hohmann where he covered the subjects of his book and I can't wait to read it.
Also I would recommend reading books on various Agile Development processes such as Scrum, Crystal Clear, and XP. There's Agile Project Management with Scrum by Ken Schwaber and Crystal Clear: A Human-Powered Methodology for Small Teams by Alistair Cockburn. Also Extreme Programming Explained: Embrace Change (2nd Edition) by Kent Beck and Cynthia Andres.
As for feature prioritization, that is generally done by the stakeholders. You need to work on the features that address the needs of your stakeholders, which, as Luke Hohmann points out, includes the system architecture.
However, one of the most important things is to make sure that you have agreement on the software development process from the team. If you force a process and the team doesn't believe in, then it will not work.
Surely you don't have 350 independent features, some must depend on others.
Put them all into some task management software which allows you to define which tasks depend on which other ones, and you might soon find that you've got a much easier decision process...
As for the release process, you could introduce the features when they are ready and inform the users via a company blog that is updated whenever a new feature is done. Such a blog entry should then give a short overview about the feature, where to find it, how to use it, etc.
Not only does this keep your users curious and coming back, it also offers a great way of potential customers to check out the progress of your offering.
As for prioritizing future implementation: how about involving the customers there as well? Look at uservoice (it is used to track requests/bugs for this site). It offers a nice way of letting the users vote on most desired things as well as showing what is being worked on and what is planned.
"rank each feature on an absolute (say) 1-100 scale"
Build them in order.
Release them when you've got (a) significant value or (b) critical mass of small things.
Always work in priority order. Build the most important stuff first. Deliver as much value as quickly as possible.
a few people here have already said it - involve the end users in the decision process of what goes in and what waits. after all, its not about whats useful to you, but whats useful to your end user.
that said, i wouldnt leave it open to 'all users to decide'; there should be a representative from the user group who you work with (i.e. senior user role).
even then, you arent saying "what features do you want?" to the user, you ask them what functionality they would like to see arrive next. the reason why you put it to them that way rather then letting them pick off a massive spreadsheet of individual features is two-fold: 1) they dont know about dependancies, 2) you want to gather together a pack of features for a logical release.
so the user representative may say "we need to have the photo gallery working next". they might not be aware that the photo galery is practically the same as the file upload module (it just accepts different file types).
so, in the next release version, you pack together the photo gallery and the file upload - why wouldnt you, considering that the file upload is like 75% done because of the work that went into the photo gallery module?
i dont believe you necessarily have to work on the hardest features first, its what the users need sooner + what other features you gather together to make a 'logical pack'.
to a certain extent, you want to clear the feature log too. so for example, you could have the following features and estimaed times:
Registration Form - 3 hrs
Photo Gallery - 8 hrs (<- client has said they want this next)
File Upload - 2 hrs
Voting/Poll module - 7 hrs
Stock Ticker - 5 hrs
out of these contrived features, i would take no. 2 (because the client is asking for it), then i would take no. 1 and 3. no. 3 because its practically done when the gallery code has been done, and no. 1 purely because its the smallest estimate out of the remaining features. nothing will give you or your coding crew the feeling of progress on your project like seriously beating down the feature list (it will probably refill though).
as far as letting people know about a new release and whats in it, i would do it via email (rather then by blog or within the program itself). and i would make it as brief as possible, bullet points, something like this:
===
Version 1.1 of Blue Widgets has just been launched and is available for your use now.
The following has been added:
Photo Gallery
File Upload
Registration Form
The user manual within the system contains more information on how these features work.
===
bang - done, make it as easy for people as possible.
LM
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).
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
Have you ever worked on a (full-time) project where using Agile methodologies actually allowed you to accomplish a 40-hour work-week? If so, what were the most valuable agile practices?
Yes, I'm on a 40 hour (actually it's 37.5 hours or so, that's what my contract says) on a project that was run with SCRUM from the beginning. That was about 2 years ago and the first time we implemented SCRUM. It's the project with the least amount of overtime for me personally, and it's also a PC game we're developing. I'm not even in "crunch" mode right now even though we're shipping an open beta on Friday.
We have learned a lot since then about SCRUM and agile. The single most valuable lesson from my point of view is: pod sizes must be reasonable ... we started out with pods with 12-20 members, that didn't work out well at all. A maximum of 10 should not be exceeded. It's too easy to agree on "flaky" and "vague" tasks because otherwise the standup & task planning meetings would take too long. So keep the pod size small and the tasks specific and get the product owner or sign-off's together with those who will work on the task.
Also, with a bi-weekly task planning schedule you have to get every Product Owner to agree on the task list and priorities for the current sprint, and new task requests should be issued before that planning meeting or else it will be ignored for the current sprint. This forced us to improve on inter-pod communication.
Scrum and management that is willing to buy into it.
Fair sprint planning. When you negotiate your own sprint you can choose what your team can accomplish rather than have tasks being handed down from above. Having your sprint commitment locked in (management can't change it mid-sprint) gives freedom from the every changing whims of people.
A well maintained, prioritized backlog that is maintained cooperatively by the product owner and upper management is very useful. It forces them to sit down and think about the features they want, when they want them and the costs involved. They will often say they need a feature now, but when they realized they have to give up something else to get what they want their expectations become more realistic.
Time boxing. if you are running into major problems start removing features from the sprint rather than working extra hours.
You need managerial support for you process without it agile is just a word.
Did I mentioned enlightened management?
Not being able to complete the tasks in a 40 hour week could be due to several things.
I see that this could happen in the early sprints of a Scrum project because the team wasn't sure of:
the amount of work they can do in the sprint and might bite off more than they can chew, and
their ability to estimate accurately the amount of points to award to blocks of work, or
the amount of effort required to perform "a point's worth" of work.
They may also be overly optimistic in what they can accomplish in the time alloted.
After that we get into several of the bad smells of Scrum, specifically:
a team isn't allowed to own its own workload, and maybe
management overrides decisions on what should be in a sprint
If any of these cut in then you are:
doing Scrum in name only, and
"up the creek without a paddle."
There's nothing much you can do apart from correct any problems in the first list, but this will only come with experience.
Correcting the two points in the second list will require a major rethink of how the company is strangling, not employing, Scrum best practises.
HTH
regards,
Rob
It may sound tough, but let's be realistic. Use of agile or any other flavour of a software process has nothing to do with a 40 hour week. Normally the amount of weekly work hours is stipulated within the employment contract and developer can use their discretion to put any additional unpaid work.
Please let’s not attribute magic healing powers to whatever your preferred software process. It can provide a different approach to risk management, different planning horizon or better stakeholder involvement; however, unless slavery is still lawful there you live the working day starts when you come through the door and ends when you go home.
It is as much up to a developer to make sure that the contract of employment is not breached as to their management. Your stake is limited by the amount of pay you get and the amount of honest work hours you agreed to give in return, regardless of a methodology used.
Certainly.
For the me the most important things that helped (in order of importance):
Cross-functional team - having programmers, testers, technical writers and sales/services people in the same team and talking to each other daily (daily call) was great.
Regular builds and continuous integration
Frequent reviews/demos to stakeholders and customers. This reduces the risk and time lost to it only for the period of iteration (Sprint).
Daily Call or Stand up meeting
Adding to all of the above (inaccurate estimates, badly implemented Scrum, etc.), the problem could to be the lack of understanding of your team's Velocity, something as simple as "how much work a team can accomplish", but which is not that easy to find as it may seem.
I've worked at several shops that practices various agile methodologies. The most interesting one had 4 "sessions" throughout the day that were about an hour and a half long, with a 20 minute break in between. Friday was Personal Dev day, so the last two sessions were for whatever you wanted to work on.
The key things for us were communication, really nailing down the concept of user stories, defining done to mean "in production", and trust. We also made sure to break the stories down into chunks that were no more than a day long, and ideally 1-2 development sessions. We typically swapped pairs every session to every other session.
Currently I run a 20+ person dev team which is partially distributed. The key tenant for me is sustainable pace - and that means I don't want my teams working > 40 hour weeks even occasionally. Obviously if someone wants to stay late and work on things, that's up to them, but in general I fight hard to make sure that we work within the velocity a 40-hour week gives us.
As both a Scrum Master and personnel manager, I have been a strong advocate of the 40-hour work week. I actively discourage team members from working over 40 hours as productivity drops quickly as the work-life balance shifts. I have found recuperating from an late-night work day often takes longer than the extra hours worked.
When it is well-run, Scrum aids in minimizing the "cram" that often occurs at the end of an iteration by encouraging (requiring?) a consistent pace throughout and tools like velocity and burndowns work well to plan and track progress.