Skip to content

Instantly share code, notes, and snippets.

@talum

talum/agile_notes_ch4.md

Last active February 13, 2018 03:54
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save talum/7ccf841e8daa3f4618a1e3e53c6be3bb to your computer and use it in GitHub Desktop.
Save talum/7ccf841e8daa3f4618a1e3e53c6be3bb to your computer and use it in GitHub Desktop.
Download ZIP
agile
Raw
agile_notes_ch4.md

Chapter 4: Adopting XP

Prerequisites

  1. Management Support

    • workspace w/ pairing stations

    • team members solely allocated to project

    • on-site non engineers

    • "Acceptance of new ways of demonstrating progress and showing results"

    • patience while we learn

    • talk in terms of manager's ideas of success

    • or try standalone practices

  2. Team agreement

    • reluctant skeptics are ok
    • promise to revisit decision on date (2-3 months out)

  3. Colocated Team

    • well, crap
    • "you need help beyond this book"

  4. On-site customers

    • try a proxy?
    • proxy must have authority to act in place of product manager
    • need someone with business expertise to take responsibility for determining and prioritizing features
    • less experience in on-site customers = more risk to value of software

  5. Right team size

    • 4-6 devs, no more than 12 on team
    • support for batman?
    • siloed problems. "Stovepipe systems" - each programmer solves the same problem in different ways. Juniors create convoluted systems. Seniors make stuff overly sophisticated.

  6. Use all the practices

Recommendations

  1. Brand-New Codebase
    • woof
  2. Strong Design Skills
    • domain-driven design
  3. A Language That's Easy to Refactor
  4. Experienced Programmer-Coach
    • leadership
    • self-organizing teams
    • "The team decides for itself who is in charge of what...In fact, in a mature XP team, there is no on leader. Team members seamlessly defer leadership responsibilities from one person to the next, moment to moment, depending on the task at hand and the expertise of those involved"
    • an experienced developer is a good coach
  5. Friendly and Cohesive Team
    • need to work together
    • trust and respect
    • bad behavior, weed out the bad eggs
    • "miscellaneous toys and conversation pieces to inspire discussion and interaction"
    • four to nine months to feel comfortable with the process
    • "A supportive work environment is also important. Team members are likely to experience defense reactions to the lack of familiar structure. Expect mood swings and erratic behavior."

Shore, James; Chromatic. The Art of Agile Development: Pragmatic Guide to Agile Software Development (Kindle Locations 1608-1609). O'Reilly Media. Kindle Edition"

New Code Base

  • super

Legacy Code Base

  • biggest challenge is setting aside gime to pay down technical debt
  • set aside slack to pay it down
Raw
ch6.md

Chapter 6: Collaborating

  1. Trust
  • Forming, storming, norming, performing
  • "Trust is essential for the team to perform this well. You need to trust that taking time to help others won’t make you look unproductive. You need to trust that you’ll be treated with respect when you ask for help or disagree with someone. The organization needs to trust the team, too." Shore, James; Chromatic. The Art of Agile Development: Pragmatic Guide to Agile Software Development (Kindle Locations 2941-2944). O'Reilly Media. Kindle Edition.
  • Customer-Programmer Empathy by sitting together, retros, energized work
  • Programmer-Tester Empathy: save us from ourselves
  • Eat Together: sharing meals, lol. FREE MEAL.
  • Team Continuity: keep productive teams together. Assign a team to a project and stick around.
  • Show Some Hustle: convey a feeling of productivity
  • Deliver on commitments: working software & delivering on commitments. make a plan and chieve it.
  • Manage problems: work on the hardest, most uncertain tasks early in the iteration, absort a problem by reducing noncritical refactoring, postpone meeting, cancel research time. Replan.
  • Respect customer goals:
  • Promote the team: charts, demos.
  • Be honest: don't count stories that aren't done done.
  1. Sitting together
  • osmotic communication
  • cocktail party effect
  • get questions answered faster
  • be sure everyone has a space they can call their own
  • try to have at least 24 linear feet of whiteboard space, magnetic. more whiteboards
  • pairing stations
  1. Real customer involvement
  • on-site customers resonspible for choosing and prioritizing features
  • in-house custom development: organization's own use. classic IT department?
  • sometimes vision is more important than feedback from customers
  • change workflows with vision
  1. Unbiquitous language
  • programmers should speak the language of their domain experts
  • design your code to use the language of the domain
  1. Stand-up meetings
  • be brief
  • 30 s each
  • "People are always late to the stand-up. Can we treat them to parking-lot therapy? I’ve been tempted to introduce Mr. Laggard to Mr. Baseball Bat myself. Keep in mind that this is illegal in most countries and tough on team cohesiveness." Shore, James; Chromatic. The Art of Agile Development: Pragmatic Guide to Agile Software Development (Kindle Locations 3716-3718). O'Reilly Media. Kindle Edition.
  • Results: whole team aware of issues and challenges that other team members face and takes action to remove them. Everyone knows current status and what people are working on.
  1. Coding standards
  • "Individual style is great when you’re working alone. In team software development, however, the goal is to create a collective work that is greater than any individual could create on his own. Arguing about whose style is best gets in the way; it’s easier to work together in a single style." Shore, James; Chromatic. The Art of Agile Development: Pragmatic Guide to Agile Software Development (Kindle Locations 3753-3754). O'Reilly Media. Kindle Edition.
  • exercise in building consensus
  • minimal set of standards. consistency over perfection.
  • select an industry-standard style guide for language
  • dev practices, tools, keybinding, ide
  • build conventions
  • error handling and conventions
  • approach to events and logging
  • design conventions
  • fix legacy code when you need to refactor it. too expensive to change it if it works and you don't need to rad or touch it
  1. Iteration demos
  • product manager demo. speak language of stakeholder
  • ship every week
  • do not fake it
  1. Reporting
  • diff types of reports
  • roadmap
  • status email
  • "Instead of trying to measure features, measure the team’s impact on the business. Create an objective measure of value, such as return on investment. You can base it on revenue, cost savings, or some other valuable result."

Shore, James; Chromatic. The Art of Agile Development: Pragmatic Guide to Agile Software Development (Kindle Locations 4094-4096). O'Reilly Media. Kindle Edition.

  • time tracking chart for first 2 months or so
  • stories have nothing to do with productivity
  • don't compare velocity across teams
  • avoid reporting code quality metrics for stakeholders
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment