...we felt like we were solving problems for a reason.
(Excerpt From: Ed Catmull with Amy Wallace. Creativity, Inc., Chapter 2, P. 52.)
|The MSC CM-5|
But in the late 1990s I realized I wanted a change. Much of my work had been on things that didn't have an immediate impact on the business. I wanted what is in the quote above - to solve problems for a reason. So when I received an offer to lead a new group building the next generation of network management systems I jumped at the opportunity. That is where I began building enterprise systems and set in motion opportunities for the next decade. It was also when I realized I wanted to build software in a more agile fashion, although at that time I didn't know it by that name.
When working for my company or client, I want to write software for a reason, that I know will make an impact. I've worked on projects where we spent days working on functionality that we knew would get very little use, but it was in the approved requirements document so we had to do it. This is a guaranteed way to lower team morale and lead to apathy.
In my first post I introduced the Agile concept of a story, a short description of a piece of functionality, usually written from the user's perspective. By having a backlog of stories and working in an iterative fashion (which will be explored in later posts), the business can choose which stories are of most importance at that moment. In such an environment, we can be responsive to the changing needs of the business, and will feel more confident that we are solving problems for a reason.