Agile Way to First Iteration


Published on

Presentation from Agile Base Camp 2 conference (Kiev, may 2010) about major activities to do before starting iterative development with one of the Agile methodologies.

Published in: Technology
  • Be the first to comment

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

No notes for slide

Agile Way to First Iteration

  1. 1. Agile Way to First Iteration Mikalai Alimenkou
  2. 2. Background • Java Technical Lead/Scrum Master at Zoral Labs • 6+ years in software development • 4+ years of working by Agile methodologies • Expert in Agile engineering practices • Agile coach (TDD, Testing, Planning, etc.) at XP Injection (
  3. 3. Ideal Agile project I have idea of new product!
  4. 4. Ideal Agile project I have idea of new product! We can implement it!
  5. 5. Ideal Agile project I want to do it in Agile way!
  6. 6. Ideal Agile project I want to do it in Agile way! Nice! We have cross functional and self organizing team! Yes, we are ready to start!
  7. 7. Ideal Agile project I have prioritized backlog and project vision for you!
  8. 8. Ideal Agile project I personally will be you PO!
  9. 9. Ideal Agile project OK, but lets sign Agile contract before?
  10. 10. Ideal Agile project OK, but lets sign Agile contract before? Sounds good for me! Lets start first iteration!
  11. 11. What do you have?
  12. 12. What do you want to archive?
  13. 13. When things are simple? • Another CRUD application • Application with many competitors on the market • Ready to use requirements or specification from the customer • Cool idea but simple product • Reverse engineering of existing project
  14. 14. What is iteration 0? • Before first real iteration • Prepare all tools and environments • Establish team practices • Prepare backlog to first iteration planning • Learning new technologies • Establishing team velocity • Even earning some business value
  15. 15. What happens in real world? Backlog is not ready because customer is not ahead of developers
  16. 16. What happens in real world? UI has many inconsistencies without common UI design
  17. 17. What happens in real world? Architectural decisions can’t satisfy nearest project requirements
  18. 18. What happens in real world? Functionality is ready but product doesn’t satisfy non-functional requirements
  19. 19. What happens in real world? Lack of deep common understanding of what product is built
  20. 20. Lead to significant rework
  21. 21. STOP! We don’t do anything upfront!
  22. 22. What we do in Agile? • Refactoring • Simple design • YAGNI • DRY principle • JIT
  23. 23. Agile planning
  24. 24. What do we need to start? Concepts ??? User Stories Iteration plan Acceptance Tests Budget Team
  25. 25. What does customer need to start? Concepts Major Features Product Design Product Architecture Test Strategy Risks User Value Efforts Estimates Skills Set Cost Estimates Release Plan User Stories Iteration plan Acceptance Tests Budget Team Execution PlanningVision
  26. 26. Real transformation Concepts Ideas Main Features Features & Design User Stories
  27. 27. Product vision • Help everyone be on the same page • Collective understanding of the product • Define main and differentiating features • Ways: – Product workshop – Users, roles and functions game – UI prototyping
  28. 28. We understand • Who are the customers • Competitors and alternative products on the market • Product category and role on the market • Key features of the product
  29. 29. Product design • Major data flows • Main UI navigation paths • Messaging and communication protocols • Users and their roles in the system • Main user activities
  30. 30. Traditional approach
  31. 31. Agile approach • Actors, roles and goals list – Whiteboard snapshots or simple spreadsheets – Personas for each role (details like name, life cycle, image, etc.) • Paper or other lightweight prototyping – Mockup tools as cheap and quick as possible – Helps communicate effectively • User testing – Execution of scenarios on prototypes – Get feedback from users to avoid early mistakes
  32. 32. Agile risk management • Risk meeting to identify risks • Store main risks on cards and put them into zone by impact and probability • Brainstorm for high right corner risks • Make results visible and revisit during development
  33. 33. Define architecture • Understand key components, flows and technologies • Reduce technological and schedule risks • Prove main assumptions
  34. 34. Traditional approach • Create detailed architectural document • Build all kinds of diagrams and architectural views • Review architecture • etc.
  35. 35. Agile approach • Use informal style of documents • Validate main architectural decisions with architectural prototypes • Mock unneeded components and services
  36. 36. Testing strategy • Testing strategy helps to reduce time of tests automation • Select testing frameworks and tools for each kind of tests • Define roles and responsibilities for testing
  37. 37. Acceptance testing • Define acceptance criteria for each User Story during iteration planning (PO, QA) • Create acceptance tests (PO, QA, DEV) • Implement acceptance tests (QA, DEV) • Use them as part of DONE criteria • At the end of iteration all acceptance criteria must pass
  38. 38. Release planning • Divide functionality by importance • Must have, Important, Would be nice • Estimate features, not stories • Don’t put all top priority stories in first release • Story mapping
  39. 39. Colored backlog Visible Feature Architectural Feature Visible Defect Technical Dept Visible Invisible Positive Value Negative Value
  40. 40. Hiring business resources • Important Product Owner role: – Strong business leadership and vision – Understand needs of users – Open to new ways of working – Have planning skills, not just reacting to the facts – Collaborative, decisive, conceptual thinker • Wrong Product Owner can: – Slow down the project – Lead the team in the wrong direction
  41. 41. Hiring technical team • Need experienced senior development staff early: – Estimate features – Define architecture – Prepare “proof of the concept” architectural prototypes – Help to hire rest of the team • Full team hiring should wait for budget approval and architectural decisions: – Identify needed skills and team size – Some time should be spent to bring team up to speed on the vision – Team trainings on Agile and engineering practices
  42. 42. You take away • Not all projects may be started quickly with Agile • Some things needs to be done upfront • Don’t use Agile practices fanatically • Almost every traditional activity may be performed in Agile way
  43. 43. Any questions?