1. Software Creation Communication Agile Principles applied to software projects

2. Silos of Knowledge Computer ScienceBusinessBiologyPhysics PhilosophySociologyPsychologyEtc., etc., etc. Craft, Community, Pride, Learning, Creativity, Communication, etc. Efficiency

3. Agile Manifesto Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. http://agilemanifesto.org/

4. Authors of Agile Manifesto Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas Note: Most of this presentation is based upon the work of Alistair Cockburn’s Agile Software Development

5. Is creating software… Engineering? Science? Art? Development? Construction? Something else? Does it matter?

6. It does matter! The way we think about anything is constrained by The mental frames we use Frames trump facts. Frames will stay and the facts will bounce off. -George Lakoff The language we use to describe it (connotations) Tax relief vs. tax deferment Death tax vs. inheritance tax Actions and results CAN differ depending on your viewpoint!

7. When we experience something, we parse it into separate, meaningful chunks When we parse according to one pattern and later put the pieces back together, we get a distorted, simplified result! Parsing Experience OR ?

8. Conclusions… Any complex shape can be parsed according to different patterns Our perception of “what is there” proceeds in different directions depending on how we separate elements What we notice is biased by the vocabulary we start with

9. Impossibility of Communication? Information received is determined by what happens inside the receiver, not just the information the sender is trying to impart Stimulus: Yell “Fire” in a crowded theater Response A: someone hears, and exits safely Response B: someone hears, and panics Response C: someone is asleep, and doesn’t hear Response D: someone doesn’t speak English, and doesn’t understand

10. Impossibility of Communication? Communication is NEVER perfect and complete The more a person is different from you, the SMALLER the communication gap he can jump No matter how much you back it up, there is ALWAYS someone who will not understand.

11. Impossibility of Communication? From Steve McConnell, Rapid Development

12. We can never hope to completely specify the requirement or the design Experience, Explicit Communication The Golden Rule: The task on a project is not to try for complete communication, but to manage the incompleteness Conclusion…

13. Levels of Listening Level 1: Following Need explicit procedures/instructions Detailed manuals and documentation provide safety RUP – Rational Unified Process Level 2: Detaching Can adapt procedures to the situation Understands where procedures break down The Art of Computer Programming Level 3: Fluent Irrelevant if following a procedure Understands the desired end effect and will make it work despite process or tools The Pragmatic Programmer

14. Levels of Listening The Zen of Level 3…. “Do whatever works” “When you are really doing it, you are unaware you are doing it” “Use a technique so long as it is doing some good” To someone fluent – makes sense To someone detaching – confusing To someone following - useless

15. Conclusions… Consider the level of your team Is it following, detached, or fluent? Is it some combination of the three? The mystery is that we can’t get perfect communication. The answer to the mystery is that we don’t need perfect communication! Remember the Golden Rule: manage the incompleteness. That is, you just need to get close enough, often enough.

16. Think Outside the Box Let’s compare software development to…a group writing epic poetry together!

17. Think Outside the Box Who are the players? The people who ordered the poem Key poem designers Began as a one person project, but the poet, in usual fashion, promises MUCH more than she can deliver! So, adds other people fairly good at poetry, and takes the role as ‘lead’ poet Still can’t get it done, so now they get desperate – they add friends and neighbors, beginners NOT good at poetry!

18. Think Outside the Box As more people are added, many of whom are inexperienced, communication and coordination becomes a HUGE problem One person was good at descriptive passages, one was good at the gory bits, etc. The lead poet is now so busy coordinating and checking, she no longer has time to write poetry! A couple of people wrote pages and pages of material describing the antagonists, way more than needed – that is the part they liked writing about. Another few people kept revising and revising, never satisfied with their work

19. Think Outside the Box As time progressed, the group got desperate and added even MORE people. Communications were horrible, no one had a current copy of the poem, and no one knew the actual state of the poem

20. Conclusions… What does this say about software development? Almost every project of any size has temperamental geniuses and average or below workers, hard requirements, and communication pressures. Why do we expect software development to be any different from group epic poetry writing?

21. So Then, What is Programming? Normally thought of as… Solitary Inspiration-based Logical activity But it is ALSO… A group engineering activity Mathematical A craft A mystical act of creation It’s creation is sensitive to tools, but its quality is independent of tools