KSCOPE 2011: What do you mean “Agile”

Currently in Cary Millsap’s session about his agile approach on things called “My Case for Agile Methods“. Agile is (not yet) my thing, but knowing Cary, and he is in to it, when he is enthusiastic about something its probably one of those things which you should look into. If not even due to, as far as I know, the Agile context Cary is using is not the Agile context referred to I see being used out there. The “agile” thing out there is the one, is the one, I will joke about. But that said, a lot of methods are not bad at all, but people implement them wrongly so trying to keep an open mind, this session of Cary was more or less mandatory to get my vision about this back on track once more.

Cary also mentioned this emotion that probably mainly goes around in the DBA world. But as Cary mentioned during his presentation, “Agile is not undisciplined”, so if it gets the wrong emotional context, then is mainly due to people not doing it correctly. Could be thats it has to do with not being correctly trained in Agile or maybe incorrectly “managed”. So what is Cary’s feeling about this, that is, “Agile” as is…

Incremental Design… “Plans fail, bit there are ways to prevent a failed plan from failing your project…” so you can prevent this by continuously design, build and construct your project. The main key here is “continuously”. So for example, you don’t design your house and then leave the project, but should continuously design and iterate on your design as needed by a customer. This counts, is needed, for every stage, so the design, build and construct part.

Rapid Integration… “The worst software in the world? …90% complete, but nobody can run it yet…”. So if you want incremental design to be implemented quickly is really a step to support this continuous integration regarding bringing in all those improved, new, altered designs, build and construct tests

Test-First Programming… “Ever been afraid to improve your code?”. So how does test-first programming work?

1. Add a case
2. Add a test
3. Run all test (and check off all tests and see what fails or not…)
4. Write code
5. Run all tests (and make sure it now all succeeds)
6. Refactor

Pair Programming… Are you stuck? Not in the mood? Are you skipping steps? The fun part Cary here describing is that he is aware of how his office furniture is placed. It turned out that it is in such a way that its supports the buddy part where your buddy (wingman) can look at your code or comment on your code during your programming. Also your buddy can back you up when your stuck or tired. Of course its also more creative in the end due to the fact that you push each other in more creative and productive ways while doing your tasks, like programming.

Ten-Minute Build… This will mainly keep your energy up to create the best as you can do. You can’t continuously keep up the high level of concentration and if you can’t keep your pace your code level will deteriorate…

So keep in mind, if “Agile” looks stupid then most of the time its not the method that is “stupid”, but that it is implemented “stupid” by people. I indeed really believe that to make Agile work, that you need smart and disciplined people to make this work and a “customer” that continuously interacts with the team. Getting the hang of “it”, I indeed believe that most of the laughable stuff out there, is due to people, but then again, isn’t most IT/software/method out there based on what people do?. Its people, good people, that make it work, with a proper understanding of what the goals are you want to achieve…

I run into lately regarding a big project, if you are implementing very restrictive security rules in your development environment, then what is the “security goal” of doing this? If there is no balance into this kind of thinking, in the process, then its destructive to the overall goal. In such environment, probably, Agile methodology shouldn’t be applied in the first place. Think outside the box and give “Agile” a go, it might surprise you, but don’t underestimate the energy, flexibility, that is needed to implement it from each and every team member and the environment you work in.

There was more in Cary’s presentation, but have a look at Cary’s website, where most of this is way better explained anyway and a place to get into on topic discussions…