Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Kanban - Agile Evolution versus Revolution

Presentation given at Developer Day Scotland on Agile introduction using Kanban.
by

Chris McDermott

on 6 October 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Kanban - Agile Evolution versus Revolution

Introduction to Kanban Chris McDermott an approach to incremental, evolutionary process
and systems change for organisations Revolution Kanban 101 @chrisvmcd before agile agile introduction functional teams ill defined process high profile project difficult customer relationship a lot of bugs passion excitement job satisfaction happy customers quality code Release Planning

Planning game

Iterations

Small releases

Retrospectives

Stand up meetings

No BDUF/Emergent Design

Test driven development

Refactoring

Pair programming

Continuous Integration

Common code ownership

Code as documentation

Generalists

On site customer

40 hour week

New roles (team structure) poor communication Change is threatening Project Managers Pair programming Stand up meetings 40 hour week Iterations Release Planning Business Analysts Documentation lite On site customer Generalists Generalists Test driven development Developers Pair programming Continuous Integration Refactoring Common code ownership Change is risky #1 Visualise your workflow take the process you have & map the value stream make the work visible #2 Limit work
in progress #3 Manage flow #4 Make process policies explicit Have upper limits for work in progress stop starting and start finishing! use the need for flow as a driver for improvement another layer of visualisation remove emotional, anecdotal and subjective discussion #5 Improve Collaboratively a pull system emerges discuss progress at the board each day
(have a stand up meeting) Theory of Constraints System of Profound Knowledge Lean
(waste elimination) - continuous integration
- automate deployment - automated testing
- on site customer - common code ownership
- pair programming Kaizen Kaikaku Lean production term which
means radical overhaul Time Performance/Productvity Evolution philosophy or practices that focus upon continuous improvement of processes Kaizen how many tasks should a person work on at a time? means “transformation” or “reform” and implies a redesign of business processes that is radical (using models & the scientific method) lead & cycle times Start with what you do now
Agree to pursue incremental, evolutionary change
Respect the current process, roles, responsibilities & titles that's what we need to do regular release cadence identify bottlenecks analyse demand risk profile identify waste in summary... with Kanban we introduce Kaizen culture reduce the risk of change by introducing it
incrementally and with well understood reason we reduce the threat of change by doing it collaboratively agile evolution versus revolution Kanban resources: Books Web
- www.limitedwipsociety.org/
- www.kanban101.com/
- kanbandev yahoo group Twitter
@agilemanager
@flowchainsensei
@benjaminm
@AGILEMinds
@dpjoyce
@kjscotland Tools
- kanbantool.com
- see limitedwipsociety Questions? Input Cadence
SLA & Class of Service
Cost of Delay
Metrics
Operations Reviews (what work was like for me)
Full transcript