AGILE/memoirs
(Of one reasonably small but devoted developer team)
	
  	
  	
  	
   	
  ADAM OKRUHLICA
linkedin.com/in/okr...
REQ!
DSGN!
impl!
test
WATERFALL
agile
…"REQ"DSGN" impl"test"REQ"DSGN"IMPL"TEST"…
< 1st sprint> < 2nd sprint>
BUT IT ALSO IS…
AN ONGOING
EXPERIMENTATION
A Focus on FREQUENT
stakeholder
The basics
Anatomy of a sprint
 	
  
The basics/anatomy of a sprint
order	
   dsgn	
  
analysis	
  	
  
ux	
  
html	
  
css	
  
devel	
  	
  
test	
  
ua...
 	
  
The basics/when not agile
When not agile
•  Manufacture-like project
•  Fixed-price, fixed-scope, no changes
•  Very...
Lesson #1
Sign an agile contract.
 	
  
Lesson #1/sign an agile contract
Prepare for the Buts…
“	
  But I already precisely know what I want.
That’s great. ...
 	
  
Lesson #1/sign an agile contract
Prepare for the Buts…
“	
  But I won’t pay for unfinished software!
You’ll only be ...
 	
  
Lesson #1/sign an agile contract
Prepare for the Buts…
“	
  BUT I DON’t HAVE TIME FOR regular REVIEWS.
it seems the ...
 	
  
Lesson #1/sign an agile contract
Adapt your contract
•  Describe the agile process
•  Verbalize the commitment to UA...
Lesson #2
Make sure they understand.
 	
  
Lesson #2/make sure they understand
Agile is not a developers’ game.
•  We are partners and we play along.
•  Custom...
 	
  
Lesson #2/make sure they understand
Measuring Customer involvement
Rules of thumb
•  Do they ask how will this solve...
Lesson #3
Write bullet-proof user stories.
 	
  
Lesson #3/bullet-proof user stories
Write a story in terms of business value
(Not technical value)
US01: smtp server...
 	
  
Lesson #3/bullet-proof user stories
Use g-w-t structure to describe stories.
US02:
If a registered but unverified us...
 	
  
Lesson #3/bullet-proof user stories
Create a story hierarchy if needed.
Us03: all Users get notified when their bank...
 	
  
Lesson #3/bullet-proof user stories
Use user stories as acceptance criteria*
*Make sure to add this to your contract
Lesson #4
Story points AND manhours CAN
COEXIST.
 	
  
Lesson #4/plan with manhours
Story points give you a fair estimate.
•  user stories get story points (1-2-3-5-8..) f...
 	
  
Lesson #4/plan with manhours
however
The Team
Nature of work
Dependencies
demands
Can change.
 	
  
Lesson #4/plan with manhours
We need tasks anyway.
•  It is a good practice to break user stories into tasks
interna...
Lesson #5
Plan Parallelizeble work.
 	
  
Lesson #5/plan parallizeble work.
What is the cost of waiting?
•  Inter-story dependencies slow down / increase risk...
 	
  
Lesson #5/plan parallizeble work
Bonus: it Fixes the part-timer problem
•  Pt emps not advised by scrum (but we love...
Lesson #6
You can’t give exact launch date
for scope tbd.
 	
  
Lesson #6/ progressively elaborate time plans
When will it be done?
Task >> user story >> epic >> milestone >> proje...
 	
  
Lesson #6/ progressively elaborate time plans
Iteration backlog ß project backlog
elaboration
 	
  
Lesson #6/ progressively elaborate time plans
scopeTime
money
when time is fixed, investigate what isn’t.
Lesson #7
plan with refactoring in mind.
 	
  
Lesson #7/ don’t forget refactoring
Design the code/architecture incrementally
•  Be specific (opposite of abstract)...
 	
  
Lesson #7/ don’t forget refactoring
Refactor sprints or continuous refactor?
•  immediate code quality drop vs. imme...
 	
  
Lesson #7/ don’t forget refactoring
Communicating refactoring to customer
It is paid just as features are.
(or do yo...
Lesson #8
Don’t estimate tasks you don’t YET
know how to do.
 	
  
Lesson #8/ research “stories”
Don’t estimate this story:
US04: A logged user can invite (?) his facebook
friends to ...
 	
  
Lesson #8/ research “stories”
Estimate this one instead:
•  Rs-us04: find out what does it take to
integrate faceboo...
 	
  
Lesson #8/ research “stories”
“Spikes” (research tasks)
•  Focused Technical investigation
•  Reduce uncertainty/ris...
Lesson #9
Don’t forget what really matters
when testing.
 	
  
Lesson #9/add functional testing
What do you mean? we are doing Unit tests!
…and integration tests!
…and <insert you...
 	
  
Lesson #9/add functional testing
Code units tested with Unit tests
System tested with Integration tests
Business val...
 	
  
Lesson #9/add functional testing
Test business requirements before the customer
does!
•  A new role – functional tes...
 	
  
Lesson #9/add functional testing
Incorporating the func. tester
•  Creates test plans from acceptance criteria
•  Te...
Lesson #10
Be at least a bit cross-functional
(but don’t force it)
 	
  
Lesson #10/cross-functional team myth
•  Total Cross-functionality is a myth
•  It demands that everyone knows all a...
 	
  
Lesson #10/cross-functional team myth
•  We have a clearly stated technical leader
•  takes responsibility for techn...
 	
  
Lesson #10/cross-functional team myth
•  Single point of authority is okay, but
•  (almost) everyone is capable of s...
Agile means
•  Continuous feedback
•  Constant improvement
•  Regular deadlines
•  Better product
Take-aways
 	
  
	
  	
  
@apir47
linkedin.com/in/okruhlica
Thank you.
Upcoming SlideShare
Loading in...5
×

10 things we learned about Agile in VacuumLabs (2014 version)

337

Published on

Working on agile customer projects can be a hassle. Adam Okruhlica presents our learnings about working on demanding agile projects and how to get the most out of the methodology.

Warning: Common sense thinking included!

Published in: Software, Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
337
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

10 things we learned about Agile in VacuumLabs (2014 version)

  1. 1. AGILE/memoirs (Of one reasonably small but devoted developer team)          ADAM OKRUHLICA linkedin.com/in/okruhlica/
  2. 2. REQ! DSGN! impl! test WATERFALL
  3. 3. agile …"REQ"DSGN" impl"test"REQ"DSGN"IMPL"TEST"… < 1st sprint> < 2nd sprint>
  4. 4. BUT IT ALSO IS…
  5. 5. AN ONGOING EXPERIMENTATION
  6. 6. A Focus on FREQUENT stakeholder
  7. 7. The basics Anatomy of a sprint
  8. 8.     The basics/anatomy of a sprint order   dsgn   analysis     ux   html   css   devel     test   uat   order   dsgn   analysis     ux   html   css   sprint  X  é   sprint  X+1é  
  9. 9.     The basics/when not agile When not agile •  Manufacture-like project •  Fixed-price, fixed-scope, no changes •  Very small projects (< 1 mm)
  10. 10. Lesson #1 Sign an agile contract.
  11. 11.     Lesson #1/sign an agile contract Prepare for the Buts… “  But I already precisely know what I want. That’s great. but we would also love to give you the freedom to change plans mid-project. How about that?
  12. 12.     Lesson #1/sign an agile contract Prepare for the Buts… “  But I won’t pay for unfinished software! You’ll only be paying for working software. Moreso, you will have it working from the first weeks.
  13. 13.     Lesson #1/sign an agile contract Prepare for the Buts… “  BUT I DON’t HAVE TIME FOR regular REVIEWS. it seems the project is not that important for you. come back when it is.
  14. 14.     Lesson #1/sign an agile contract Adapt your contract •  Describe the agile process •  Verbalize the commitment to UAT after each sprint •  State and Fix your hourly rates •  Give a range price guarantees on certain scope (*if needed)
  15. 15. Lesson #2 Make sure they understand.
  16. 16.     Lesson #2/make sure they understand Agile is not a developers’ game. •  We are partners and we play along. •  Customer is part of the process. •  Every iteration must be planned in terms of business value.
  17. 17.     Lesson #2/make sure they understand Measuring Customer involvement Rules of thumb •  Do they ask how will this solve my problem? •  Are they proposing what to do next? •  Do they come up with refined functionalities? •  Do they want to get involved in standups? •  Do they use the product after sprints?
  18. 18. Lesson #3 Write bullet-proof user stories.
  19. 19.     Lesson #3/bullet-proof user stories Write a story in terms of business value (Not technical value) US01: smtp server is set up and class ‘mailsender‘ can reliably connect to it. US01: a user will receive an email upon registration.
  20. 20.     Lesson #3/bullet-proof user stories Use g-w-t structure to describe stories. US02: If a registered but unverified user [given] tries to log in to the system [when] , an appropriate warning is shown and the login action is revoked [then].
  21. 21.     Lesson #3/bullet-proof user stories Create a story hierarchy if needed. Us03: all Users get notified when their bank account changes. us03A: all users get an email when … US03b: all users get a system notification when… us03c: all users can edit their notification preferences…
  22. 22.     Lesson #3/bullet-proof user stories Use user stories as acceptance criteria* *Make sure to add this to your contract
  23. 23. Lesson #4 Story points AND manhours CAN COEXIST.
  24. 24.     Lesson #4/plan with manhours Story points give you a fair estimate. •  user stories get story points (1-2-3-5-8..) from the team •  Future stories are estimated against them relatively •  Team speed is measured by velocity (story points) •  Iterations are planned for the current velocity
  25. 25.     Lesson #4/plan with manhours however The Team Nature of work Dependencies demands Can change.
  26. 26.     Lesson #4/plan with manhours We need tasks anyway. •  It is a good practice to break user stories into tasks internally (code-oriented) •  Refining user story-based estimations by absolutely estimating individual tasks works better in volatile conditions (for us at least)
  27. 27. Lesson #5 Plan Parallelizeble work.
  28. 28.     Lesson #5/plan parallizeble work. What is the cost of waiting? •  Inter-story dependencies slow down / increase risk •  Optimizing throughput by planning non-dependent stories •  1-2 big story streams, complemented by small stories
  29. 29.     Lesson #5/plan parallizeble work Bonus: it Fixes the part-timer problem •  Pt emps not advised by scrum (but we love them) •  Simply Assign small/non-depending tasks to them
  30. 30. Lesson #6 You can’t give exact launch date for scope tbd.
  31. 31.     Lesson #6/ progressively elaborate time plans When will it be done? Task >> user story >> epic >> milestone >> project EASY TO ESTIMATE (FIXED) Subject to possible changes
  32. 32.     Lesson #6/ progressively elaborate time plans Iteration backlog ß project backlog elaboration
  33. 33.     Lesson #6/ progressively elaborate time plans scopeTime money when time is fixed, investigate what isn’t.
  34. 34. Lesson #7 plan with refactoring in mind.
  35. 35.     Lesson #7/ don’t forget refactoring Design the code/architecture incrementally •  Be specific (opposite of abstract) 1st time •  Be a bit more general 2nd time •  You get the idea…
  36. 36.     Lesson #7/ don’t forget refactoring Refactor sprints or continuous refactor? •  immediate code quality drop vs. immediate velocity drop
  37. 37.     Lesson #7/ don’t forget refactoring Communicating refactoring to customer It is paid just as features are. (or do you only pay builders when laying bricks?)
  38. 38. Lesson #8 Don’t estimate tasks you don’t YET know how to do.
  39. 39.     Lesson #8/ research “stories” Don’t estimate this story: US04: A logged user can invite (?) his facebook friends to the website by clicking “invite” and selecting from a list of friends (?).
  40. 40.     Lesson #8/ research “stories” Estimate this one instead: •  Rs-us04: find out what does it take to integrate facebook notification api for dart. They call me “spike”
  41. 41.     Lesson #8/ research “stories” “Spikes” (research tasks) •  Focused Technical investigation •  Reduce uncertainty/risk early •  Time-boxed to max. 1 sprint
  42. 42. Lesson #9 Don’t forget what really matters when testing.
  43. 43.     Lesson #9/add functional testing What do you mean? we are doing Unit tests! …and integration tests! …and <insert your test> tests!
  44. 44.     Lesson #9/add functional testing Code units tested with Unit tests System tested with Integration tests Business value tested with uat?
  45. 45.     Lesson #9/add functional testing Test business requirements before the customer does! •  A new role – functional tester •  Responsible for: validating ac, search for logical errors •  Can also: “debug” acceptance criteria, perf. Testing, ux testing, etc.
  46. 46.     Lesson #9/add functional testing Incorporating the func. tester •  Creates test plans from acceptance criteria •  Tests finished user stories during sprint •  Performs regression testing before delivery •  Smoke tests upon deployment to production
  47. 47. Lesson #10 Be at least a bit cross-functional (but don’t force it)
  48. 48.     Lesson #10/cross-functional team myth •  Total Cross-functionality is a myth •  It demands that everyone knows all agenda •  Architectural •  Business and procedural •  Design & ux, etc
  49. 49.     Lesson #10/cross-functional team myth •  We have a clearly stated technical leader •  takes responsibility for technical processes & architecture •  And an analyst / Product developer / team coordinator
  50. 50.     Lesson #10/cross-functional team myth •  Single point of authority is okay, but •  (almost) everyone is capable of short-term substitution out of his domain
  51. 51. Agile means •  Continuous feedback •  Constant improvement •  Regular deadlines •  Better product Take-aways
  52. 52.         @apir47 linkedin.com/in/okruhlica Thank you.
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×