The crippling cost of free

Business will see delivery team’s function to “deliver”, but all teams do many other functions – most of which fall outside normal controls.  They aren’t products, projects, epics, stories – they’re ad hoc requests.

  • Requests for estimates/quotes
  • Requests for technical options/investigations
  • Recommendations
  • POCs
  • Re-prioritisations
  • Response to customer requests

The common link is that there is little or no visibility of cost to requester – all cost is borne by the delivery team and rarely tracked as “real work”.  Friction can arise when it is not clear to the business the volume and content of work being executed outside of that which is monitored and reported on (e.g. in burndown charts, project plans, etc)

Spikes are somewhat analogous within agile methodologies, but often these requests are additional or external to the methodology.

Symptom is unhappy stakeholders – slow turn-around time for responses, key resources become unavailable or ineffective, unable to access technical skill sets they need to address customer (and potential customer) requests

Potential solutions

Try forming a group who has specifically allocated time for dealing with these items – they’re the interactive interface to the business, protecting the delivery team who are focused on delivering agreed work

May have different rhythm to delivery group – shorter turn-around, daily/bi-weekly/weekly as opposed to sprint cycle

Invite stakeholders and visualise workload – kanban/WIP management better than burndown/scrum, offload prioritisation onto stakeholders – you want to prioritise, what do we drop out?

Systematise common components – quotes, technical documentation for inclusion in customer responses, types of analysis/investigation (1, 3, 5 day spikes) with risk factors and criteria defined and understood

 

The Zone: Banned for life

As a developer, you need long, undisturbed periods of time in order to concentrate on the problem at hand. Your best, most productive time is when you are in ‘the zone’.

Any developer worth their salt has experienced this state, where the outside world disappears, you’re holding 20 variables in your head at once and are being incredibly productive. A lot of job satisfaction is generated from this place; I personally equate it with the creative satisfaction that artists experience. It’s powerful stuff.

The bad news: To introduce even minor managerial responsibility – say a team lead role – into your job description, is to receive a lifetime ban from ‘the zone’. Once you become a hub for communication and decision-making, your chances of getting enough unbroken time to get into that effective, productive state are effectively zero. You are likely to be regularly frustrated at the constant interruptions of your colleagues.

The fix: I’m afraid the only effective solution I’ve seen to attempting to split your time between coding and managing is to give up on one or the other. If you’re attached to the management element of your role, you should seek to also ramp up other non-coding activities that can be completed in shorter bursts.

Design, documentation, code reviews, coaching and client interaction all fall into this category. If you’re attached to your coding, don’t be afraid to say as much and just pass up the whole management thing altogether.

Maker’s schedule vs manager’s schedule: http://paulgraham.com/makersschedule.html