Currently I am working at a company with a fast-paced environment, very aggressive deadlines, and historically a high rate of failure in the form of poor product quality and missed deadlines. Back when I started at the company, I introduced them to Agile methodologies and how they could benefit the organization in higher employee and stake-holder satisfaction, fewer or no missed deadlines, and better product quality. After some initial mixed reactions I was able to get them on board with the idea -- or so I thought!
While I have been successful in implementing many of the Agile practices such as earlier stakeholder involvement, EDUF, iterative development, code refactoring, unit testing, continuous integration, etc. in a relatively short amount of time, I still have to deal with the fact on a daily basis that they have to have very good estimates too far in the future. They must have this information from a budgetary standpoint and in order to be able to make executive decisions in advance about whether or not to proceed with a given project.
I have tried my best to explain how the Agile estimation works, and how trying to estimate too far in the future could be a wasted effort, but after all the time and energy spent, I am beginning to think that perhaps the Agile philosophy is not for all mindsets after all!
Posts
2 comments:
Hey Mo, I have been whispering in the ears of our management also about Agile and how it could help us in our environment. There is some interest but we have such a garage managed or retail mindset they progressive ideas tend to get stomped out. Its good to see that you have had some sucess in a similar environment. We also have to have to submit accurate estimates for projects that are out there in time. If you solve it let me know!
Al, it's good to know that you have been giving agile some thought too. The problem with Agile estimation is not that it can't be done, in fact you can have very good estimates for a foreseeable future (let's say 3 months), but estimates get pretty blurry as you move in the future along the timeline. This is not a disadvantage of the methodology. In fact I like to think of it as a "by design" feature that stems from the "Responding to change over following a plan" philosophy. In an ever-changing business world requirements are never static. They change over time and agilists consider investing in a project plan too far in the future as bad investment; for better or worse that plan is bound to change anyway.
Post a Comment