Summary
This “book” is really a deck of 52 🙂 index cards with topics on one side and an explanation or further detail on the other side. Many topics from the Pragmatic Programming series are summarized here.
Top 3 Things I learned
- I like the Agile success factors. A good way to assess the situation during project chartering in a risk assessment of where your problems will be in Agile development.
- Acceptance Test Design principles. I am increasingly interested in driving design by acceptance.
- I really only found 2 things, but for ceremony and consistency and some tongue-in-cheek, I choose Bad Agile Smells.
Notes:
Twelve Agile Guiding Principles — Everyone focuses on the 4 key tenets of Agile, but seems to miss these as well as the primary reason for doing Agile.
- Satisfy the customer through early, continuous delivery
- Welcome changing requirements, even late
- Deliver working software frequently
- Businesspeople and developers collaborate daily
- Build projects around motivated individuals
- Convey info via face-to-face conversation
- Primary progress measure: working software
- Maintain a constant pace indefinitely
- Continuously demonstrate technical excellence
- Simplify: maximize the amount of work not done
- Self-organize
- Retrospect and tune behavior
Agile Roles: Some interesting roles here
- Customer: product definition
- Programmer: Construct the product
- Tester: Verifies product works as defined
- Tracker: Gather and present metrics
- Coach: Guide the team to success
- Coordinator: Manage external communication
Agile Success Factors (Binary, must be present to win). These become risks if you take on Agile without doing them
- Freedom to change
- Energized team
- Communication with customer
- Collaboration
- Attention to quality
- Incrementalism
- Automation
Toyota Production System (TPS) Principles
- Continuous Improvement
- Respect for people
- Long-term philosophy
- Develop the right process <– this to me is key, implies that you have to look at each situation and think about the process for the situation and not take a previous process and make it fit the situation
- Develop your people and partners
- Continuously solve root problems.
The Right Process
- Continuous process flow
- Pull work to avoid overproduction
- Work like the tortoise, not the hare
- Stop to fix the problems
- Standardize the tasks
- Expose problems with visual control
- Use only reliable technology that serves people and process
Reaching Consensus on Story Priority
- Simple Triage Rule: pick your priority category (bugs, features, foundation, etc) and do all stories in it
- Covey’s Quadrants: 2 x 2 matrix significance vs. urgency <– very similar to what I used on TDC
- Value/Risk/Good first: max value by value first, or min risk by max risk first, max usefulness by max good
- Fixed-length queue: Pick top items for immediate queue, then pick again
- Bargain: More votes than stories, everybody votes, <– similar to a retro tech.
- Alphabetical: arbitrary, but better than nothing
Acceptance Test Design Principles
- Abstract << Write for non-techies
- Bona Fide << Must exercise the system in a production-like environment
- Cohesive << One goal, one test
- Decoupled << Each test stands on its own
- Expressive << test is readable as if it was documentation
- Free of duplication <<
- Green << automated tests must always pass
Shu (follow the rule) – Ha (break the rule) – Ri (there is no rule)
Bad Agile Smells
- Individual work assignments (no pairing)
- Piles of unfinished work
- Work assignments given under the table
- Empty ceremonies
- Neglecting quality practices
- Guarded Speech
Agile Programming Practices
- Continuous Integration
- Test Driven Development
- Constant design improvement (Refactor)
- Coding standard
- Collective code ownership
- Simple design
- System metaphor
- Pair programming
Seven Code Virtues
- Working (as opposed to incomplete)
- Unique, (not duplicated)
- Simple, (not complicated)
- Clear (not puzzling)
- Easy (not difficult)
- Developed (not primitive)
- Brief (not chatty)