`
| |
|
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 |
Posted in Agile | No Comments »
Wednesday, June 1st, 2011
Agile gave us a wonderful head-start in a different direction than the one we’ve used to (heavy weight methods.) Personally I feel we’ve got as much value we could. Now its time to start thinking from a different direction, building on what we already know and to some extent unlearning some things we know.
Wait a second, isn’t Agile all about “Inspect and Adapt”?
There is a limit to “inspect and adapt”. If you look at the Lean movement, most people talk about Kaizen (small gradual change, change for the good, which is in-line with inspect-and-adapt). But very few people talk about Kaikaku (disruptive change or transformation).
Remember Agile was Kaikaku for most of us in late 90s. And then we’ve applied Kaizen to it for many years. IMHO now its time to apply Kaikaku again.
Posted in Agile, Community, post modern agile | No Comments »
Wednesday, May 6th, 2009
Kanban seems to be a good starting point to adopt Lean thinking on a team. Of course Kanban alone is not sufficient to become lean. You need to Trust & Respect team members and you need concepts like Single Minute setup, Mistake-proofing, Zero Inspection, Kaizen, etc. Kanban to me is a great manifestation of Queuing Theory and to some extent Theory of Constraints.
Jeff Patton wrote a great intro to Kanban.
Of late I’m hearing a lot about Kanban and its application to software development. IMHO Kanban is nothing new. If you look at a lot of “traditional” maintenance and support teams they’ve been using Kanban for ages.
Back in 2004 when I was leading an offshore maintenance project without knowing anything about Lean or kanban, we really evolved to using a pull-system (Kanban) on our team. That was the only logically way we could work. Of course we started off with Iterations and Releases and so on. But we quickly implemented a simplified Kanban on our team.
Posted in Agile | 3 Comments »
|
