In the Software Process and Measurement Cast 37, Kenji Hiranabe suggested that both software and the processes were intangible and opaque. 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. Combining both ideas means that a software product is a harness for knowledge to deliver business value; delivered using what is perceived to be an intangible process. The output of the process is only fully recognizable and testable for the brief period that the code executes. On top of all that, there is every expectation that the delivery of the product will be on-time, on-budget, high quality and be managed and orderly. No wonder most development 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 more transparent to scrutiny, is generally a good goal. I use the term “generally” on purpose. The steps taken to increase tangibility and transparency 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 laid out two processes that are applicable across the divide defined by waterfall and Agile projects. In 2007 on 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 SPaMCAST 37, 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.
Executed code that 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.