During the past month, a relatively new form of resource management has taken afoot at within our team.
Two separate factors contributed to this shift of developer resources:
1. Budget Constraints
2. Compliance Requirements
The first, budget, came from the management’s decision not to extend most of consultancy contracts – all of which were already overdrawn, for a specific product. With new product offering in the company portfolio for next year, the in-house developer resources have been tapped to finish Release-1.
The second, compliance, was a legal overhead to comply with certain Sarbanes-Oxley requirements, so we can have proof of our security practices, effectively in place.
For now, it should suffice to mention that BOTH of such factors are what I’ve come to experience at most companies where software is now an integral part of portfolio – or suite of products – so that it has a direct effect on the bottom-line.
Given these concerns, our team decided to deal with developer scarcity by splitting the single team into two schedules, a morning-section (9 – 12) of maintenance and Scrum stand-ups and the after-lunch section (2 – 6) of new development. We effectively time-boxed ‘maimtenance’ into the mornings.
Judging from the past month, the time-box worked rather well, increasing focus on a single WIP for either task buckets – new dev and maintenance.
However, it also left an unsatisfactory thirst in my appetite for completing a task. While neither task bucket was unattended for very long, this required us to shift our focus from-and-to the two buckets every single day.
The only happy campers are the staffers wanting more maintenance tasks finished off. What cannot be determined currently is whether the new offering portfolio can be fully supported.
The point of running a Scrum Team has been skewed, by non-technical factors. I wonder whether our past year should now be considered a failure in resource management, or a bigger-scoped project management.
offthemesh 