DevDays Day 2 Agile Development

Because I was too late for the Indigo chat, I decided to meet up with
friends at the Team System chat. It was, to my surprise, more about (MSF) Agile
then about Team System. The presentation was by Ron Tolido who gave the
presentation much flair and we had a very funny time. For a magazine for IT
professionals, he had written an article in which he explained his view on 9
different IT archetypes and in this presentation he used them happily to enjoy
us Microsofters.

If you were totally unfamiliar with the topics, this wasn’t a presentation
you would learn a lot. Even if he made a lot of jokes, he made you believe
RUP was totally useless, UML is something only people with gray beards and
sandals would use and Agile is without any form of documentation or
models. Precisely for this archetype, the Microsoftie, as they like to
drag-n-drop a lot and not think about any structure or application design,
or at least not until most of the application is working. Or at least looks
like it’s working, a crashing desktop as result is something Microsofties takes
for granted. Of course that’s not the case. Right? Sometimes we do think about something we develop, before ever touching code.

Another thing Tolido mentioned, was Java developers. They crave for complex
problems, complex models, etc. He said, when everyone started understanding
relational databases and fourth generation languages, they brought us OO and
inheritance. When people started to understand that, they thought, let’s throw
in multiple inheritance, polymorphism, etc. The thing however was the fact that
‘they’ create these objects, but to persist these into a relational database, a
mapper is required. A lot of complexity goes into this mapping business. And now
everyone is using xml for messaging and they need another mapper to serialize
these objects into xml.

The last archetype I have to say something about is the tester, and this
‘new’ thing called exploritory testing. Tolido said that for this, the tester
needs to hang back, losen up, take a sip from the waterpipe and in a very
relaxed mode, check out the application. That’s what exploritory testing is
about.

He did however also say some good things about Agile. He taught the
audience that the plan wasn’t everything, the planning of the project was much more important. One of the tenets of Agile is
responding to change over following a plan. Other (older) methodologies have
some kind of a war scenario with the customer. The customer asks you to build
something, you promise to build product “A” and when you’re finished, you
exactly hand over product “A”. I’ve seen it happen so many times, a customer
telling that what’s delivered isn’t exactly what he asked for! I think even
methodologies like RUP can cause these ‘symptoms’. Or at least I’ve seen it
fail because of it. Agile however enforces a lot of communication
between developers, business analysts, project leader and… customer! After
every iteration, you show a working version of your application to the customer
and based on that working version, the customer decides what changes
and what new functionality is.

Of course your planning/timeline can grow larger and larger, and the client
does not want to pay an infinite amount of money. When you do the juicy bits
first, the customer at least first and foremost gets what he wants
most. He can then personally decide to change stuff or add more
functionality. I just started reading Agile Software Development by Robert C.
Martin and he describes the way new functionality is rated. You get scenarios
(use cases in RUP) and the developers create tasks from those scenarios and give
them points on a scale from 1 to 10.The higher the score, the more work it
takes. After a few iterations, you and your customer know what your *velocity

• is, how many points you can process within one iteration. The
  customer chooses the juicy scenarios first, also based on the points the team
  can process. I have no hands on experience with this, but it looks like this
  must work! My goal for this year is, to use Agile development in a project and
  see how this turns out.