Alistair Cockburn
gave a talk at Agile 2009 about software development. He explains that developing software is about people making concrete ideas in an economic context. It is about people inventing, deciding, communicating, solving problems and creating solutions that they don’t yet understand and keep changing, expressing ideas in primitive languages to an interpreter unforgiving of errors, making decisions with limited resources and where every choice has economic consequences. All of engineering and team design patterns kind of fall into this definition.Next Alistair describes one pillar of software development as a cooperative game. Games have positions, moves, and strategies. Some are competitive like chess which is finite and goal-directed or poker which is open-ended. Others are cooperative like rock climbing which is finite and goal-directed, or jazz and music which are open ended games. Some fall in the middle like both like organizational survival and career management. These are infinite.
He explains that software development is cooperative, finite and goal oriented (funding model): 1 round is a deployment of the system. IT system is cooperative and open ended games. They live until we get tired of them, retire them, rebuild them or buy a commercial system. Product Line Management maps to infinite games. After one release 3.0, a competitor comes out with something new, and we follow our release with a .x release just to stay in the game and so on.
The game has two conflicts, to deliver the software and to setup for the next game by refactoring architecture, adding tests, making sure juniors are ready to lead, and adding documentation, etc. Both are competing for finite resources. Only three moves are allowed: invent, decide, and communicate. Also, the situations (almost) never repeat. The strategy that worked on last project, odds are it might not work on the next project. We have to always be alert.
Next Alistair states that we have to adapt to your situation based on the number of people to coordinate and the criticality to the application. Communication and control structure change and strategies, setup, conventions need to change accordingly. Face to face is the most effective form of communication. When there are question and answer the best form of communication is people at whiteboard, then people on phone, then people on chat. If there are no question and answer then best is videotape, then paper.
Alistair describes distance as expensive. If we assume that 2 programming in pairs communicating once every 20 minutes cost nothing then 12 people on same floor but in different rooms cost 100K/yr penalty in communication speed, and 12 people on different floors cost 300K/yr penalty in communication speed. People issues determine a project’s speed. Setup a project so people can detect when something is not right. They need to care enough do something about it and effectively pass along the information. Speed of the project is the speed of which ideas moves between minds (attitude and mechanics for communication).Next Alistair covers the second pillar which is software development is a Craft. Craft teaches us to pay attention to our skills and to the medium (UI: 2d surface + cognitive psychology, coder: programming language, PM: people). The major crafts are: deciding what to build (requirements), managing people and projects, modeling, designing the external view, large-scale design and architecting, find-scale design and programming, validating the work.
Alistair explains that people learn skills in 3 stages: Shu (learn a technique – copy, sample, context free), Ha (Collect techniques, learn context), Ri (invent/blend techniques).
The 3rd pillar is use of Lean Processes. Software development looks like manufacturing if the unit of inventory is the unvalidate decision (UI waiting on analyst decision, testers waiting on developer decisions). Software development has correction loops. Bugs fighting for attention with new work queue. One way is to have one dedicated person per day to handle feedback cycle. Lean aims for small continuous flow. Micro incremental development is the target with constant attention to queue size. Different processes should be used for different situations. Optimization is based on where there is a bottle neck (decision dependency network).
Finally, Alistair describes the last pillar as design is knowledge acquisition. He explains that waterfall is a late-learning strategy. Knowledge comes at the final integration. While in Agile, knowledge is gained with every iteration. Growth of knowledge (risk reduction) comes with early, continuous integration. In agile we need to develop for business value once risks are down (not necessarily highest business value 1st). We need to develop for partial business value and for partial lack of knowledge (tech stuff we need to learn more about). This gives us a choice to deliver by value or by date.
Alistair concludes that software engineering will use craft, cooperative game & lean principles. Craft is developing skills in a medium (Shu-Ha-Ri), cooperative game of invention is developing teamwork, communication, and strategies, lean processes is the use of small queues, cross-trained people, varied processes, and design as knowledge acquisition is early integration, and choice to deliver by value or date.
This presentation is available on InfoQ at http://www.infoq.com/presentations/cockburn-bury-not-praise-agile
