as reality sets in...

As reality sets in, I have started to realize the most straightforward path to software development, i.e. the much maligned waterfall method, just doesn't work. Perhaps each person needs to learn this for themselves. It's far, far easier to plan, but much more difficult to implement. So maybe those Agile people do have something to say.

Now, I still think this guy is over-reaching by saying that people hide behind detailed documentation. I would still argue if the developer here before me had written documentation, my job today would be a lot easier. I'd also argue that I've used my own documentation, because God knows my memory doesn't stretch back to something I wrote 6 months ago. But this article does explain how Agile is not the same as being undisciplined.

http://www.ddj.com/architect/201804241?cid=RSSfeed_DDJ_ArchitectDebug

Hopefully that links to the article on The Discipline of Agile. I'm planning to read more about Agile to see if it can help my department do a better job of meeting customer expectations.

So, on one project, we've started with an iterative process and I've sent off the first iteration to the development team in India. I realized that it was going to take years to gather all the requirements in detail, and it would be far more effective to get started on what we do know. We defined the highest priority use cases to the highest detail we could, and sent them off. We have 7 iterations planned. I have my fingers crossed and I hope that this process works. The customers are anxious.

On another project, requirements gathering was extremely painful. The customers couldn't describe what they wanted, exactly. The SMEs - the people doing the job that the software was supposed to facilitate - couldn't really decide on what they actually did. And because the goal was to make improvements and combine two similar systems into one . . . there were teams that disagreed on how the new application should work. To make it more difficult, I don't have the domain knowledge in the area (high tech manufacturing) to suggest the best features, or even imagine what they were telling me. They hadn't seen Remedy applications before, so they couldn't imagine Remedy's capabilities either. So instead of writing a requirements document - something I had tried and failed to start each week after our requirements meetings - I created a prototype. The next meeting was much more smooth, with fewer arguments. Because I had created something that we could all see, I was immediately getting much better feedback on what it should do.

Because the prototype was created in the same environment as the final product, my boss and I decided the best course of action would be to continue developing the prototype, allowing it to evolve between requirements meetings. Perhaps by the time we finished"defining the requirements", we would have a nearly finished product.