Measuring the Productivity of Development Teams

Proposed By
Bernard Hecker
Notes

Who is using agile? Kanban? Who is happy with their understanding of team productivity? Anyone using formal scrum? (some)
The natural progression of using scrum, sprints and backlog grooming is a typical path. But if you’re not using velocity and measuring burndown, are you benefitting from scrum and extracting information that’s useful and actionable?
Assigning points is a group agreement on what a point is - it’s not a formal measurement of time, though. New talent changes velocity (slows things down while they go through the learning curve of “what is a point”). Points only are useful for the team using it over time if they all share a common understanding of what a point is worth.
“Waterscrumfall” seems to be a common concern. People worry about project/product managers who put points into gantt charts because they’re under pressure to predict a timeline.
Unfortunate reality of overscheduled teams running multiple projects concurrently.
“Bug people” using Kanban but part of teams using scrum. In Kanban, the focus is on continuous flow - there’s no cycle. You minimize the work in progress and map it on a board. This works well and is in use by teams who are heavy into operations work (especially bug fixes.)
Scrum works well for the folks building releases where a lot of people have to work together.
Implementing a personal Kanban is another way to organize work and be able to demonstrate priorities. Particularly useful if the tasks and time to complete are understood and tracked, so you can use it to pick what will move into the done column based on the time available to complete it.
Scrum and Kanban both have ways to collect metrics and run analysis.
Tools in use:
JIRA
Trello
Kanbanery
Time-tracking is a useful partner to the tracking of work and points system. Can add another data point for understanding impact and velocity. But some teams are not willing to adapt to this change.How do you put a point value on R&D tasks - you don’t know how long it will take to solve the problem. How do you plan for it?
Velocity should be the average over multiple sprints to account for the spikes and dips in natural productivity. Trying to keep points the same is a huge challenge because people have different speeds at completing tasks.  How do you know where there’s room for improvement or your velocity is as good as it’s going to get?For folks using other methods (not agile), what is working for measuring productivity? What isn’t?
For one team supporting customers on research projects, the time budget is set up front - expectation is set up front first, then time is spent and you can go back to the client for feedback.How do you do code reuse? Reuse of code, sharing with your team and others, is the secret to productivity. Investing in that is key. The trick is trying to ascertain what the value is for the institution. If writing some code is immediately valuable to multiple organizations, then it has high value and definitely worth that investment in particular.
Developers want to know what the reasons are / justification (the “why”) behind what they’re being asked to do; they are more apt to be willing to track productivity when they are engaged and believe in the value of what they’re creating because they understand the “why.”
Very important to have a mix of work - the harder development work and the simpler bug fixes on something you’re familiar with as a developer - is a welcome variety. What makes a developer happy: flow, systems, what else? (Darryl will send out a link to the list.)
The focus on team productivity is greater than on individual productivity. There’s a high degree of concern over teams working on government funded projects, where that productivity is closely measured and justified.Sharing the productivity data right next to the value of what the developers produced is critical. Don’t focus on just people’s time - focus on the value of what was produced with that time and match it with a clear mission and autonomy. There would be more compliance at time-tracking if there was more definition on what to track and how. Also, leadership needs to invest in the tools and pay for it if they want the value of the data coming out of it.
Favorite tools: Podio (free! https://podio.com/stanforduniversity/employeenetwork) , LeanKit (http://leankit.com/), SmartSheets (http://smartsheet.com)

Year
2015