Agile

[Markbnj]

It sounds like you are advocating Agile, and you just don't know it.

Maybe. Maybe I just haven't seen it done right. The whole idea of it seems wrong to me. If you know what you want, and you've thought through the workflows and the rules and interactions, why is agile necessary?

 

[TridenT]

So... books/resources?

 

[Train]

Maybe. Maybe I just haven't seen it done right. The whole idea of it seems wrong to me.

What "whole idea" are you referring to?

If you know what you want, and you've thought through the workflows and the rules and interactions, why is agile necessary?

I think you said it yourself:

The writing of a software system is not a production process. It's not a reproducible recipe for the assembly of components. It's a creative process of invention, and every time we undertake it we produce something which has never existed before. The best statement of software requirements that you've ever seen falls so far short of the production plan for an automobile that they aren't even the same animal.

Let me also ask you this: Do you ever get better at what you do? Do you adapt your practices after a project? Do you ever say something like "well that project went OK, but if I were to do it over, we could probably have went faster knowing this..." And then take that wisdom into the next project? Do you think of yourself as a craftsman, or someone who types for a living?

 

[Train]

So... books/resources?

Google/Bing

http://programmers.stackexchange.com/ has some great agile discussions. Follow the agile tag there. If you get interested in a particular practice or term that gets used, search for it, there are usually pretty good blog posts, or even videos of presentations at conferences.

 

[BrightCandle]

The right way to learn about Agile is actually to read about extreme programming. The principles and practices that came about from extreme programming are ultimately what Agile teams use today, its the engineering skills that are necessary to make it all work. Kent beck has a couple of very good books on the topic and Agile planning and estimation by Covey is also very good as it has some decent examples in the back that show how it works in practice with a cross functional team. But cover both the project side as well as the core engineering disciplines that make it work.

The overriding question I always like to ask is if you were told by your customer that their competitor had just released something awesome and they needed everything you had today live then how long would it take? If your answer is anything but "this afternoon you can have that" then your level of agility isn't very good. If you find yourself answering "well we can release what we have but it wont be X" where X is tested, signed off by the users, or anything else that NEEDS to be done to for it to be released then you are just trying shortcuts to make it look more agile.

You can get a surprisingly long way by asking how long would it take to release from now a fully working system. It allows you to look critically at what it is your team is doing and how it currently works to introduce batching and latency that reduces the teams agility. Most scrum teams never try to get below 2 weeks, that is there the period they settle on for sprints and thus that is the practical time for releases. With Kanban you can go a lot shorter than that and some teams get down to hourly releases. But to do it requires a lot of engineering practices that many developers really don't like. Hourly in many businesses is not the right way to go, but then monthly or yearly is probably longer than any business would realistically want. Ask and answer the question honestly and you'll find out how agile you really are.

The other question that I think has really high value is how long does it take for an idea to be implemented. You can in theory have a very large backlog and that can get in the way of other things and so maintaining a relatively short feedback cycle is also important.