Making Tangible The Intangible
Thomas M. Cagley Jr
An audio version of this blog post can be found on SPaMCAST 37 (www.spamcast.net).
It is a rare that the ideas espoused by an interviewee end up affecting me to the point that I need to incorporate them into the essay that accompanies their specific interview. The gestation period is typically longer at least by a week this stuff was just way to powerful. The essay for this cast reflects concepts espoused by Phil Armour in SPaMCAST 36 and Kenji Hiranabe in SPaMCAST 37 (the current cast for those of you reading this on my blog). The confluence of concepts that so moved me begins with the Kenji’s comments on the intangibility of both software and the processes (the process being both intangible and opaque) used to create software unless, of course, you are in the IT business. In SPaMCAST 36 Phil Armour put forth the thought that software was a container for knowledge. Knowledge is only tangible when demonstrated or, in software terms, executed. All of this discussion boils down to a product built to harness knowledge, using what is perceived to be an intangible process. This process is only full recognizable for the brief period that it executes. On top of all of that, there is every expectation that the delivery of the product will be on-time, on-budget, have high quality and be managed and orderly. No wonder IT managers have blood pressure issues!
Intangibility creates the need for managers and customers to apply controls to understand what is happening in a project and why it is happening. The level of control required for managers and customers to feel comfortable will cost a project time, effort and money that could be better spent actually delivering functionality (or dare I say it, reducing the cost of the project). Therefore finding tools and techniques to make software and the process used to create software more tangible and while at the same time more transparent to scrutiny, is generally a good goal. I use the term “generally” on purpose. The steps taken to increase tangibility and transparency (boy, doesn’t that sound like an oxymoron) need be less invasive than those typically seen in command and control organizations. Otherwise, why would you risk the process change?
Agile projects have leveraged tools like WIKIs, standup meetings, big picture measurements and customer involvement as tools to increase visibility into the process and functional code as a tool to make their knowledge visible. I will attest that when well defined agile processes are coupled with proper corporate culture, an environment is created that is highly effective for breaking down walls. But, and as you and I know, there had to be a “but”. The processes aren’t always well defined or applied with discipline and not all organizational cultures can embrace agile methods. There needs to be another way to solve the tangibility and transparency problems without resorting to draconian command and control procedures that cost more than they are normally worth.
In his two SPaMCAST interviews, Mr. Hiranabe has laid out two processes that are as applicable across the perceived divide defined by waterfall and agile projects. Last year in SPaMCAST 7, Kenji talked about mind mapping. Mind mapping is a tool used to visualize and organize data and ideas. Mind mapping provides a method for capturing data concepts, visualizing the relationships between them and in doing so making ideas and knowledge tangible. In the current SPaMCAST Kenji proposes a way to integrate kanban into the software development process. According to WIKIPEDIA, “Kanban is a signaling system to trigger action which in Toyota Production System leverages physical cards as the signal”. In other words the signal is used to indicate when new tasks should start, and by inference, the status of current work. Kenji does a great job at explaining how the kanban can be used in system development. The bottom line is that the signal, whether physical or electronic, provides a low impact means of indicating how the development process is functioning and how functionality is flowing through the process. This increases the visibility of the process and makes it more tangible to those viewing from outside the trenches of IT.
Code that when executed does what was expected is the ultimate evidence that we have successfully captured knowledge and harnessed it to provide the functionality our customer requested. The sprint demos in SCRUM are a means of providing a glimpse into that knowledge and to build credibility with customers. However if your project is not leveraging SCRUM, then daily or weekly builds with testing can be leveraged to provide some assurance that knowledge is being captured and assembled into a framework that functions the way that you would expect. You should note that demos and daily builds are not an either/or situation. Do both!
The lack of tangibility and lack of transparency of the process of capturing knowledge and building the knowledgeware we call software has been a sore point between developers and managers since the first line of code was written. We are now finally getting to the point where we have recognized that we have to address these issues; not just from a command and control perspective, but also from a social engineering perspective. Even if Agile as a movement was to disappear tomorrow, there is no retreat from integrating tools and techniques like mind mapping and kanban while embracing software engineering within the social construct of the organization and perhaps the wider world outside the organization. Our goal is to make tangible what intangible and visible that which is opaque.
