robbowley.netRob Bowley | Adventures In Software Development

Rob Bowley Adventures In Software Development Menu Home Responsibilities of a Developer / QA Responsibilities of a Lead Developer Responsibilities of a Principal Developer Responsibilities of a Team Leader Responsibilities of a Team Member Line management in Agile Teams Leave a reply Line management is currently on my mind as I’ve moved to a new company (VP Engineering, team of 30+ people). Coincidently it’s also something I’ve recently been asked about by a peer in a similar position. Modern management practices tend to frown on line management as it smacks of traditional organisational structures. However – out with line management tends to go any formal pastoral care for staff as well as inexperienced or unqualified people getting left to deal with complicated situations with little or no guidance. Below is advice based on my experiences . I’m happy to answer any questions, but I don’t present anything here as a shining example of good or bad (where’s the Holacrocy dude?”), just stuff that has worked well for me over the years. Everyone needs good guidance I wrote this article on Roles & Responsibilities in Software Teams over 5 years ago and have used these effectively in 3 companies now. I find it really helps for everyone to be clear on what’s expected of them, it certainly makes the line managers job easier to have something which defines positive (and negative) behaviour. Team Lead as line manager for the team In my roles above, the Team Lead is basically line manager for the team. Their most important line management duties is regular 1-2-1s with their team to make sure everyone’s happy and productive and catch any situations or issues arising quickly. The Team Lead will also deal with team related line management issues, such as approving holiday, work from home requests etc. The CTO/VP/Director/Head of Dev (i.e. me) will have more frequent 1-2-1s with the Team Leads than other team members so there’s a good feedback loop and any issues can quickly get escalated if needed. Team Lead != Lead Developer I intentionally separated these roles of Team Lead and Lead Developer , as being good technically does not make you a good people/line manager (see the Peter Principle ). In many teams I’ve looked after the same person holds both roles, but not always. Ultimately I’m the Line Manager though… When it comes to more substantial issues such as anything requiring expenditure (e.g. pay increase requests, training) or performance issues that the Team Lead cannot solve himself (e.g. when you’re getting near the realm of disciplinary proceedings) that’s where I will take over from/support the Team Lead. Ideally a team can work through most of it’s issues, but not always. Line managers need good guidance and training Looking after people comes more intuitively to some than others, but either way it is a discipline people need training and guidance on – how to give good feedback is a great example as are good listening skills. I make an effort to mentor Team Leads in my 1-2-1s with them, but it’s good to have wider organisational initiatives too. Pay reviews and performance appraisals I’ve written up about my experiences with pay, performance and feedback previously. I consider regular 1-2-1s (with Team Lead and myself) to take the place of annual performance appraisals. However most companies still do pay reviews annually, which means some form of annual pay review meeting is required. As something I’d consider a more substantial line management issues I personally take responsibility for those pay review meetings with all my staff. This entry was posted in Uncategorized on February 16, 2015 by Rob . 7digital Development Team Productivity Report 2013 Leave a reply Last year (2012) I published data on the productivity of our development team at 7digital. I completed the productivity report for this year and would again like to share this with you. We’ve now been collecting data from teams for over 4 years with just under 4,000 data points collected over that time. This report is from April 2012 to April 2013. New to this year is data on the historical team size (from January 2010), which has allowed us to look at the ratio of items completed to the size of the team and how the team size compares to productivity. There’s also some analysis of long term trends over the entire 4 years. In general the statistics are very positive and show significant improvements in all measurements against the last reported period: a 31% improvement in Cycle Times for all work items a 43% improvement in Cycle Times for Feature work a 108% increase in Throughput for all work items a 54% increase in Throughput for Feature work a 103% improvement in the ratio of Features to Production Bugs a 56% increase in the amount of Items completed per person per month a 64% increase in the amount of Features completed per person per month DevTeamPerformanceReportApr12Apr13 (pdf) The report includes lots of pretty graphs and background on our approach, team size and measurement definitions. A brief summary of the last 4 years: Apr09-Apr11* Cycle Time improved (but not Throughput or Production Bugs) Apr11-Apr12 Throughput & Cycle Time improved (but not Production Bugs) Apr12-Apr13 All three measurements improved! *The first productivity report collated 2 years’ worth of data. It’s really pleasing to see we’re finally starting to get a handle on Production Bugs and generally things continuing to improve. It’s interesting to see this pattern for improvement. We haven’t got any particularly good explanation for why things happened in that order and curious if other organisations have seen similar patterns or had different experiences. We’d expect it varies from organisation to organisation as the business context has a massive influence. 7digital is no different from any other organisation in that you have to be able to balance short term needs against long term goals. If anything else our experiences just further support the fact that real change takes time. We must add the caveat that these reports do not tell us whether we’re working on the right things, in the right order or anything else really useful! They’re just statistics and ultimately not a measure of progress or success. However we’re strong believers in the concept that you’ve got to be able to do it right” before you can do the right thing”, supported by the study by Shpilberg et al, Avoiding the Alignment Trap in IT . We hope you find this information useful and can help other teams justify following best practices like Continuous Delivery in their organisations. We would of course be interested in any feedback or thoughts you have. Please contact me via twitter: @robbowley or leave a comment if you wish to do so. This entry was posted in Uncategorized on August 28, 2013 by Rob . Pay, performance and feedback – an experience report (and where we are now) Leave a reply I’ve written up an experience report on my recent adventures trying to improve the way we do pay reviews (it’s more interesting than you might think). Like many companies we’ve been struggling with a problematic pay review process. In our case the feedback mainly revolved around it feeling arbitrary and lacking transparency. Around the time we were discussing this the Valve Handbook got posted, within which it talked about their peer review & stack ranking system: We have two formalized methods of evaluating each other: peer reviews and stack ranking. Peer reviews are done in order to give each other useful feedback on how to best grow as individual contributors. Stack ranking is done primarily as a method of adjusting compensation. Both processes are driven by information gathered from each other—your peers.” Awesome, you get rated by your peers rather than a manager or HR person, who has no idea what you do (not that we did that anyway)! I liked this idea a lot and got to work on doing our own version. I started with a trial peer review survey with one team....