Lost in Time Tracking.

Let me be direct and confess my opinion and intention first. I see time reporting as just a waste from an engineering organization point of view. Even though I honestly expect to be proven wrong any day, considering how many intelligent people consider time tracking to be really important, I haven’t been provided with any solid proof or evidence yet. I am writing this entry  to help me clarify my own thinking and with the hope of getting some comments back and learn from them.

I expressed my opinion to an  informally gathered group of engineering managers. They strongly disagreed with my point of view, so I asked them to present the group with the change or improvement performed in their teams based in time usage reports or statistics during the last year. Unsurprisingly there was none. Nobody in group has ever used the reports or data coming from the enterprise time reporting systems to actually manage her teams. They agreed  this was partly due to the reports not representing the complex reality of time usage within a product development or engineering team. If it’s really important and it can provide insight into our teams and processes then we are missing the opportunity. It’s practically useless even if it could have some theoretical potential.

Continue Reading

Advertisements

Boiling More Than One Ocean (At the Same Time)

Note on the publishing date: This post first appeared on 2013/02/25 as part of the now defunct leannovation blog header, which died because it happened to coincide with the name of an unrelated existing company.

Since I joined my first non-corporate software development team a few years back I have seen plenty of examples of product development organizations trying to do too much in parallel. I’m not talking about the usual peak of activity here or there, but about a constant stretch to higher utilization levels or to a bigger number of projects crawling through the development life-cycle.

I am bringing one particular example as an illustration. It was maybe an exaggerated case which, fortunately enough, I have only witnessed but never been a part of. The organization in question was a software development department within the IT division of a mid-sized corporation. By then they usually bought most of their software “in-a-box” or through externally contracted development projects so the department was not very big. Most of their developers were allocated to multiple projects; the most demanded ones to as many as 10 projects. Teams didn’t last long enough to gel and individual allocations were “calculated” through some pretty sophisticated resource management techniques, considering several variables like title, occupation, availability (in chunks of 5%) and even cost.

Continue Reading