Thinking

Pair Programming - Increases brainpower and improves software quality. Driver works on code, while navigator thinks of big picture and design/architecture. Roles should switch every half hour.

Energized Work - People are motivated. Work life balance, clear statement of why project is important, mitigate meetings, and socialize out of work.

Informative Workspace - Information/status of project posted all over the room.

Root-Cause Analysis - Don't blame people, blame the process. Ask why 5 times. Don't add overhead if problem not systematic.

Retrospectives - Continoually improve process. Iteration retrospectives occur 1 hr weekly. Release, project, & surprise retrospectives occur on ad-hoc basis. 4 steps:

  1. Norm Kerth's Prime Directive - "Regardless of what we discover today, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand" (write it on board, and have everyone agree).
  2. Brainstorming - 30 min - Each person writes 5-10 good/bad on index cards, and reads out loud.
  3. Mute Mapping - 10 min - Nobody speaks, group related index cards, name the category, and vote which ones to improve next iteration
  4. Retrospective objective - 20 min - do root-cause analysis to fix categories chosen

Collaborating

Trust - Team trust and organizational trust (impressions). Team thinks "us" and not "them." Team trust strategies:

  1. Customer-Programmer Empathy - customers think programmers don't care of deadlines/neets, programmers provide estimates that customers yell at - sit together, retrospectives & energized work help
  2. Programmer-Tester Empathy - programmers don't respect QA, and QA have mission to shoot down programmers work. Developers - thank QA for catching issues, Testers - focus on great product.
  3. Eat Together - breaks down barriers
  4. Team Continuity - Don't break up teams after projects, see team as a single resource.
Impressions - organizational trust strategies:
  1. Show Some Hustle - Energized work, informative workspace, reporting, & iteration demos - sense team is working hard.
  2. Deliver on Commitments - Results - working software & delivering on commitments. Iteration demos and releasing on schedule.
  3. Manage Problems - Let stakeholders know, provide analysis and solutions to them - builds trust.
  4. Respect Customer Goals - Communicate with them on difficult technical challenges; take their ideas and help write a store (index card)
  5. Promote the Team - Be open - invite to iteration demos, hold brownbags, describe the process

Sit Together - Improves communication and mitigates misunderstandings. Stops guessing, everyone can hear conversations.

Real Customer Involvement - In-house development - involve everyone (executive/stakeholders), outsourced development - meet customer in-person, vertical-market development - 1 PM gathers real customer needs into single vision, horizontal-market - 1 PM, usability studies, beta builds, focus groups.

Ubiquitous Language - Programmers should speak in language of domain experts/customers. Code should represent domain concepts.

Stand-Up Meetings - Inform team members where everyone is. Do it right before lunch. 30 seconds per person (provide status). Issues/details should be discussed off-line.

Coding Standard - guidelines for all programmers to adhere to.

Iteration Demo - Concreate demo of work, stakeholders happy to see. Forces weekly deployments. Go through stores 1 at a time & demo. Write feedback on index cards. Meeting should be 10 min. Ask stakeholders 2 questions: (1) Is our work to date satisfactory?, (2) May we continue?.

Reporting - For upper management & stakeholders. 2 types - progress reports and management reports. Progress reports - roadmap (slide desk of planned releases with features), status email, & iteration demos. Management reports - Defects, time usage

Releasing

done done - Stories ready for production each iteration. Partially completed stories not done done, and add hidden cost. Criteria:

  1. Tested - all unit/integration/customer tests finished
  2. Coded
  3. Designed - code refactored as desired
  4. Integrated - UI to database
  5. Builds
  6. Installs
  7. Migrates - database schema scripts
  8. Reviewed - customers reviewed story and confirms expectations met
  9. Fixed - all bugs fixed or scheduled in stories
  10. Accepted - customers agree story is finished

No Bugs - No QA cycle. Traditional approach - find and fix bugs. Agile approach - generate few bugs. Change attitude focus on no bugs. Consider having no bug database (perpetuates this attitude.) Achiving nearly zero bugs:

  1. Write fewer bugs - TDD - creates test suites & structures code into small, easily verifiable steps. Pair programming. Customer tests - ensures requirements correct. Exploratory testing - find edge cases.
  2. Eliminate Bug Breeding Grounds - use slack each iteration to pay down debt in old code
  3. Fix Bugs Now - Longer you wait to fix a bug, the more costly it is. Automate test and fix bugs immediately. Understand why it occurred (is this systematic problem?), and discuss in retrospective.
  4. Test Your Process - Exploratory testing uses intuition and experience to find problems. If exploratory testing finds a bug, there is a whole in your process, fix the bug, then fix the process.
  5. Fix Your Process - Root-cause analysis and process improvement on every bug. Randomly pick a bug if too many bugs.

Version Control - Check-in only code that builds and passes. For each iteration, tag as iteration X. For each release, as release X. Branches shouldn't be necessary.

Ten-Minute Build - Build should be 5-minutes. Automate everything (registry settings, db schemas, processes, etc...). Ensure 100 unit tests run per second. Only 10% tests should be integration tests. Reduce build time so incremental builds not necessary.

Continuous Integration - Hidden costs include merging, creating installer, database pre-population, etc... CI keeps all code integrated with building release infrastructure. Two things:

  1. Integrate your code every few hours
  2. Keep build, tests, and other release infrastructure up-to-date
Make preparing for a release an ordinary experience that actually releasing is a non-event. Leverage the CI integration script process (ensures what works on your computer works on any). Need 1 spare dev box and a integration token (rubber chicken): To update from repository
  1. Wait till integration token is available (someone is checking-in unproven code).
  2. Get latest changes from repository, and don't let anyone take the integration token.
To integrate
  1. Update from repository (do previous steps)
  2. Get integration token, & check-in code
  3. Go to integration machine, get the changes, and run build & tests.
  4. Replace the integration token

Collective Code Ownership - Everyone owns all code, no system owners. Take pride in team's code and improve. Developers work in different areas everyday (since tasks change everyday).

Documentation - Face-to-face communication emphasized, so no formal documentation. User manuals, API references, & reports - should be scheduled as a story.

Planning

Vision - 1 page document: (1) what the project should accomplish - the opportunity that the project will address, (2) why it is valuable, (3) and success criteria. Post this on informative workspace - so everyone knows why our work is important and how we'll be successful.

Release Planning - Developers must work on 1 project at a time (15% cost with context-switching). Here is how to release plan:

  1. Decide release dates (e.g. 1/month)
  2. Leverage vision to brainstorm minimum marketable features. Decompose into specific stories, and work with programmers to get estimates. Prioritize stories, so highest-value, lowest-cost stories done first.
  3. Final list of stories is release plan - put features w/stories on whiteboard
To reduce waste, plan at the last responsible moment - last m oment at which you can responsibly make a decision. The further away the event, the less detail the plan needs. Here are good starting points:

The Planning Game - Programmers know cost. Customers know customer value. Need to maximize value and minimize cost. Programmers - they estimate. Customers - they prioritize. Game:

  1. Anyone creates a story
  2. Programmers estimate the story
  3. Customers place story into the plan in priority order
  4. Repeat above steps until all stories estimated and in plan
Result - single list of stories in priority order.

Risk Management - Generic risk multiplier - x1.4 - x1.8 (for XP done done projects only). For project specific risks, create a risk census - list of risks:

  1. Gather whole team and hand out index cards
  2. Ask for risks & brainstorm scenarios leading to risks
  3. Let remainder of team go back to tasks
  4. For each risk, (1) estimate probability - high, medium, low, (2) determine impact - dollars lost, days delayed, etc...
  5. Ignore unlikely risks with low impact
  6. For each risk, decide: (1) avoid by not taking risky action, (2) contain it with risk multiplier or more time, (3) mitigate by taking steps to reduce impact
  7. For those you will handle: (1) determine transition indicators - objective, (2) mitigation activies - stories that happen regardless of whether risk happens - add to release plan, (3) contingency activities - only necessary if risk comes true, (4) risk exposure - time/money to set aside to contain risk (see book).
Every week, review risks and check tranition indicators. Write on yellow cards and put on release planning board. Assign someone to monitor them.

Iteration Planning - Counter risk of tendency for work to take longer than expected. Iteration planning should take 1/2 hr - 4 hrs (by lunch should be done).

  1. Take all stories done done and add up original estimates = story points
  2. Customers select most important stories from front of release plan that add up to velocity - should take 10-15 min
  3. Everyone leaves except programmers
  4. Break down stories into engineering tasks (e.g. add db table, create UI form, update build script). Each task should take 1-3 hrs to complete. Put on index cards & discuss.
  5. Estimate each task on each card
  6. Add up estimates and ensure it equals last iteration. Adjust as necessary
  7. Hold commitment ceremony with everyone, and ask if each person commits to getting stories done
  8. Put stories and corresponding tasks on iteration planning whiteboard
When you work on a task, take it off the board (put your initials there), and put it back when completed and circle with green marker. For emergency requests, create a story, and replace one of the existing stories.

Slack - Every project needs slack. This is important for consistently meeting iteration commitments. Schedule important work that isn't time-critical:

  1. Paying down technical debt
  2. Research time for developers

Stories - 1-2 line descriptions of work team needs to produce. Placeholder for detailed requirements. Criteria:

Write stories on index cards. Additional details: Hints on combining/spliting stories:

Estimating - Estimate in ideal time. Estimates are consistant in aggregate (interruptions tend to be consistant). Velocity is # of story points (engineering time) you can accomadate in an iteration. When calculating velocity, don't include stories not done done. To improve velocity, (1) pay down technical debt, (2) improve customer involvement - ensure they are available to answer questions, (3) Shield programmers from interuptions.

Developing

Incremental Requirements - Face-to-face communication is most effective. Work on requirements incrementally, in parallel with rest of team.

Customer Tests - Created by customers, these are examples of domain rules that programmers turn into automated tests.

TDD - Rapid cycle of testing, coding, & refactoring. Improves design & interfaces. TDD verifies that the code does what you think it should do. Focus is on behavior, not implementation. Each test should take under 10 seconds to run. Test categories: (1) Unit tests - focus on class/method, are entirely in memory, (2) Integration test - test that causes code to talk to db, communicate to network, touch the file system; each integration test should run entirely on its own. Ensure you don't need too many integration tests, otherwise you have a design problem. (3) End-to-End test - brittle, very slow - use exploratory testing instead.

Refactoring - Process of changing the design of your code without changing behavior. What it does stays the same, but how it does it changes.

Simple Design - Rather than anticipating changes/providing extensibility hooks, create a simple design that anticipates little as possible. Limit public interfaces.

Incremental Design & Architecture - Create a simple design that solves the problem you face at the moment. Don't generalize. The second time modify the design to make it more general to solve the two problems you need to solve. The third time, generlize it further. Keep your design simple and focus only on the features it currently supports. Implement future changes when only needed.

Spike Solutions - A spike solution is a technical investigation, a small experiment to research the answer to a problem. Write test code to do a spike solution.

Performance Optimization - Schedule as a story. Express as following: (1) Throughput, (2) Latency, (3) Responsiveness - how much delay is acceptablle between start an operation and receiving feedback.

Exploratory Testing - Goal is to not write bugs in the first place. Each test is a little experimeent that investigates the capabilities and limitations of e software.