03 Agile - Through the Looking Glass

This web page is associated with a book called called Hermeneutics in Agile Systems Development.

The book can be bought at: https://play.google.com/store/books/details/Dr_Jerome_Heath_Hermeneutics_in_Agile_Systems_Deve?id=mi6VBQAAQBAJ

The book gives a more complete explanation of these issues and includes a number of related topic discussions. The combination develops the understanding of the concepts of Agile software development.

Agile Through the Looking Glass

How does agile look through the looking glass? The structured methodology liked the idea of a black box. That was the ultimate in information hiding. Agile likes to have an open, visible, and communicating process. The goal is that everyone is part of the whole process, because the parts are in communication with each other. That does not mean a programmer would not program a black box. It does mean that a black box and its use will be clear to everyone who uses it.

With structured methodology, the structured documentation was to fill the communication gap. But the documentation was massive, cryptic, unreadable and unread. My father brought these documents home. I supposed he intended to read them or at least try to read them. As I taught systems analysis with the structured methodology I realized that the documentation was not meant to develop the project technically. The documentation was to cover the rear of the developers. The document had to provide every excuse possible in case the project failed, which it often did.

The visibility of an agile project (if done right) guarantees the project will be visible to the users or customers as well. The app process as a whole is not a black box to the developers, nor is it a black box to the customers.

After being taught the structured methodology I was fascinated by the fact that much of the code I was producing was to develop things the customer needed like useful formatting, lining up forms and report data so it made sense, adding features that add value that was asked for by customers. Every once in a while I needed to program a function. The app needed a square root or a square function. The rest of the time the problems were not about function.

Ultimately, my context calculus relates to his visibility. Visibility can take on different modes: line of sight access, communication, scum meetings, sharing work results as soon as they are meaningful, rapidly adding small features, and having a department party now and then. Of course at our parties Tom would bring the Habanero sauce. But he was the only one in the group who could use it.

In agile features seem to grow out of the process. Customers need applications that do expected things. When the results produced by the structured methodology are unexpected then the user cannot use those apps no matter how functional they are. Agile is specifically tuned to avoid this kind of problem. The user specifies the features they want and how they want them to work. Of course the developer has to create real features, but the feature needs to fit as close as possible to the user’s requests. I have found that formatting the screen and formatting the data on the screen was at least 90% of my job as a developer. Developing the perfect algorithm is fun, but the customer wants formatting.

The timing of the development and the timing of the parts of the app to each other is also important to the customer. Rapidly adding small features give the customer some use of the app and that use will be expanding so the customer can evaluate and comment on the progress. The timing also has to do with the apps ability to function in the time frame of the customers who are using it. Understanding these time constraints requires a lot of communication with the customer, particularly as the customer has seen some features and can associate those features with the real world of their work. I always felt that this part of an app requires imagination and quite skillful programming. Because of all the skill you use in the process it hurts a little when the customer does not like what you did. This is where agile needs to be ego-less programming.

Ultimately the goal of an app needs to be to make the customer more capable of doing their job. The relatively intense and long standing discussions with customers help to guarantee the app will improve the things the customer feels they need improved. There are points when the developer hedges. The customer tells you what they want and how they think it can happen, but you sense something (intuition or experience) that they really need. This is where the process of adding small increments to a project can help. Discussing small features aimed in the direction the customer wants can result in clearing up exactly what the customer wants and needs, and provide a path towards the goal needed.

Hermeneutics in Agile System Development

Dr. Jerome Heath