zaterdag 22 oktober 2011

The big difference

If you'd ask me what is the top-of-the-tops of advantages of Agile development, I would go for ... Hmmm. It's always difficult to mark one specific item, but I'd say Risk Reduction is the main thing.

The funny thing is that the Requirements-Specs-Analysis-Design-Implementation-Test-Introduction-Maintain  (aka 'Waterfall model') people try to claim this, but they're dead wrong; it's exactly the opposite from what they claim. Waterfall procedures are almost a guarantee for overruns and blatant failure. And always producing mediocre results (if any).

Value levels

Agile methods are much better suited for reducing risk, especially for avoiding all-out failures. By concentrating on 'value level's you can always work towards useful products - in terms of user, or developer value. Value levels translate into milestones. Very commonly, we get the following milestones:

  1. Initial demonstration model (executable!)
  2. First actually usable 'system'
  3. First acceptable but no-so-luxury product
  4. Satisfactory, worthy product
  5. Great software
In agile you need a development toolbox that allows taking software onto higher levels all the time. Where Waterfall produced series of build-and-dump prototypes, Agile just goes on with the same executable model. This requires re-shuffling of activities.

Trust is key here. The users have to trust that the developers will always seek to optimize user value. Developers must make sure they always live up to that code of ethics. This is a question of integrity. For Agile team managers, integrity in of the team is one of the main issues. Team members with 'hidden agendas' or other sneaky ideas about how to work need to be expelled at all cost. I can't stress that point enough.

Risk reduction

Back to risk reduction. By striving to get these milestones ready as early as possible (usually whilst releasing early and often) you always head for systems that at least do something useful. There always is maximum user value at each point in time. After (1) you have a great tool to discuss what's needed with users, how things should 'look&feel', and so forth. For the software developers, it is even more important. Everything present should be working with a final system in mind. This gives the blueprint of the design/architecture concepts used for the product. After (2), users can do actual work with the system (in a Spartan sort-of-way). Next is a product that you could introduce without problems, albeit that there is a feeling of unease among the parties. Getting stuck at this level is often a question of budget/funding. After that, the only way is up.

Conclusion

Working in terms of value levels gives great risk reduction. People say that half of the software built anywhere never makes it to the work floor. Agile is the way to minimize that risk. No guarantees will be given up front other than 'we will make it as good as possible'. Live by that rule; always have the maximum user value in mind - that's what Agile is all about.

donderdag 20 oktober 2011

Pro-active vs re-active

If people have to tell you time and again that they don't like what they are getting, then you're not on the right track.

Can it happen? Of course. You can't figure out user satisfaction with certainty until you show them the goods. One of the fundamentals of Agile development. The thing is, lots of developers have trouble with two important ingredients: listening and preparing.

  • Listening: Rather than the narrow definition (using ears only) I also use that for 'reading carefully', and 'paying attention to signs'. Not only handling every detail, but also trying to understand why the user has come up with something. In e-mails, first of all make sure you react to everything brought up by the user. The 'old style' e-mail response works really well (interleaved quoting and answers). But good listening is much more than that.
  • Preparing: Agile requires lots of interaction with users. On the other hand, lots of user interaction is simply unnecessary. Not just because you could have figured it out yourself. Very often it's harmful. There are many things in life that need preparation, and sure as hell interaction with users needs careful preparation. I can think of hardly any case where I just go over to the users and start like 'please tell me what you want'. Do they know? They may think they do. Do you know what you have to offer? Probably not. Investigate.

zondag 16 oktober 2011

Following standards

Hey, I don't like standard methodologies. That doesn't mean I'm against technical standards.

Just answered an e-mail from a student at the University of Manchester. Tried to export a SEG-Y file in IEEE format from Petrel. The amplitudes were screwed up and he sent me the file. I was amazed to see that Petrel simply has the byte order wrong. Yes, the byte order is specified in Revision 1. And Rev.1 is over 10 years old now! (OK the official first version is from May 2002 - whatever). The byte order for IEEE (and IBM) floating point data is ... big endian. Not little endian. Live with it. For those who doubt it, here's the doc:



... how clear is that?






SEG-Y sucks. It's incredibly old-fashioned, outdated, inefficient and [fill in your favorite bad word here]. But with standards it's simple: follow them 100% or don't even pretend to follow them. As long as there is no real alternative, at least let's stick to the standard ... please ...?