I’ve been in the business of writing software since 2001 where I started out writing point-of-sale web applications for an insurance company. From there I moved on to working for software development companies working on products ranging from online banking to line of business applications. For a short period of time I even dabbled as an independent consultant.
The more products and projects I was a part of, I soon came to realize that sometimes the bureaucracy associated with a company and/or product inhibited a lot of the productivity and creativity and could lead to a less effective end result, both in terms of the product and the team morale. The year was 2005, and I decided there had to be a better way.
These experiences are what drove me to seek out a better way of developing software where I would eventually stumble across this thing called agile development. The more I read about the mindset of agile development, the more I wanted to learn. My thirst for knowledge on this topic could not be quenched. Everything I read all had the same theme: focus on writing high quality software, engage the customer throughout the development process to make sure you’re writing what is desired, and empower the team to get things done. I thought this sounded too good to be true; as a software developer, this sounded exactly like the type of environment I wanted to work in, but what about the customer? What would her opinion be?
On the surface, it seemed like the customer would enjoy the process as well since she is involved in all phases of the development process rather than spending a ton of time trying to define the requirements up front and not seeing anything until many months later. I know I wouldn’t feel comfortable with that model as a customer: here the customer is investing time and money into a product with no return and nothing to show for until months, sometimes years later. The iterative approach that agile methodologies advocate gives the customer working software after each short iteration allowing the customer to quickly gauge whether the product is in line with the vision, shift in priorities based on market conditions, or, in the worst case, whether to cancel the product/project altogether. If the project is changed or even cancelled, the customer has still saved large amounts of time and money as only a few weeks have been lost instead of realizing that a change needed to be made only after the entire product was completed.
Even the most skeptical of customers can keep an eye on, and even be put at ease with, the progress of the project through the constant collaboration and feedback that is promoted through agile methodologies. Rather than the product development team and customer having an adversarial relationship, these methodologies take steps in the positive direction of customer and developers working together towards a common goal as each party are part of one cohesive team. Moving to this type of methodology seemed like a no-brainer; why isn’t the vast majority of software development occurring in this manner?
Over the last couple of years, I've played a large role in changing the way my place of employment goes about writing software. We've gone from an environment that was entrenched in the traditional waterfall methodology and have slowly moved to adopting agile methodologies. It has been a rewarding experience to see the productivity and quality gains that agile has brought to the development process and how an empowered, collaborative, cross functional team can bring about game-changing ideas and products. I'd like to share some of the experiences (good and bad) here in an effort to continue to spread the word and also as a means to selfishly solicit feedback from the community to improve our development processes moving forward.
No comments:
Post a Comment