5 reasons you'll love to hate Agile Development
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

5 reasons you'll love to hate Agile Development

  • 1,487 views
Uploaded on

This is a presentation that Arin Sime of AgilityFeat gave at the 2013 Innovate Virginia conference, on 5 reasons why you will love to hate agile development. He presents 5 different areas that as an ...

This is a presentation that Arin Sime of AgilityFeat gave at the 2013 Innovate Virginia conference, on 5 reasons why you will love to hate agile development. He presents 5 different areas that as an agile coach he has often seen teams struggle with when moving to agile methods. For each area, Arin discussed why you should try it anyways and suggested strategies for tackling the problems head on.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,487
On Slideshare
1,052
From Embeds
435
Number of Embeds
11

Actions

Shares
Downloads
7
Comments
0
Likes
1

Embeds 435

http://agilityfeat.com 354
http://www.agilityfeat.com 40
http://localhost 10
http://blog.agilityfeat.com 9
http://agilityfeat-production.herokuapp.com 8
http://www.agileteam.co 7
https://twitter.com 2
http://agilityfeet.com 2
http://cloud.feedly.com 1
http://www.agilityfeat.biz 1
http://www.agilityfeet.co 1

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
  • Add in that you do need some high level customer research is needed up front
  • Lean UX is about doing this iteratively – take one bite at a timehttp://upload.wikimedia.org/wikipedia/commons/0/01/Leafcutter_ants_transporting_leaves.jpg

Transcript

  • 1. 5 Things you’ll love to hate about Agile Development @ArinSime Arin@AgilityFeat.com 434 996 5226
  • 2. Design & Development in Central America
  • 3. A few that have paid us…
  • 4. Hey, Look at me! I can talk.
  • 5. 5 Things you’ll love to hate about Agile Development #1: Pair Programming
  • 6. Pair Programming 2 developers working together on the same story, using the same computer and keyboard. One Driver and one Navigator, and they must switch roles regularly. What’s the Beef?  Manager: Why pay for two developers to only do one thing?  Developer: But he smells, and I don’t like to share!
  • 7. Independent Developers Developers Pair Programming Building Feature “A” Building Feature “A” Test Rework Test Redo Also fewer expensive post-release defects Pairs are 15% slower, but produce half as many bugs Williams study showed error free code went from 70% to 85%, cutting the error rate in half. Study by Laurie Williams of the University of Utah, as quoted in the Economist: http://www.economist.com/node/779429?Story_ID=779429
  • 8. Reasons to pair program: Lower Defect Rates Constant Peer Review Cross Training Cleaner Solutions Pairs are 15% slower, but produce half as many bugs Williams study showed error free code went from 70% to 85%, cutting the error rate in half. Study by Laurie Williams of the University of Utah, as quoted in the Economist: http://www.economist.com/node/779429?Story_ID=779429
  • 9. Painless Pair Programming Ideas  Require two people to sign up for every user story  Or only require pairing on certain user stories  Allow “me time” daily  Enforce pair programming most strictly on difficult or risky changes and with new team members  Use a sign up sheet and rotate pairs daily or on stories
  • 10. 5 Things you’ll love to hate about Agile Development #2: Test Driven Development & Automation
  • 11. Test Driven Development Build the automated tests for each story prior to coding the solution. Result: Automated Test Suite & High Quality! Write a new test What’s the Beef?  Manager: Isn’t this going to take longer? Green (Test Passes) Red (Failing Test)  Developer: How will I maintain all these old tests? Refactor Code Write Code  Tester: You can’t automate me! I am a human being! Green (Test Passes)
  • 12. Automation frees you to do more exploratory testing! Acceptance Test Driven Development (ATDD) Test Driven Development (TDD) http://watirmelon.com/2012/01/31/introducing-the-software-testing-ice-cream-cone/
  • 13. Painless TDD Ideas Write a new test Green (Test Passes)  Start with “Manual” TDD – write acceptance criteria  Leave legacy code behind Red (Failing Test)  “Cover and Modify”  Focus on unit tests first Refactor Code Write Code Green (Test Passes)  GUI level automation should focus on just a few paths that cover large sets of functionality
  • 14. 5 Things you’ll love to hate about Agile Development #3: Manual Testing Patterns
  • 15. Manual Testing Automation is great, but exploratory testing is still recommended. Manual testing in agile teams should be done within the sprint, and is part of that sprint’s “Definition of Done.” What’s the Beef?  Tester: How will I have time to do quality testing in each sprint? What about regression testing?  Developer: So I have to be done 2 days early now? Then what do I do?
  • 16. Sprint BusynessTM BusynessTM O M G developers This is what typically happens, but is not “good”. testers lolcats Days of the Sprint
  • 17. Sprint BusynessTM developers BusynessTM O M G testers lolcats Instead, let’s make sure stories are small and delivered frequently to testing… Days of the Sprint
  • 18. A Typical 2-week Cadence Sprint 2 Sprint 1 Monday Tuesday Wednesday S1 Planning Thursday The last stories should have made it to testing The first stories should be in testing by now S2 Planning Monday of the new sprint is a good time for testers to regression test Friday S1 Demo & Retro Developers work ahead, help test, maybe refactor S2 Demo & Retro
  • 19. Painless Testing Ideas  Enforce small user stories!  Developers deliver highest value stories first in the sprint  In-sprint testing focuses only on the stories at hand  Use the beginning of the next sprint to regression test before deploying the current sprint  In sprint bugs are communicated, not tracked
  • 20. 5 Things you’ll love to hate about Agile Development #4: Branching & Release Streams
  • 21. Release Streams Agile teams work in small chunks, and deployments happen on cadences like this: Scrum – deploy at end of sprint What’s the Beef?  Developer: I have to work in multiple branches every day!?!? Kanban – deploy story by story This means frequent deployments, and multiple branches to keep code independently testable and deployable.  Release Engineer: I hate merging, and now I hate U.  Tester: How do I know what codebase I am testing?
  • 22. “Big Bang” Branching big_bang master branch merge Deploy to Production
  • 23. Branching Challenges for Agile teams  Deploy frequently  Work on very small stories  Work towards big goals, aka “epics”  Balance production fixes with ongoing work  Keep the testing environments straight
  • 24. Branching by features feature_1 feature_4 feature_2 feature_3 master branch merge Deploy to Production Deploy to Production Deploy to Production Works great with very independent features and a kanban style system. May be too fluid for scrum teams and large epics.
  • 25. Sprint Branching Strategy epic sprint_x sprint_x+1 sprint_x+2 master testing production A little complicated … but the value created here is balancing short term and long term work while still delivering frequent releases.
  • 26. Hot fixes to production epic sprint_x sprint_x+1 sprint_x+2 master hf_issue testing production Hot fixes to production should be rare … use the sprints instead when ever possible!
  • 27. 5 Things you’ll love to hate about Agile Development #5: Iterative Architecture & Design
  • 28. Iterative Design & Architecture Vision is good, but detailed design documents are bad. Remember that whole “working software over comprehensive documentation” thing? Agile teams work in small chunks, and architectural and UX/visual design tasks should be done at the last responsible moment. What’s the Beef?  Architect: No more design documents? I can’t decide whether to kiss you or punch you right now.  Visual Designer: I’m an artist, don’t oppress me!  Developer: FR33D0M!!!
  • 29. Vision and customer research are good things But details are waste
  • 30. Defining in pieces
  • 31. Defining in pieces
  • 32. Defining in pieces
  • 33. 5 Things you’ll love to hate about Agile Development Why you should bother…
  • 34. Avoid Big Bang Deployments “Big release” Feature B Feature A Design Change Feature C Bug fix Pricing Change Which was the cause? meh.
  • 35. Instead… Define Biz Test Code it! Test the code Deploy! Measure results Learn!
  • 36. @ArinSime Arin@AgilityFeat.com 434 996 5226
  • 37. Testing process changes Standard path Common entry point Common conversion or exit point Which path? Alternate path Log user behavior
  • 38. 5 Things you’ll love to hate about Agile Development Additional Slides
  • 39. A Typical 2-week Cadence Sprint 2 Sprint 1 Monday UX has wireframes approved by the team or list of S1 revisions Planning Tuesday Wednesday UX now knows what wireframes Thursday to focus on… Friday S2 Prioritization Team now has approved S2 S2 3 Amigos wireframes and possibly Estimation mockups too S1 Demo & Retro S2 Planning S3 Prioritization S3 3 Amigos S3 UX starts Estimationworking ahead on next sprint S2 Demo & Retro
  • 40. Prioritization Meeting  Purpose: Review the backlog, and adjust the priorities of upcoming stories as necessary. Product Owner can make projections of when stories will be worked on based on historical velocity, but they cannot commit the team. Required Attendees: Product Owner, Scrummaster, UX Optional Attendees: Other stakeholders that the Product Owner reports to Time: 1 hour  Look out for: Any fixed constraints or new issues from stakeholders may require changing priorities  Outcomes: Product Owner and UX knows what stories to prepare for the 3 Amigos meeting
  • 41. 3 Amigos Meeting  Purpose: Review the upcoming stories for the next sprint. This is a chance for the team to verify that the “Definition of Ready” criteria are all met and the team has a shared understanding of the story to be developed. Required Attendees: Product Owner, Scrummaster, UX, Developers, Testers. Some teams prefer to rotate which developers and testers attend. It’s usually best to start with the whole team until comfortable with the process though. Time: 1 hour (time boxed)  Look out for: Missing Acceptance Criteria, dependencies on external resources or architects, edge cases that need to be considered.  Outcomes: The team agrees that this story can be estimated and can be considered for the next sprint’s planning session.
  • 42. Estimation Meeting  Purpose: Go through all the candidate stories for the next sprint. These stories should have already been approved in a 3 Amigos meeting, or adjustments made based on feedback from that meeting. Stories are estimated by the full team using story points. Required Attendees: Product Owner, Scrummaster, UX, Developers, Testers. All developers and testers should be present, not just representatives in this case. Time: 1 hour (time boxed)  Look out for: Major team disagreements on what a story means. If stories are too big to be comfortably completed in the sprint, they should be broken up.  Outcomes: 1-2 Sprint’s worth of User Stories are ready for planning.
  • 43. Planning Meeting  Purpose: The hard work has already been done. Now the team is just going to compare the list of prioritized, estimated stories to historical velocity and decide how many to commit to in this sprint. Required Attendees: Product Owner, Scrummaster, UX, Developers, Testers. All developers and testers should be present, not just representatives in this case. Time: 30 minutes - 1 hour  Look out for: It’s ok for the Product Owner to add stories at the last minute on occasion, just prioritize and estimate them quickly at the beginning of the meeting prior to the planning.  Outcomes: A completed Sprint that the team is comfortable committing to and tackles the Product Owner’s highest priorities.