Your SlideShare is downloading. ×
You think you know agile
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

You think you know agile

7,452
views

Published on

Combined slide decks from the presentation at Progressive.net 2011

Combined slide decks from the presentation at Progressive.net 2011

Published in: Technology, Business

0 Comments
11 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,452
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
405
Comments
0
Likes
11
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Scrum – Hirotaka Takeuchi and IkujiroNonakaDSDM – Dynamic Systems Development MethodMoSCoW requirement prioritisation – Must have, Should have, Could have, Won’t haveFully compatible with ISO 9000 & PRINCE2
  • Servant Leadership - Robert K. Greenleaf 1970
  • In scrum although backlog grooming is not an official meeting most teams work with thee ScrumMaster & Product owner to ensure the stories are ready to be worked on
  • Values:Simplicity, Communication, Feedback, Respect, CouragePrinciples: Humanity, Economics, Mutual Benefit, Self-Similarity, Improvement, Diversity, Reflection, Flow, Opportunity Redundancy, Failure, Quality, Baby steps, Accepted responsibilityPractices: Primary - Sit together, Whole Team, Informative Worksapce, Energized Work, Pair Programming, Stories, Weekly cycle, Quarterly Cycle, Slack, Ten Minute Build, Continuous Integration, Test First Programming, Incremental DesignCorollary - Real Customer Involvement, Increment Deployment, Team Continuity, Shrinking Teams, Root Cause Analysis, Shared Code, Code And Tests, Single Code base, Daily Deployment, Negotiated Scope Contract, Pay Per Use
  • Flow – important to ensure that the work flows through the systemCadence – the time it takes to performPolicies – govern behaviour, how the system works. Limit WIP best example of a policyClasses of Service – typically based on business impact, implemented through policies, will effect work done by the team
  • Partially Done Work – work not completedExtra Processes – needless paperworkExtra Features – adding features in ‘just in case’ which aren’t really neededTask Switching – switching between different projectsWaiting – delays in staffing, delays in starting, delays due to excessive documentationMotion – how much motion to answer a question? Linked to Task Switching & WaitingDefects – the longer it takes to discover a bug the more it costsManagement Activities – project management activities, authorization processes for approval of requirement changes, etc
  • Perceived Integrity – how a customer perceives the system. A good example is GoogleConceptual Integrity – the same concept, from a users perspective, is executed consistently e.g. Airline bookingRefactoring – process can’t be perfect 1st time. Refactor to improve as knowledge improvesTesting – Unit tests, integration tests, load tests, etc
  • Identifies that knowledge of what we are doing is important and that we need to actively look to create this knowledge to help the teamFeedback – feedback loops help create knowledge e.g. Unit testingSharing knowledge – pair programming, code reviewsRecording knowledge – wiki, code comments, documentation
  • Concurrent development – develop separate streams until you have to decideOptions thinking – Responding to change rather than following a plan, don’t freeze “requirements”Last responsible moment – don’t make a decision over what to do until the last momentMaking decisions – actually make a decision over what option to take, don’t allow concurrent streams forever
  • Pull Systems – customers prioritise what they want so they get most important thing firstQueuing theory – ensure steady rate of arrival, include slack, Theory of constraintsCost of Delay – cost of developer not having tools to speed dev, cost of not getting to market
  • Engage, collaboration, trust and respect the people doing the work. E.g. Managers that do not know how the work is done shouldn’t try to tell people how they should do their workLean is not about controlling people, it is about engaged motivated people helping a business grow
  • Systems thinking – look at entire systemMeasure value – focus on how the business delivers value, use Value Stream Mapping to helpThink long term – don’t focus on the now (although important) look at where you the business is going/needs to be
  • Utilise WIP limits to highlight impediments/bottlenecksStill use iterations to provide “container” for deployable softwareStill generalist skillset i.e. Anybody can pick up any task
  • Recommended booksPoppendicks : Lean Software Development – An agile toolkit, Implementing Lean Software Development. David Anderson : Kanban – Sucessfulevolutionary change for your Technology business
  • Running Lean (www.runningleanhq.com) – great free book on lean startup“Offical” book from Eric Ries coming out soon.
  • Not comparing like for like.Be sure to differentiate Business Methodology with a workflow methodology AAARS =Acquisition – user comes to site from various channelsActivation – users enjoy 1st visitRetention – users come backReferral – users like you enough to refer othersRevenue – users conduct some monetized behaviour
  • Jeff Sutherland
  • Transcript

    • 1. You think you know agile?
      The where, what and how of agile
      nathan.gloyn@dotnetsolutions.co.uk
      Design Code Release
      nathangloyn
      @NathanGloyn
    • 2. Agenda
      You Decide!
    • 3. ROOTS...
    • 4. Roots...
      When agile was born…
      Heavy weight project management processes
      Misunderstood requirements
      Missed deadlines or death march projects
      Inability to change requirements
      Applications with lots of defects
      Increases the cost
    • 5. Roots...
      Scrum – first described
      1986
      DSDM, Adaptive Software Development
      Scrum
      1995
      1996
      Extreme Programming (XP), Crystal Clear
      1997
      Feature Driven Development
      2001
      Agile Manifesto
      2004
      Kanban
      ?
      ?
    • 6. Roots...
      Agile Manifesto
      Individuals and interactions over processes and tools
      Working software over comprehensive documentation
      Customer collaboration over contract negotiation
      Responding to change over following a plan
      That is, while there is value in the items on the right, we value the items on the left more.
    • 7. Roots...
      Agile Manifesto – 12 Principles
      Customer satisfaction by rapid delivery of useful software
      Welcome changing requirements, even late in development
      Working software is delivered frequently (weeks rather than months)
    • 8. Roots...
      Agile Manifesto – 12 Principles
      Working software is the principal measure of progress
      Sustainable development, able to maintain a constant pace
      Close, daily co-operation between business people and developers
    • 9. Roots...
      Agile Manifesto – 12 Principles
      Face-to-face conversation is the best form of communication (co-location)
      Projects are built around motivated individuals, who should be trusted
      Continuous attention to technical excellence and good design
    • 10. Roots...
      Agile Manifesto – 12 Principles
      Simplicity
      Self-organizing teams
      Regular adaptation to changing circumstances
    • 11. Concepts
    • 12. Concepts
      Control
    • 13. Concepts
      Communication
    • 14. Concepts
      Collaboration
    • 15. Concepts
      Cooperation
    • 16. Concepts
      Commitment
    • 17. Team
    • 18. Team
      The team is:
      Critical to success
      Not a bunch of individuals
      No Hero’s
      Not dependent on any member
      Empowered
      Trusted
    • 19. Team
      Who is in the team?
      Team Member
      Product Owner
      Customer
    • 20. Team
      Who is a Team Member?
      Developer
      Tester
      Business Analyst
      Team Lead
      Architect
      Product Owner
    • 21. Team
      Do we need a product owner?
      Focus on what to deliver
      Customer Proxy
      Product Manager
      Project Manager not a good fit
      Not good idea to be a team lead or manager
    • 22. Team
      Where does a Scrum Master/Coach fit in?
      Guardian of the teams process
      Servant/Leader
      Helps foster the idea of “team”
      Should never be a team lead or manager
      Focused on helping team deliver
    • 23. Team
      Do we need a project manager?
      Generally no
      Responsibilities distributed
      Product owner
      Coach/Scrum Master
      Some projects have to be waterfall
    • 24. Team
      Generalist
      OR
      Specialist?
    • 25. Team
      A Self <?> Team
      Self Organising
      Self Directing
      Self Managing
    • 26. Methodologies
    • 27. Methodologies
      Currently 3 main stream:
      Scrum
      XP
      Kanban
    • 28. Methodologies: Scrum
    • 29. Methodologies: Scrum
      TO DO
      WIP
      Done
    • 30. Methodologies: XP
    • 31. Methodologies: XP
      TO DO
      WIP
      Done
    • 32. Methodologies: Kanban
      Input Queue
      In Process
      Done
      Available capacity
    • 33. Methodologies: Kanban
      TO DO
      WIP (2)
      Done
    • 34. Methodologies
      Commonalities:
      Visibility/Transparency
      User stories
      Pull Based
      Definition of done
      Sustainable pace
      Continuous Improvement
    • 35. Methodologies: Helicopter View
      Scrum
      XP
      Kanban
      Plan release
      Plan iteration
      Work through items
      Release when “Done, Done”
      Iteration Retrospective
      Release Retrospective
      Plan sprint
      Work on items in sprint
      Review
      Retrospective
      Input queue
      Pull item to work
      Work until meets done criteria
      Repeat
    • 36. Methodologies: Meetings
      Scrum
      XP
      Kanban
      Release Planning
      Iteration Planning
      Standup
      Iteration Retrospective
      Release Retrospective
      Daily Stand-up
      Sprint Review
      Sprint Retrospective
      Sprint Planning
      Backlog grooming
      None
    • 37. Methodologies: Roles
      Scrum
      XP
      Kanban
      Customer
      Coach
      Team
      Customer
      Product Owner
      Scrum Master
      Development Team
      What ever you
      currently have
    • 38. Methodologies: Artifacts
      Scrum
      XP
      Kanban
      Board
      Charts
      More charts!
      Card Board
      Backlog
      Definition of Done
      Burndown
      Board
      What ever reports you wish to create
    • 39. Methodologies: Metrics
      Scrum
      XP
      Kanban
      Lead time
      Cycle time
      Throughput performance
      Due date completion
      etc
      Velocity
      Velocity
    • 40. Methodologies:Continuous Improvement
      Scrum
      XP
      Kanban
      Kaizen culture
      Kaizen blitz
      Slack
      Inspect & Adapt
      Sprint retrospective
      Iteration retrospectives
      Release retrospective
    • 41. Methodologies: Differentiators
      Scrum
      Estimation
      Commitment Forecasting
      Iterations
      Team decide what to pull into an iteration
    • 42. Methodologies: Differentiators
      XP
      Short Iterations
      “Done, Done”
      Rules
      5 Values
      14 Principles
      24 Practices
    • 43. Methodologies: Differentiators
      Kanban
      Flow
      Cadence
      Policies
      Classes of Service
    • 44. Methodologies: Comparison
    • 45. Lean
    • 46. Lean
      What is Lean?
      From manufacturing
      Toyota Production System (TPS)
      Just In Time (JIT) production
      Kanban card
      Kaizen
      Poppendicks
      Lean Software Development: An Agile Toolkit (2003)
      David J Anderson
      Kanban - Successful Evolutionary Change for your Technology Business
    • 47. Lean: Principles
      Eliminate Waste
    • 48. Lean: Principles
      Build Quality In
    • 49. Lean: Principles
      Create Knowledge
    • 50. Lean: Principles
      Defer Commitment
    • 51. Lean: Principles
      Deliver Fast
    • 52. Lean: Principles
      Respect People
    • 53. Lean: Principles
      Optimise the whole
    • 54. What’s next?
    • 55. What’s next?
      ScrumBan
      Lean Startup
      The rise of lean
      Death of the Iron triangle?
    • 56. What’s next: Scrumban
      Mixture of Kanban & Scrum
      Workflow of Kanban
      Backlog column for iteration
      Ready column for higher priority work
      Meetings of Scrum
    • 57. What’s next: The rise of lean
      The next best thing?
      Beware marketing speak
      Can help whatever process you are using
      Kanban
    • 58. What’s Next: Lean Startup
      “new methodology”
      Focused on getting product “out there”
      More a business methodology
      Kanban great fit
      Beware comparisons to agile
    • 59. What’s Next: Lean Startup
    • 60. What’s next: Death of the Iron triangle?
      Cost exists anyway
      Quality should be a given
      Scope flexible
      Possibly in enterprises
      Unlikely with external clients
    • 61. Sum up
    • 62. Summary
      Lots of ideas
      Pull in what works
      Throw away what doesn’t
      Create your own process
      Stay true to principles
      nathan.gloyn@dotnetsolutions.co.uk
      Design Code Release
      nathangloyn
      @NathanGloyn

    ×