Montreal Xp Tools Presentation

Target audience: MontrealXpUsersGroup. Format: 20 minutes lecture at 19h15 november first. Then open discussion. Expected number of people: around 10. Please be there at 19h00 so we can begin at 19h15! ;-)

• Includes: Physical setup.
• Reminder: Value the Individuals and interactions over processes and tools.
• Goals: To foster, to encourage to use of new tools or to use a tool a "better" way.
• Intro: Appropriate use of tools, Tools vs pratices, Tools as physical tokens, when reinventing the wheel.
• Core: Values, Practices, Feedback loop, Physical Environment.
• Conclusion: Explore and choose, let tool emerge, travel light.

---

Summary

• Tools are shaping the working environment. They are not only means to an end, but facilitators and inhibitors of human activity. The way we set up the working environment will influence the way we work. We should not underestimate this fact and learn to take advantage of it.
• We should look for tools that support XP values:
  • communication, through open tools that favorise awareness, transparency and empathy.
  • feedback, by using adequate tools that will favor appropriate and reliable answers from both the team and the machine. (see comparison between unit tests and bugs database)
  • simplicity, through light tools that will support the programmers' activities rather than increase the load of work and divert attention from the project.
  • courage, through tools that will help the team to make confident decisions over foolish ones.
• Interesting tools
  • Development / Integration Workstations (#dev/2+1)
  • Ide / Compiler / Debugger / (Profiler)
  • Automated Acceptance / Unit Tests framework,
  • Version Control
  • Build Script
  • refactoring Browser
  • Coding Standard reinforcement / Coding help
  • Wiki
  • Index cards, whiteboards, giant post-it
  • Photocopier / Scanner, Camera (Backup for whiteboard, index cards, ...)
• Setting up the environment
  • The War Room: OpenSpace / Radical Collocation, Walls, PP tables

---

JeanPhilippeBelanger also suggested to use white vinyl sheets applied on walls, it is less expensive that whiteboards.

Something we have done in past projects is to get strips of plastic and apply magnets to the back of them. Then use them on a whiteboard that has a magnetic background. This way you can have "permanent" and "temporary" information. The strips can be used as CRC Cards or User Stories or whatever and the whiteboard can be used for project notes or velocity, etc. -- IainLowe

---

Index cards:

• Main
  • Structure of lecture
  • XP Practices
  • XP Feedback loop
  • XP Values
  • XP Tools Virtues: openness, support, reliability, confidence
  • Drawing of physical setup
  • Tools: Development / Integration Workstations (#dev/2+1)
  • Tools: Ide / Compiler / Debugger / (Profiler)
  • Tools: Automated Acceptance / Unit Tests framework,
  • Tools: Version Control
  • Tools: Build Script
  • Tools: Refactoring Browser
  • Tools: Coding Standard reinforcement / Coding help
  • Tools: Wiki
  • Tools: Index cards, whiteboards, giant post-it
  • Tools: Photocopier / Scanner, Camera (Backup for whiteboard, index cards, ...)
  • OpenSpace / Radical Collocation, Walls, PP tables
  • Private space
• Misc. (Just in case)
  • Ideas
  • Development Life cycle (client / dev, define, estimate, choose, build value)
  • Agile Principles
  • DTSTTCPW, DRY / OAOO, YAGNI, Worst Thing First, CodeUnitTestFirst
  • Variables: Cost, Time, Quality, Scope

---

See Also: Bug tracking issue: Extreme Programming Installed p.165. Advanced Issue: Defect Databases. p. 169. Advanced Practice Tests as Database

See Also: ExtremeTools, RadicalCollocation, War Room, OpenWorkspace, http://www.c2.com/cgi/wiki?search=tools

---

 Tools as support mechanism for the Values and Practices of XP

XP Values

• Communication
  • with clients, departments, team members, ourselves.
  • person to person
    • index cards
    • whiteboards
  • computer-mediated:
    • collaborative documents (wiki)
    • bug tracker
    • prototypes
    • version control
    • source code
  • Question: When to use low tech tools vs hi tech tools?
    • (L+) When communicating with other people: they're intuitive and we need to fill the gap through interacting with people (the RTFM syndrome is symptomatic of the gap being closed through the availability of user manuals).
    • (L+) When we want to keep knowledge between individual and not stored away in a project file.
    • (L+) When we don't want to leave a memory of the past.
    • (H+) When we need to make something evolve into something else (ex: source code).
    • (H+) When we need to be able to go back in time (ex: version control).
    • (H+) When we need to maintain detailed information about something (ex: knowledge base).
  • Conclusion (?): Low tech tools and hi tech tools complement themselves. HT works well when we have to build something, externalize knowledge and maintain detailed information about the status of a project (Acceptance Tests gives a true status of what has been done) ; LT put the emphasis on people and how they share, understand things and appropriate knowledge without having to "point their fingers at books" -- they're good at simplification.
• Feedback
  • from machine, client, team members, departments...
  • programming
    • profiler
    • unit testing
    • acceptance testing
    • debugger
    • bug tracker
  • point: where do you get your feedback from? Get the most reliable source (acceptance tests vs bug tracker). A word on competition between tools and the importance of choosing the right tools early in the project.
• Simplicity
  • question: how can tools help us travel light?
  • automation: let the machine do it for us
  • experimentation (sand box): let's play with the solutions to start with and dismiss the complex ones before we really implement something
  • idea: tools also have user requirements. The costs of listening to an inappropriate tyrant (ex: Microsoft Project).
  • should we use our tools in the simplest way possible?
• Courage
  • idea: courage to try out new tools; encourage everyone to experiment with a single tool each month and report on it.

XP Practices

• Planning Game
  • Emphasis on human interaction through low tech tools: index cards, white board, giant post-its,... Physical objects as an intuitive token of project scope (could this actually help prevent featuritism?) Can a tool like MS Project be dangerous?
• Small Releases
• Metaphor
• Simple Design
  • sandboxes
• Testing
  • unit testing, acceptance testing, profiler. Is testing ideally done all with tools?
• Continuous Integration
• Pair Programming
  • Physical tools prevent task switching (because the computer is busy), they're readily accessible, more flexible and less cluttered with information than dynamic tools.
• Collective Ownership
  • wiki, version control.
• Refactoring
  • refactoring editor / browser.
• 40-Hour Week
• On-Site Customer
  • Prototypes, maps, physical tokens can be more expressive of scope than huge boring files. How do we bring some of the advantages of physical tokens to the online world if we never meet out customers face to face?
• Coding Standards
  • SelfDocumentingCode environments? Automatic code formatting IDEs?

 A word on tools and people: Environment Engineering

• (discuss) It's a matter of setting up and environment and taking good advantage of existing resources through our own abilities.
• (discuss) People will fill the gap left open by our tools. Do we want to fill in this gap ourselves?
• (discuss) Each tool is best supported through its own range of practices. Should we prevent ourselves taking full advantage of a tool in favor of more important practices?

---

Ideas here.

• Software development:
  • IDE,
  • version control system,
  • local version control system (?),
  • debugger,
  • refactoring editor / browser,
  • profiler (a word about Optimization...),
  • unit testing framework,
  • acceptance testing framework,
  • build and release script,
  • bug tracking system
• Machines:
  • Integration / Build machine (may serve as web server wiki host)
  • Development machines (code in pair)
  • Individual machine (mail, browse, other explorations)
• Physical setup:
  • Table for pair programming, (a word about physical location of tables)
  • Index cards,
  • Giant Post-it,
  • whiteboards, corkboards,
  • openworkspace,
  • Walls (for displaying artifacts)
  • "Common" private space...
• Others (a word about drawbacks of the optional stuff)
  • Scanner (to backup index cards)
  • Still camera (to backup whiteboards / corkboards)
  • Camera (to backup discussion and meeting)
• A WikiWeb
• Should we include Standup meeting as a tool?
• A word about using the same tools within the team.
• Low tech tools as physical tokens
• Low tech tools as (human) interaction tools

---

Looking for...

• Visibility
  • Whiteboards
  • Giant Post-it
  • Corkboards
• Traceability
  • Giant Post-it
  • Index cards
  • Wiki (Yes: It's written down, no it's organic)
• Non-blocking
  • Index cards (while pair progamming, the non keyboarder can jot down ideas on cards)
• Emergence
  • Wiki
  • Whiteboards
  • Code
• Automation
  • Unit tests
  • Acceptance tests
  • profilers
  • code generators
  • ...?

---

Random questions and thoughts...

a) childish metaphysics for the philosophically inclined (incomplete)

• what is a tool:
  • a means to do something
  • a working environment
  • a toy (?)

• what can a tool do for us?
  • simplify
  • accelerate
  • automate
  • do what we're not good at / hate doing
  • helps us communicate
  • store and archive work

• what a tool should not do
  • distract
  • complicate

• what are the costs of using tools?
  • opacity (we don't always see or understand what's going on 'underneath')
  • maintenance
  • dependency (personal and technical compatibility)
  • may destroy relationship (e.g. mail flame)

• what should we be looking for in a tool
  • is it appropriate?
  • is it intuitive?
  • does it produce good work?
  • does it conforms to standards? How wide is it supported?
  • build trust among people
  • encourage human interaction

• what should not be looking for in a tool
  • a way to not interact with the other people

b) tools-related issues

• how to find the good tools and decide to implement the good ones
• getting people to use those tools / making the transition
• know your needs, choose your tools for your needs, not more
• good attitude to develop

---

MontrealXpUsersGroup