What on earth do a development team care about Cycle times? After all what is it really for?
What do I care if it management want some bullshit metric to measure teams with - that doesn't make it valuable to us. We can't do our jobs better because of that.
OK so management can use cycle times for planning - but I don't need to know about that. I just want to get on with developing the product.
Granted, if we have short cycle times we can release the software more quickly then the company can make money on it sooner. But its not like the money wouldn't be made eventually.
Yeah - I suppose if we released regularly then my jerk of a boss would see what we have done and wouldn't scream at me for building the wrong shit.
Then my jerk boss makes us hack in the right solution at the end of the project for 3 weekends straight. If the code wasn't full of last minute hacks then my boss' precious cycle times wouldn't be so long!
Alright Alright I admit, by having shorter cycle times then I am probably going to have less things at any one time to work on, and my focus and attention can be given to one work item and prevent context switching.
FINE!! - short cycle times mean that the client will see our progress and have faith in what we do, but does that help me do my job? Trust between my team and the client is great but how does that let us build something better?
Alright - fair enough - I guess by having the clients trust I won't have to listen to them tell me how to do my job and have them constantly checking up on my every move.
Okay Okay okay - other than quicker releases, better return on investment, fast feedback, cleaner solutions, less context switching, gaining the trust of the client, what have the Romans ever done for us?
What do I care if it management want some bullshit metric to measure teams with - that doesn't make it valuable to us. We can't do our jobs better because of that.
OK so management can use cycle times for planning - but I don't need to know about that. I just want to get on with developing the product.
Granted, if we have short cycle times we can release the software more quickly then the company can make money on it sooner. But its not like the money wouldn't be made eventually.
Yeah - I suppose if we released regularly then my jerk of a boss would see what we have done and wouldn't scream at me for building the wrong shit.
Then my jerk boss makes us hack in the right solution at the end of the project for 3 weekends straight. If the code wasn't full of last minute hacks then my boss' precious cycle times wouldn't be so long!
Alright Alright I admit, by having shorter cycle times then I am probably going to have less things at any one time to work on, and my focus and attention can be given to one work item and prevent context switching.
FINE!! - short cycle times mean that the client will see our progress and have faith in what we do, but does that help me do my job? Trust between my team and the client is great but how does that let us build something better?
Alright - fair enough - I guess by having the clients trust I won't have to listen to them tell me how to do my job and have them constantly checking up on my every move.
Okay Okay okay - other than quicker releases, better return on investment, fast feedback, cleaner solutions, less context switching, gaining the trust of the client, what have the Romans ever done for us?
