Starting Agile in a Company


Published on


Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • How long will they work together? Usually… less than a 1 month Usually… analysts at the beginning , testers will join in the end How many projects will they work on? Usually… 2 or more What activities will we take to build a team ? Usually… beers!
  • Starting Agile in a Company

    1. 1. Starting Agile in a Company Tips how to organize projects/products portfolio and cross-functional teams Vaidas Adomauskas 2011-10-06
    2. 2. Vaidas Adomauskas <ul><li>Blog : </li></ul><ul><li>Twitter : @adomauskas </li></ul><ul><li>SlideShare : http :// </li></ul><ul><li>LinkedIn : </li></ul>
    3. 3. Adform ( ) <ul><li>Founded in 2002 in Copenhagen, Denmark </li></ul><ul><li>Handling campaigns in more than 25 countries </li></ul><ul><li>10 offices </li></ul><ul><li>130+ employees (100+ in Lithuania) </li></ul><ul><li>60+ developers </li></ul>
    4. 4. Agile in organization January April Split your organization Split your product Spilt time Optimize business value Optimize process $ $$$ Create product in increments Henrik Kniberg “ The essence of Agile” AgileEE 2010
    5. 5. Agenda <ul><li>Why teams? </li></ul><ul><li>Organizing Teams </li></ul><ul><li>Organizing Projects </li></ul><ul><li>Organizing Support </li></ul><ul><li>Summary and Q/A </li></ul>Split your organization Split your product Optimize business value $ $$$
    6. 6. Why teams?
    7. 7. Which group gets better results?
    8. 8. Viktorija Truba čiūtė , Lietuvos Agile Diena 2011 Which ones they will be?
    9. 9. No common purpose…  Group of people Common purpose  Performing team! A  team  comprises a group of people or animals linked in a common purpose .
    10. 10. Bruce Tuckman model: It takes TIME to build performing team!
    11. 11. My team in Adform IMHO: it takes ~2 months to grow to performing team
    12. 13. Anyone else? <ul><li>… ir vienas svarbiausių dalykų - darbuotojai pradėjo dalintis žiniomis ir kartu siekti bendro tikslo, kartu atsakyti už klaidas, neįvykdytus įsipareigojimus . &quot;Ashburn International&quot; </li></ul><ul><li>… one of the most important things – employees started sharing knowledge and seek for common goal together, care for mistakes and not fulfilled commitments together. &quot;Ashburn International&quot; </li></ul>
    13. 14. Permanent teams are most effective
    14. 15. Organizing Teams
    15. 16. Cross-functional teams
    16. 17. <ul><li>Feature Team </li></ul><ul><li>Component Team </li></ul>How to split? Craig Larman, Bas Vodde - “Practices for Scaling Lean & Agile Development”:
    17. 18. Component Teams… <ul><li>Good </li></ul><ul><li>Easy start - developers know components, not features </li></ul><ul><li>Cross-functional - testers/analysts divided to teams </li></ul><ul><li>Consider </li></ul><ul><li>How to divide components? </li></ul><ul><li>How to run valuable sprint reviews ? </li></ul><ul><li>How to plan features ? </li></ul>Warning! Are you really that big (more than 50 people)?
    18. 19. How many teams? <ul><li>#teams = #people / 7 </li></ul>Warning! It seems easier to work in smaller teams… be aware more teams – more “management”!
    19. 20. Anyone else? <ul><li>Company: “We need to split our departments in different cities and organize them around our products. ” </li></ul>
    20. 21. Form cross-functional feature teams
    21. 22. Organizing Work
    22. 23. Create Product Backlog (Project Portfolio) <ul><li>List all projects </li></ul><ul><li>Prioritize (order) them </li></ul>
    23. 24. Create Product Backlog (Product) <ul><li>Slice your product </li></ul><ul><li>Prioritize slices </li></ul>
    24. 25. What tool to use?
    25. 26. Follow experiment @adomauskas
    26. 27. What if our projects are big? <ul><li>Break it to minimal marketable features (MMF) </li></ul>Project 1 Project 3 Project 2 (3 months ) P1F1 P2F1 Project 3 P1F2 P2F2 P1F3 Time to Complete Project 1 (4 months)
    27. 28. Work for teams (not vise versa!)
    28. 29. Anyone else? <ul><li>Big insurance system </li></ul><ul><ul><li>cars, houses, life insurance; customers data, integration with banks, accounting and billing, authorization flows… </li></ul></ul><ul><li>Insure a car </li></ul><ul><ul><li>No integrations, billing… </li></ul></ul><ul><ul><ul><li>Insure Volvo cars </li></ul></ul></ul><ul><ul><ul><ul><li>Insure Volvo V70 </li></ul></ul></ul></ul>
    29. 30. Work for teams (not vise versa)
    30. 31. Organizing Support
    31. 32.
    32. 33. Which one your company looks more alike to? Planned work Unplanned work
    33. 34. Fires! <ul><li>Urgent client requests </li></ul><ul><li>Production bugs </li></ul><ul><li>Minor features </li></ul><ul><li>Development bugs </li></ul>
    34. 35. Urgent client requests <ul><li>Is it urgent? </li></ul><ul><ul><li>Yes! </li></ul></ul><ul><li>Will you use it tomorrow? </li></ul><ul><ul><li>No… </li></ul></ul><ul><li>Will you use it next week? </li></ul><ul><ul><li>Yes… </li></ul></ul><ul><li>Great, we will do it during in next sprint (NOT urgent) </li></ul>
    35. 36. Urgent client requests <ul><li>Is it urgent? </li></ul><ul><ul><li>Yes! </li></ul></ul><ul><li>Will you use it tomorrow? </li></ul><ul><ul><li>Yes… </li></ul></ul><ul><li>Really, we will check? </li></ul><ul><ul><li>Ok.. Maybe next week </li></ul></ul><ul><li>Great, we will do it during in next sprint (NOT urgent) </li></ul>
    36. 37. Urgent client requests <ul><li>Is it urgent? </li></ul><ul><ul><li>Yes! </li></ul></ul><ul><li>Will you use it tomorrow? </li></ul><ul><ul><li>I need it yesterday!!! </li></ul></ul><ul><li>OK, Get on it right now (urgent) </li></ul><ul><li>How we can plan this next time ? </li></ul>
    37. 38. Fires! <ul><li>Urgent client requests </li></ul><ul><ul><li>Only small % </li></ul></ul><ul><ul><li>Plan most in product backlog </li></ul></ul><ul><li>Production bugs </li></ul><ul><ul><li>Critical ones – yes, decrease them! </li></ul></ul><ul><ul><li>Major/minor – plan them in product backlog </li></ul></ul><ul><li>Minor features </li></ul><ul><ul><li>NO, plan them in product backlog </li></ul></ul><ul><li>Development bugs </li></ul><ul><ul><li>NO, this is part of sprint task </li></ul></ul>
    38. 39. Team handles it <ul><li>Time “pillow” </li></ul><ul><ul><li>Max 30% of sprint </li></ul></ul><ul><ul><li>Visualize on sprint board </li></ul></ul><ul><li>Measure it! </li></ul><ul><li>Get it to 0%! </li></ul>
    39. 40. Support team <ul><li>Good: </li></ul><ul><ul><li>“ Focus” on bug fixing </li></ul></ul><ul><li>Issues: </li></ul><ul><ul><li>Knowledge of the system </li></ul></ul><ul><ul><li>Demotivating work </li></ul></ul><ul><ul><li>No team ownership for good code </li></ul></ul>
    40. 41. Support is our life… <ul><li>Are you sure??! </li></ul><ul><li>Use Kanban! </li></ul>
    41. 42. Prevent the fires!
    42. 43. Summary
    43. 45. Courage
    44. 46. External help
    45. 47. Start NOW
    46. 48. Thank you  <ul><li>Vaidas Adomauskas </li></ul><ul><ul><li>[email_address] </li></ul></ul><ul><ul><li> </li></ul></ul>Let’s Scrum!