Scrum is an Agile development framework that Jeff Sutherland invented at Easel Corporation in 1993. Jeff worked with Ken Schwaber to formalize Scrum at Why Time Sheets are Lame!
Programmer time vs. Quality Software Score. Totally uncorrelated!
Actually time sheets are worse than lame:
* they demotivate developers
* 10-15% loss of productivity is the minimum
* developers have to fake the time to fill them out properly
* erroneous data is used for reporting and management makes bad decisions
* customers are deceived
* they have nothing to do with quality code production
* they focus the whole organization on phony data instead of production
Nevertheless, this is not enough for many managers to give up time sheets. Just like the waterfall process, there is a psychological dependency so strong, it is as if they are on drugs.
However, the situation is even worse. Most management has completely wrong information in their head and thus continually make bad decisions. One of my students recently said to me, "You mean everything my manager told me is wrong!"
Yes, Jose, everything your manager ever told you is wrong:
* there is no correlation between developer time and software production
* there is no correlation between time spent and quality of code
* there is no relationship between "quality people" and code production
The only correlation between developer time and quality production code is the quality story points measured as a deliverable for a specific team.
Research over many years at Yale University provides some of the best data on this topic - see Joel on Software:
* for a single project worst/best coding times are 1/10
* across many projects worst/best coding times are 1/25
* the ratios above are the same for the worst and best Yale students
* the quality of the code produced is completely independent of time spent
For some reason, many development managers makes decisions without any data at all on this issue and their assumptions are completely out of reality.
Tom Poppendieck told me recently a competent manager actually did some research on his XP teams to see what number of hours per week produced the maximum amount of quality production code. After trying shorter weeks and overtime weeks, the best number of hours for teams to produce the most quality code was a 16 hour work week!
Trust me, you need to dump those lame time sheets and get focused on real software production before an Agile competitor puts you out of business!
posted by Jeff Sutherland @ 1:39 PM
10 Comments:
I can't agree with you more! The challenge I currently face is that I'm a scrum master working within a "time and materials" billing model. So if we fall behind early in the sprint- but force our developers to stay late to make up the difference, we actually make more money! And quality decreases (of course) because of the stress to get the deliverable out the door. So I'm trying to convince the powers that be to charge a flat fee that is based on a team of developers (5 devs = $x per week) regardless of how many hours that team works. Have you seen any other billing strategies that have received buy-in from traditional hourly billing managers who can't quite grasp the concept of quality of code is not directly related to the time spent in your seat with your hands on a keyboard?
The best Agile consultancies focus on fixed price projects. It is easy for them to deliver software in half the time with half the bugs. Fixed price allows them to drive margins up over 50%, or roughly the same as a software product company. If you have to report time, I have described how to do this so it is accurate and doesn't waste developer time or lower motivation. See http://jeffsutherland.com/scrum/2007/03/time-tracking-is-anti-scrum-what-do-you.html
This is great stuff- thank you. I've struggled greatly with our current time keeping process. It just doesn't make sense to me to have developers spending their time filling out timesheets. But we bill clients by the hour- that's a business model I don't have control over changing.
What I do have control over, however, is how I gather the data. So I'm going to implement your time invested + percentage complete approach. I'm eagerly keeping an eye out for "The Scrum Papers" for more details on the reporting structure.
I'll let you know how it goes!
Jeff,
This is my first time reading your blog. I think there are good arguments to not use timesheets on certain teams and projects. But I do not understand why you do not use them, and instead over-exaggerate and make up sources and stats.
Here are some issues you may want to consider on your post:
1. Joel Spolsky (one of your sources) says the opposite of what you propose. Actually, the use of timesheets is the most relevant new feature of his software management product, FogBuz. Please read Joel's latest column: Evidence Based Scheduling.
2. I guess that the Yale source you claim but do not cite, are the timesheets that for 25 years all Yale CS students have had to fill while coding exactly the same homework assignment. As these stats are available to alumni, we can use them as reference for certain estimations.
3. Lastly, I am surprised you mention Agile consulting as example. Most of the firms I know (ThoughtWorks being the most shiny example), make their employees keep timesheets and have a target of billable hours per week.
I quoted Joel's data that he got from Yale. I radically disagree with his use of timesheets. They do not increase velocity of Scrum teams, they slow team velocity down. We used tools at PatientKeeper that gave as good or better time data than FogBuz for years. Our Product Owner has abandoned time data because it slows Scrum teams down and gives no accurate measure of feature delivery.
ThoughtWorks is good on engineering practices and they currently require time sheets for billing customers. Hourly billing of customers will not optimize customer value. It gives them the illusion that something might be happening. Acceptance of team delivery of real features is the only thing a customer should ever pay for. Hourly billing is charging for warm bodies whether they deliver or not, even when ThoughtWorks does it.
I disagree with your suggestion that the best Agile consultancies focus on fixed price projects. In my opinion, fixed price projects misalign incentives and instead have to rely on contractual obligation to ensure delivery. Contractual obligation means up front analysis and specification and the inability to handle learning and change - which is hardly Agile.
Of course - in the commercial realities of the world, many customers still insist on fixed price engagements, and there is money to be made there (especially if change orders are expensive).
So instead, Agile consultancies need to bill in an incremental way. At the moment that is time and materials, but your right - given the non-linear relationship between time and benefit, this isn't a great metric to work to. There is some thought going into how you would bill based on the delivery of value - but there is a lot of inertia in the market to accept these "crazy" ideas.
Post a Comment
<< Home