Apply today for a FREE subscription to CIO Magazine!
Mon, May 21, 2007 20:37 EDT

|
Posted by: Michael Hugos in Best Practices Topic: ApplicationsBlog: Doing Business in Real Time
Current Rating: |
Your skill in using just six techniques in appropriate combinations to address different situations is the measure of your IT agility. I call these the core techniques. Just as a game like basketball is composed of a small group of core techniques such as dribbling, passing, guarding and shooting, so too is the game of developing information systems.
The skill levels of project teams can be measured by their capabilities in these techniques. By employing these techniques, a project team will always be able to produce competent (and sometimes even brilliant) results. These six techniques are a simple yet comprehensive set of skills that can be taught and mastered by people involved in building systems. These core techniques are:
1) Joint applications design (JAD)
5) Object oriented design and programming
6) System testing and rollout.
There are other techniques that may be relevant from time to time, but these six core techniques are always relevant in every situation regardless of the technology being used or the problems being addressed. The best practitioners of IT agility are competent in all of them and masters of some of them.
IT agility happens when people use creative combinations of these techniques to define, design and build solution systems for the challenges they face. The JAD technique is key for pooling the insights and ideas of business and technical people to define possible solutions. Combinations of JAD, process mapping, and system prototyping are key to further exploration of possible solution systems and creation of detailed system design specifications. Then building systems from design specifications calls for the techniques of object oriented design and programming and system testing and rollout.
These techniques are well known in the IT profession; they weren’t created yesterday. Do a web search on any of these techniques and you will find hundreds of references to them and many options for getting education and training in them. In IT agility, these are the basic skills of the game. It is possible to get a very accurate assessment of the chances for success of a project team on an agile development project (or any IT development project for that matter) by measuring their skill
I wouldn't add any to the list of six. I might change object oriented programming to service oriented programming.
Hi Madgreek65,
You raise a good point; yet is SOA really just a further evolution of Object Oriented techniques?
At this point I think that what we now call services in SOA are what we used to call objects; and objects have services right? We call these services by passing messages to them over the internet just like we call objects by passing messages to them over a LAN or through an operating system. Whether we are calling a piece of a bigger system or a chunk of program code it seems like it's still the same.
I think a person needs a solid grounding in OO techniques in order to really understand SOA. And then you see that they are essentially the same concepts just implemented in different environments.
I agree. At my shop, we started with objects, evolved to components, and then evolved to services. Regardless, you hit the nail on the head with the 6 steps. Good post.
Micahel,
great article, as usual.
I don't like very much the word "prototyping", talking about agility. Yes you wrote about evolutionary prototyping that's, in my opinion, the right way but the word prototyping could be misleading.
I believe there can be 'spikes' (defined amount of time devoted to analyze something unknown for the project team) + delivered working stuff: good design, fast feedback, scope reduction, requirement splitting can lead to NO prototyping.
PierG
http://pierg.wordpress.com
Hi PierG,
You point out something that I would like to expand on. The word prototyping can indeed be misleading. For prototyping I linked to a slide presentation created by a professor at University of Southern California. He talks about two types of prototyping - "evolutionary" prototyping that progressively delivers working systems; and "throw-away" prototyping that is just used to illustrate a user interface and that is then not used as part of the deliverable system.
I believe that evolutionary prototyping is the way to go. In IT agility I don't believe there is any need (and not any time either) to do throw-away prototyping; althought I know that many people think of prototyping as meaning the throw-away kind.
I agree with your idea of "Spikes" to use a small, defined amount of time to analyze something unknown and deliver a working solution. In this model the "prototype" is actually the delivered working system that comes out of the spike. So in that sense there is no prototyping as an independent activity different from developing the working system.