Layer 8
In 2004 a white paper titled, "Layer 8" circulated the NC State University campus IT groups generating a wide range of discussions. In the introductory section the paper labeled IT as a "tool that can either aid or hinder our progress" and proposed that it could be better leveraged by "sens[ing] the emerging realignment [of IT] and understand[ing] the direction in which IT is moving".
The proposal was well thought out: Recalibrating the process of integrating, purchasing, and developing IT to organizational goals. The approach was flawed in a number of respects. It attributed change to technology, not people. Key points in the rhetoric were later found to be tied to the interests of the individuals involved and not in any real requirements set forth by the community.
The views in this paper failed to account for risk as a natural part of adapting change. Instead risk and failure were attributed to poor alignment and poor accountability. A clear fear of risk and failure is expressed and "pilot projects" suggested as the remedy. Sources sited "blame" people for failure, propose higher levels of ceremony in processes. Change is viewed almost as a nemesis: if we don't get the jump on change, it will get us.
Layer 8 starts out with a nice premise: the human factor is the deciding factor in successful application of technology. If Layer 8 were true to this idea, the result would have been more in line with Agile thinking.
Agile methods were designed in highly competitive, risk driven environments: the corporate software development world. Considering this, it might seem that Agile methods are ill equipped to apply to academic IT environment. Nothing could be farther from the truth. All dynamic environments involve competition and this is particularly true in the academic IT environment. Agile methods are also iterative and the academic environment has built in iteration cycles, the semester.
Taking technology out of the picture for a moment, because Layer 8 is clearly written to push the agenda of decentralized computing which is a technology concern, the biggest takeaway message is: we need to communicate about what our organizational goals are and make technology decisions based on those. Meeting organizational goals is important, but there is another layer of success that is important to consider. Personal success, that is the collective success of individuals, is often the key stone to organizational success. Blaming individuals opting out of technology change is a coping mechanism for groups unable to implement technology in a fault tolerant manner. The right technology incorporates powerful rhetoric that either ensures success primarily through conversion and through administrative backing as a fall back.
Conversion means people willing adopt technology because it solves the problem as well if not better, a measure of personal success. Administrative backing means that the technology is aligned with organizational goals such that there is peer and supervisory pressure to embrace technology change. In this way administrative backing is a measure of organizational success.
There is a third form of success in Agile methods, but it is dependent on the to the other two: technical success. Technical success can only be achieved when personal and organizational success are also realized. James Shore and Shane Warden illustrate the overlap of these three forms of success as a traditional triquetra-esque vin diagram. In contrast, a more proper view of the relationship between these three forms is more spiral and in nature. That is to say that there are many ways we can succeed personally, independent of any level of organizational success or technical success. There may be a few ways we can succeed organizationally and not personally, but there are most successful organizational outcomes depend on personal success with or without technical success. Similarly there are even fewer ways to technically succeed that do not have some overlap with either personal success, organizational success, or both. The sweet spot is dead in the center of area where all three forms of success overlap.
Layer 8 would have been a better proposal if it had actually considered the human layer and not glossed over into the institutional and enterprise layer.
The proposal was well thought out: Recalibrating the process of integrating, purchasing, and developing IT to organizational goals. The approach was flawed in a number of respects. It attributed change to technology, not people. Key points in the rhetoric were later found to be tied to the interests of the individuals involved and not in any real requirements set forth by the community.
The views in this paper failed to account for risk as a natural part of adapting change. Instead risk and failure were attributed to poor alignment and poor accountability. A clear fear of risk and failure is expressed and "pilot projects" suggested as the remedy. Sources sited "blame" people for failure, propose higher levels of ceremony in processes. Change is viewed almost as a nemesis: if we don't get the jump on change, it will get us.
Layer 8 starts out with a nice premise: the human factor is the deciding factor in successful application of technology. If Layer 8 were true to this idea, the result would have been more in line with Agile thinking.
Agile methods were designed in highly competitive, risk driven environments: the corporate software development world. Considering this, it might seem that Agile methods are ill equipped to apply to academic IT environment. Nothing could be farther from the truth. All dynamic environments involve competition and this is particularly true in the academic IT environment. Agile methods are also iterative and the academic environment has built in iteration cycles, the semester.
Taking technology out of the picture for a moment, because Layer 8 is clearly written to push the agenda of decentralized computing which is a technology concern, the biggest takeaway message is: we need to communicate about what our organizational goals are and make technology decisions based on those. Meeting organizational goals is important, but there is another layer of success that is important to consider. Personal success, that is the collective success of individuals, is often the key stone to organizational success. Blaming individuals opting out of technology change is a coping mechanism for groups unable to implement technology in a fault tolerant manner. The right technology incorporates powerful rhetoric that either ensures success primarily through conversion and through administrative backing as a fall back.
Conversion means people willing adopt technology because it solves the problem as well if not better, a measure of personal success. Administrative backing means that the technology is aligned with organizational goals such that there is peer and supervisory pressure to embrace technology change. In this way administrative backing is a measure of organizational success.
There is a third form of success in Agile methods, but it is dependent on the to the other two: technical success. Technical success can only be achieved when personal and organizational success are also realized. James Shore and Shane Warden illustrate the overlap of these three forms of success as a traditional triquetra-esque vin diagram. In contrast, a more proper view of the relationship between these three forms is more spiral and in nature. That is to say that there are many ways we can succeed personally, independent of any level of organizational success or technical success. There may be a few ways we can succeed organizationally and not personally, but there are most successful organizational outcomes depend on personal success with or without technical success. Similarly there are even fewer ways to technically succeed that do not have some overlap with either personal success, organizational success, or both. The sweet spot is dead in the center of area where all three forms of success overlap.Layer 8 would have been a better proposal if it had actually considered the human layer and not glossed over into the institutional and enterprise layer.