XNSIO
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

The Ever-Expanding Agile and Lean Software Terminology

Sunday, July 8th, 2012
A Acceptance Criteria/Test, Automation, A/B Testing, Adaptive Planning, Appreciative inquiry
B Backlog, Business Value, Burndown, Big Visible Charts, Behavior Driven Development, Bugs, Build Monkey, Big Design Up Front (BDUF)
C Continuous Integration, Continuous Deployment, Continuous Improvement, Celebration, Capacity Planning, Code Smells, Customer Development, Customer Collaboration, Code Coverage, Cyclomatic Complexity, Cycle Time, Collective Ownership, Cross functional Team, C3 (Complexity, Coverage and Churn), Critical Chain
D Definition of Done (DoD)/Doneness Criteria, Done Done, Daily Scrum, Deliverables, Dojos, Drum Buffer Rope
E Epic, Evolutionary Design, Energized Work, Exploratory Testing
F Flow, Fail-Fast, Feature Teams, Five Whys
G Grooming (Backlog) Meeting, Gemba
H Hungover Story
I Impediment, Iteration, Inspect and Adapt, Informative Workspace, Information radiator, Immunization test, IKIWISI (I’ll Know It When I See It)
J Just-in-time
K Kanban, Kaizen, Knowledge Workers
L Last responsible moment, Lead time, Lean Thinking
M Minimum Viable Product (MVP), Minimum Marketable Features, Mock Objects, Mistake Proofing, MOSCOW Priority, Mindfulness, Muda
N Non-functional Requirements, Non-value add
O Onsite customer, Opportunity Backlog, Organizational Transformation, Osmotic Communication
P Pivot, Product Discovery, Product Owner, Pair Programming, Planning Game, Potentially shippable product, Pull-based-planning, Predictability Paradox
Q Quality First, Queuing theory
R Refactoring, Retrospective, Reviews, Release Roadmap, Risk log, Root cause analysis
S Simplicity, Sprint, Story Points, Standup Meeting, Scrum Master, Sprint Backlog, Self-Organized Teams, Story Map, Sashimi, Sustainable pace, Set-based development, Service time, Spike, Stakeholder, Stop-the-line, Sprint Termination, Single Click Deploy, Systems Thinking, Single Minute Setup, Safe Fail Experimentation
T Technical Debt, Test Driven Development, Ten minute build, Theme, Tracer bullet, Task Board, Theory of Constraints, Throughput, Timeboxing, Testing Pyramid, Three-Sixty Review
U User Story, Unit Tests, Ubiquitous Language, User Centered Design
V Velocity, Value Stream Mapping, Vision Statement, Vanity metrics, Voice of the Customer, Visual controls
W Work in Progress (WIP), Whole Team, Working Software, War Room, Waste Elimination
X xUnit
Y YAGNI (You Aren’t Gonna Need It)
Z Zero Downtime Deployment, Zen Mind

Stop Sprinting, Start Minting

Friday, October 23rd, 2009

These days, its common to see teams doing the Product Backlog Management to Sprint Planning t0 Daily Scrums to Reviews to Retrospectives perfectly fine, as described in the book (or the 2 days Certified Scrum Master course). We are doing all the process stuff correctly, except that we don’t seem to be”actually” making money (minting). But somehow along the way, we seemed to have missed the point.

The problem I see is, teams are doing all the process stuff, as they are told, except that, post demo they don’t actually release the software (deploy it into production). Most teams are very happy showing the demos at the end of the sprints. They start thinking that this new process they are following is magical. Until 6 months later, their so-called “Product Owner” comes backs saying I didn’t quite expect “this” this-way and I thought “that” would be “this” and not really “that”. That is when it hits the team that what they were really doing was building inventory and basically doing a compressed-waterfall.

Until you actually release your software and see your end-users actually use it in real life, you don’t have the most important feedback. Hence you are not “done” until you really see you users use the feature you just released (and probably you are not even done after that. “Done-Done” was a cute concept, get over it). There is no better means of feedback nor is there a better risk-reduction strategy other than releasing software to production frequently (at least every week).

Remember code that is not yet deploy and just sitting in your repository is a liability. So is, all your fancy product backlogs and grandiose plans.

    Licensed under
Creative Commons License