Tech project metaphors: Ships & Waterfalls

Some stream-of-consciousness notes from a session held today at THATCamp Brisbane. The below input comes from all those attending the session – if you’d like your name listed here let me know.

The topic was Tech Project Metaphors: Ships & Waterfalls

* Metaphors are almost tangible things in tech, since we deal with electronic impulses in silicon, we use terms like “thread” and “loop” to describe what we build. Thus a metaphor is more than just an analogy, it is close to a reality.

* Good metaphors can help us deal with problems better.

* Metaphor “Build” software – this is an early metaphor. Writing program text into an editor, compiling it and then delivering it as an artifact was called “building”.

* type 1 and type 2 projects – type 1 has no users/customers, and has no/low community engagement; type 2 has customers/users and high engagement. engineers can think that type 1 projects are great because they do what they want without customers reporting problems. business owners/customers think type 1 projects are disasters/white-elephants because they cost money but deliver no value.

* Metaphor “Waterfall” process – now we have a specification – rows of binders full of documentation about how the software should be. Then we build what is described there, as before. This is problematic for customer figures who don’t see working software until the waterfall has gone down through a few levels.

* Metaphor “Beehive” – software engineers are in a nice environment (the beehive) where they are cultivated and nourished by the beekeeper who pays the $$$ to keep them. They produce software and the keeper scrapes the good stuff off the top. Google’s environment is like this, but of course if the stuff is not good, it dies quickly so there is motivation. The Google project “Knol” tried to be a better wikipedia, and it was a result of engineer driven requirements or beehive development – but because it didn’t meet the requirements of the Googling public it died; it was a type 1 not a type 2.

* Metaphor “Ship” – a journey, a team travelling and working together towards a common destination. Different roles – those on the bridge steer the ship, those in the engine room burn cash to drive it forward. On the bridge the team members need to set the course, plan waypoints and ensure they arrive at the correct destination (that is meet the customers requirements), while those in the engine room continue to drive the project forward by writing lines of code and putting implemented features behind them. Need to iterate, and communicate between the two groups to be successful. Clues and plans to steer the ship sucessfully are vital.

* From the ship we see procedural literacy can help those on the bridge to talk to the ones in the engine room.

* Pulling teeth needs to be done so that those who are not forthcoming with critical project requirement intelligence or information on risks (icebergs, reefs, unfavourable currents) do come up with that information. Means getting the engineers to come up from below and take the long view to point out what may be obvious to them.

* Boundary rituals are useful in marking the passage. Need to create ceremony around waypoints.

* Need to tokenise, gamify and make artifacts out of as much as possible in the project management so as to ensure that all those on the ship see the same things and understand the messages.

* The crew of the ship is an inter-disciplinary team. Communication is a key skill for all of them, but especially for those on the bridge.

Key problems – how to promote, value and improve communication between the members of the crew? How to bind them together so they feel part of the same “road trip” – not “us and them”? How to recruit team members who have skills in communication, problem defninition and navigation?