Every development shop I've had the pleasure of working in had a practice to schedule developers at some sort of "maximum velocity" – the assumption that each developer could get about 40hrs of actual coding work done each week. Business owners and executives want to anticipate revenue based on billable or productive hours. Project and account managers must give commitments or milestones to stakeholders.
All this adds up to developers being put under a ton of pressure to be as productive as possible. (Getting away from hours estimating and into flow is a whole other subject - for now, I'll discuss how I tried to be as practical as possible working with the reality of needing hours estimates.)
The issue I've consistently seen is that the expectations on "developer productivity" are not always based in day-to-day reality - who can really get 40hrs of coding in a week while maintaining a work/life balance? This creates either of three situations: an adversarial and/or dishonest relationship between developers, project managers and stakeholders; a group of apathetic and disengaged developers, or a death march environment where teams become like the walking dead, burnt out on consistent 50-60hr work weeks.
What I want is a sustainable pace with consistent, predictable results so that setting and maintaining expectations with stakeholders and executives is an unventful experience. Here are some of the ways I've adjusted overall expectations of both stakeholders AND developers.
The first step toward sanity is to check our assumptions on what developer productivity means for the business. Most of my experience has been in service agencies with some time spent working on product-oriented teams. Regardless of focus, there are consistencies across these groups. In addition to working on a project, dev teams need time set aside for:
- Support tasks
- Planning and/or estimating; iteration or demo meetings
- Code reviews
- Training and learning
- Admin tasks like email, time sheets, reviews, team meetings, etc.
One of the toughest logistics questions managers face is how to schedule for a developer who must be available for support tasks as well as work on a larger project. When I say "schedule a developer" I mean a way to dedicate time to a project to ensure consistent progress while still providing support to existing code. This is not an ideal situation but an all too true reality for most small to mid-size development shops that do not have a dedicated support team. The concept of timeboxing has worked well for me in the past. In smaller shops I've had success to set aside the first 1 or 2 hours of every workday to a support task or two. Or, work out a schedule where one or two days a week, there are larger chunks of time set aside to dig into support tasks (anywhere from 4-8 hrs). The goal is to give your development team a consistent and predictable rhythm to their work. Nothing kills productivity and creativity like being interrupted for support tasks or questions about when/how to schedule. Save the interruption for truly critical support work - and do your prioritizing and planning with your developers at the same time every day, either first or last thing. If a developer is a mix of support and project, allow for the task-switching penalty in your timeline or other projections.
Projects will require frequent tuning. Making sure to allot time in my project schedule for developer involvment at iteration meetings and demos has saved me many headaches over delivery date and budget. This also goes for regular sprint planning tasks that include architecture, estimating, and even fixes in the QA cycle. Budget for these in your project schedule and recognize these activities are "real work" that need hours. (Plan for company meetings separately from project- or support-related meetings, more on that in a bit...)
There's a saying I've seen floating around on Twitter... not sure who to originally credit it to, so I will paraphrase it. CFO to CEO: "We're investing a lot of money to train our people. What if they don't stay with the company?" CEO responds: "What if we don't train them and they stay?" Software is a constantly changing and innovative field. Development teams flourish when given permission and resources to stay on top of trends, new methods and ideas. If your shop does not have a formal training schedule, consider an informal "Tech Talk Lunch" once a week and view a relevant video or webinar recording. Encourage discussion afterwards and see what comes out of it. Another element of training and learning is keeping up on blogs or other social media. If your team does a daily standup or weekly team meeting, this is a great place for everyone to check in with something they've learned or what was interesting to them that week. Or encourage some of your team to submit ideas to their favorite conventions and sponsor them as presenters. Managers need to budget hours away from coding for these investment activities. For the purpose of reporting up to executives, I've typically used 2-3hrs per week per developer to include these types of activities. The result was always a more energized development environment, focused on quality and efficiency.
Then there are "housekeeping" tasks like personnel reviews, time sheets, and maintaining email inboxes. Do you also have a regular weekly departmental meeting or team standup? There is no getting around that these things must be done; managers need to see this as work and not something that gets squeezed into the day between coding. When estimating available velocity, I set aside an hour a day per developer for admin tasks such as these - I didn't get too granular, just needed a general number. That may seem like a lot of time per day but it was typically accurate and it's better to have the time set aside than the alternative: gradual seepage of velocity, like air from a leaky tire.
If you're a project manager who must schedule a team based on hours, and make commitments based on available work hours, these ratios will be useful to you. I saw consistent results when scheduling 32-35 hours a week per developer in support or project-related tasks. Over a few weeks, you'll see productivity, energy and enthusiasm rise as realistic expectations are attained. Consistently on-target results are the key - re-set expectations to what's practical and enjoy a predictable and profitable development culture!
