As humans, we've always had the innate urge to succeed. Success in an organizational structure that is driven by quotas and percentage profits is achieved when a set number of features are completed in a given (i.e. ridiculous) amount of time (possibly at a reasonable cost).
In my 10 years of Software Engineering career, I have been part of various different processes RUP, Waterfall, Iterative, Scrum, XP. Often when a new process is adopted with in a organization, it becomes the mantra of a few who have learnt it by the book and see it as a panacea for all existing problems. This mantra gets picked up by a few management officials who extend their so-called 'full support' to ensure the process is successful.
Once this magical alignment between the official and mid-level manager happens, the chosen process becomes the new destination replacing the actual product it needs to focus on. In Scrum, Velocity is an indicator of team's predictability in delivering set of features. Unfortunately, for some, velocity at 60 hr work-week is a successful scrum project.
At the end of project, you might have had a successful launch but you have just killed the thing that gives your golden egg, your employees.
Scrum intends that all parties, both internal and external be successful. When done right, it provides great benefits. But, when done right for the sake of proving a point, disasters occur. We sometimes achieve completion of economic goals with 'come what may' attitude and that does not necessarily translate to overall success.
Was that the destination you intended when you incorporated a new process?
No comments:
Post a Comment