Agile values working software over comprehensive documentation – it is 1/4th of the original manifesto. That doesn’t mean don’t document! It means don’t document more than you need to document. Documentation does have value, but the practice of documenting got excessive – that’s why a reaction to the bad stuff earned a spot as one of the pillars of agile. How do you avoid over-reacting when changing a culture of over-documentation?
Subscribe to Tyner Blain
Search
Pages
Archives
Categories
- Administrivia (32)
- Contest (1)
- Austin TX (11)
- Business Analysis (168)
- Business Rules (13)
- Consulting (103)
- Communication (90)
- Presentation (15)
- Writing (39)
- Outsourcing (8)
- Communication (90)
- Data management (3)
- Definitions (6)
- eCommerce (6)
- Expert systems (3)
- Flashback (75)
- Foundation series (22)
- Interface Design (9)
- Interviews (1)
- Lists (26)
- Marketing (27)
- Organizations (12)
- IEEE (1)
- IIBA (4)
- ProdMgmtTalk (2)
- ProductCamp (4)
- People management (4)
- Polls (10)
- Process Flow (5)
- Process Improvement (73)
- CMMI (10)
- Product Management (271)
- Product Strategy (10)
- Project Management (60)
- Quick Post (1)
- Requirements (363)
- Prioritization (46)
- Requirements gathering (106)
- Requirements management software (14)
- Requirements Models (163)
- Ishikawa Diagram (14)
- Kano Analysis (9)
- Software requirements specification (57)
- UML Modeling (12)
- Use Cases (68)
- User Stories (11)
- Reviews (11)
- Book Reviews (8)
- Software Reviews (3)
- ROI (40)
- Slightly off-topic (36)
- Software development (265)
- Agile (126)
- Design (16)
- Testing (47)
- Test Automation (25)
- UX (64)
- Interaction design (29)
- Usability (21)
- Success Stories (1)
- Uncategorized (15)


