My dreams of solving big problems with wonderfully majestic architectural solutions crashed over 10 years ago. Working in an enterprise environment for years and seeing no projects actually make it to production is quite deflating. “So, what do you do?†“Me? I write software†“Oh really, what does it do?†well…
This was an eye-opening experience after starting my career and spending five years developing a retail tax electronic filing software package in the early 90’s that had to be out the door and function exceptionally by a given date or the company shut its doors. I came to realize we did “agile development†there every year from June to January long before the “agile†was a buzzword.
In the ten years since the deflation of the “architectureâ€-era of my career I have spent trying to find the right balance between the two. The academic side certainly has to play a role in being able to solve problems in better/simpler ways. The practical side certainly has to place limits on the time it takes to find the perfect solution to any given problem.
So my question is: If “agile†(not Agile) is the better way to do things why does it still seem to be such a high-stress, long hours work environment? Are we doing something wrong? Should the fact that we’re doing things with agility take the pressure off and allow for 40 hour work weeks and stress-free weekends?
The mass amounts of project data/metrics available to management by using various agile practices gives visibility into things never seen before. This seems to cause as many headaches as it is meant to solve. The concept of failing-fast/early is great… unless you’re failing fast and early.
(Wouldn’t it be nice to go back to a muddied-requirements based project with no oversight that you can just throw back over the wall when you think you’re done? Ok, not really, but sometimes I day-dream about working on a project where they actually do know what they want.)
And how much effort should be put into transformation efforts? Management has been sold a new silver-bullet every couple years (whether tool or process) for the duration of my 18 year career. I understand why they don’t bite. But they still don’t understand that fixed-requirements and fixed-resources and a fixed-date is always setup for failure… because the idea of fixed-requirements in itself is a figment of their imagination.
This was an eye-opening experience after starting my career and spending five years developing a retail tax electronic filing software package in the early 90’s that had to be out the door and function exceptionally by a given date or the company shut its doors. I came to realize we did “agile development†there every year from June to January long before the “agile†was a buzzword.
In the ten years since the deflation of the “architectureâ€-era of my career I have spent trying to find the right balance between the two. The academic side certainly has to play a role in being able to solve problems in better/simpler ways. The practical side certainly has to place limits on the time it takes to find the perfect solution to any given problem.
So my question is: If “agile†(not Agile) is the better way to do things why does it still seem to be such a high-stress, long hours work environment? Are we doing something wrong? Should the fact that we’re doing things with agility take the pressure off and allow for 40 hour work weeks and stress-free weekends?
The mass amounts of project data/metrics available to management by using various agile practices gives visibility into things never seen before. This seems to cause as many headaches as it is meant to solve. The concept of failing-fast/early is great… unless you’re failing fast and early.
(Wouldn’t it be nice to go back to a muddied-requirements based project with no oversight that you can just throw back over the wall when you think you’re done? Ok, not really, but sometimes I day-dream about working on a project where they actually do know what they want.)
And how much effort should be put into transformation efforts? Management has been sold a new silver-bullet every couple years (whether tool or process) for the duration of my 18 year career. I understand why they don’t bite. But they still don’t understand that fixed-requirements and fixed-resources and a fixed-date is always setup for failure… because the idea of fixed-requirements in itself is a figment of their imagination.