Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Agile Tour - War Stories
Upcoming SlideShare
Loading in …5
×

Agile Tour - War Stories

397 views
350 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
397
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide



  • Framework
  • -I am intersted in agile and try to use as much of i can @ichoosr, but i’m certainly not an expert
    -We do not claim we are an agile company
    ->We use agile ideas etc it throughout our company
  • 4 Regels

  • Nog detailed roadmap or backlog that determines the next 3 months
    We look 2 or 4 weeks ahead and plan on Mondat
    =>Sometimes we have a deadline that is 2 or 3 months in the future, but its details are not yet clear
    Works well
    =>Hard ot have a longterm vision
    =>Takes courage to push for new things
  • We don’t have any documentation, like big spec stuff or planning documents
    ->the testversion is the documentation
    ->We need user stories
    =>Scope creep
  • Small company=>we have to listen to our customers
    =>We don’t have a customer on site
    =>I wonder how this works?
    =>Would save us a lot of time wiating for feedback etc...
  • Small company, not much tools or process
    =>Agile helps to control this chaos

  • Early and continuous of valuable software
    Release each 2 weeks
    =>try to fix this, but hard
    Brings certain amount of calmness or team is relaxed
    With the team=>Early feedback
    =>No big release
    Longer releases => more stress
    Buisiness & Sales
    =>If we need something urgent we vcan have it in a few weeks time
    =>They don’t try to push etra stuff in it
    Disadvante
    We test 1 day out of 10 development days
    Unit testing is not enough
    Integration testing=>we need this, but maintainablility is high
    Valuable software=>Release to production

  • =>We determine what to do every 1 to 2 weeks so we are late in development
    =>But we do plan
  • =>works well
    =>not much discussion about how to plan
  • Short release cycles
    =>Definition of done is important to know hat can go in there
    =>Unit Tests
    =>Test/Verify
    =>Buisness
    =>Not always folled rogoursly enough, but is on the wall
    =>Continuous Integration + Unit Tests


  • 2 teams in Nl en BE
    Dit kost veel effort
    Startup=>organisch en automatisch
  • Startup=>We give everybody ownership of their job
    Of course lots of freedom to do what they want
    =>This really motivates people
    =>don’tknow if this would work in big companuies


  • Build a good team
    1 kamer voor alle developers
    1 a 2 uur stilte momenten
    face-to-face conversation=>build a team
    Beslissen bij consensus=>zorgt voor verantoordelijkheid

  • No documentation
    Backlog
    Bug tracking systeem
    Wiki
    Feature wordt ontwikkeld en dan getoont op test en binnen de 2 dagen besproken
    Nood aan user stories, want nu vele tijd verloren door op voorhand iets te weining na te denken

  • Is extreem belangrijk in product development
    Verkeerde technische beslissingen kosten over 2 jaar miss heel veel geld om te fixen of om te damage controllen
    Iedereen op tijd naar huis
    =>Buisiness gaat daar in mee, “als iemand roept dat moet”


  • No pair programming=>would help here
    No formal code reviews
    Shared Code=>eiderene werkt aan feature
  • KISS
    In het begin een noodzaak
    Nu een gewoonte, maar begint te veranderen
    Buisinessmensen hebben het hier moeilijk mee
    Gecomineerd met 2 weken release: doe het minimum en zat dat live en zie wat gebeurd
    Vaak is dit genoeg
    37 signals voorbeeld

  • Retrospective
    Bijschakelen tijdens development
    1 keer per 2 maanden=>Acties opvolgen is moeilijk in klein team
    Maar gewoon het houden v/e soort retrospective geeft aan dat improvement belangrijk is
    Iedereen denkt op zijn minst eens om de zoveel tijd na over verbeteringen
  • Build a team
    zorg dat die mensen graag samenwerken en voor elkaar opkomen en ga dan uit de weg
    Release Early
    Zorgt voor early feedback


  • ×