Since coming across Jame’s post about Idiagram I’ve been thinking about how Marshall’s approach to complex problem solving and visual modeling might help contribute to solving corporate communication problems. One of my biggest frustrations in the workplace is poor communication. It destroys morale, reduces quality, kills teamwork, etc. No mystery to those of you who also understand the critical role that good communication plays in maintaining high performance teams. It would be interesting to apply Marshall’s approach, along with his visual modeling style, towards the corporate communication problem space, for both external (public) and internal (workplace) communication. How do you think the communication problem space could be visually modeled given the approach you’ve seen from Idiagram? If I’m feeling creative one day I may make the brave attempt to draft up a visual model for internal employee communication that encompasses things like:
- Speaking and writing clearly.
- Providing complete information.
- Credibility: your actions match your words.
- Clear and timely communication of issues.
- Responsiveness.
- Open communication at all levels.
The idea would be to illustrate how these communication characteristics tie into high performance teams, professional development, and profitability.
Did you know that the birth of the waterfall software development methodology is a thing of irony? I was working on a presentation on agile software development when I looked deeper into the history of the waterfall methodology. Dr. Winston Royce first developed the waterfall methodology in 1970 in a paper entitled “Managing the Development of Large Software Systems“. In his paper he first introduces the waterfall approach and then states that it is ”...risky and invites failure“. Royce then proceeded to propose an iterative model as an improvement on his initial waterfall suggestions. Ironically, despite Royce’s own criticisms of a waterfall approach, the industry chose to adopt waterfall, and ignore his superior iterative methodology. You can read more details here.
I was recently in a meeting to discuss and help refine my company’s solutions approach when I mentioned the importance of having a “zero feature release” (ZFR). Some people in the meeting were not familiar with the meaning of a ZFR. I went on to explain that a ZFR is essentially the release of the project’s first iteration that includes all components of the project’s architecture and infrastructure (or as many as possible), but “no features”. Why is this so important? Because highlighting and addressing architectural issues early, is significantly easier than addressing them during later release stages. Leaving core architectural pieces to later release stages can dramatically increase project risk in terms of time, quality, and costs.
A couple of quotes from Kent Beck’s book Extreme Programming Explained highlight the focus of the first iteration:
…the first iteration must be a functioning skeleton of the system as a whole… For the first iteration, pick a set of simple, basic stories that you expect will force you to create the whole architecture. Then narrow your horizon and implement the stories in the simplest way that can possibly work. At the end of this exercise you will have your architecture.
(Beck 113)
The first iteration puts the architecture in place. Pick stories for the first iteration that will force you to create ‘the whole system,’ even if it is in skeletal form.
(Beck 134)
Deployment and configuration issues (like architectural issues) must also be identified as early as possible. Too often, deployment and configuration issues arise later in the project lifecycle creating project delays, increasing costs, and risking the quality of the deliverable. Therefore, in addition to an architectural focus, a zero feature release must also be focused on validating the deployment and configuration of the system.
