Wednesday, February 21, 2007
Enterprise Architecture and Time Tracking...
In a previous blog entry, I comments on the biggest myth in Project Management but of course, I managed to think of something equally evil practiced within many enterprises. Both JP Rangaswami and Todd Biske both commented on why EAs aren't embracing agilism. I figured it that if I combine these two thoughts, then folks may realize some EA antipatterns not previously discussed...
Both JP and Todd have discussed applying the Agile Manifesto to enterprise architecture. One of the things that shops who attempt to embrace agile approaches almost always fail at is in the elimination of time tracking. Of course, the bean counters and even the business wants to understand their investment spend within IT, but I savagely believe that what they are asking for is different than what they really need.
The business asks for hours while developers simply don't care to track them and therefore pollute the metrics by simply making the dialog go away. Developers on the other hand, understand that they do care about whether the tasks assigned to them are complete or not which is also in alignment with the business requests for information.
The business doesn't really want to know about time but they do want to understand velocity. Velocity should be a predictor of outcomes and of courses acknowledges that trajectory sometimes changes. Over time, velocity stabilizes within a project context which also provides another useful metric that time capture doesn't.
Could enterprise architects make things better for software developers if we displayed an ounce of courage and rebelled against time tracking? Emphatically yes! Imagine what would happen if developers solely worked on software development and could spend more time improving the quality of software instead of participating in distractions us enterprise architects, process weenies and bean counters force upon them...
| | View blog reactionsBoth JP and Todd have discussed applying the Agile Manifesto to enterprise architecture. One of the things that shops who attempt to embrace agile approaches almost always fail at is in the elimination of time tracking. Of course, the bean counters and even the business wants to understand their investment spend within IT, but I savagely believe that what they are asking for is different than what they really need.
The business asks for hours while developers simply don't care to track them and therefore pollute the metrics by simply making the dialog go away. Developers on the other hand, understand that they do care about whether the tasks assigned to them are complete or not which is also in alignment with the business requests for information.
The business doesn't really want to know about time but they do want to understand velocity. Velocity should be a predictor of outcomes and of courses acknowledges that trajectory sometimes changes. Over time, velocity stabilizes within a project context which also provides another useful metric that time capture doesn't.
Could enterprise architects make things better for software developers if we displayed an ounce of courage and rebelled against time tracking? Emphatically yes! Imagine what would happen if developers solely worked on software development and could spend more time improving the quality of software instead of participating in distractions us enterprise architects, process weenies and bean counters force upon them...
