Post on 01-Nov-2014
description
AGILE/memoirs (Of one reasonably small but devoted developer team)
ADAM OKRUHLICA linkedin.com/in/okruhlica/
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 uat
order dsgn analysis ux
html css
sprint X é
sprint X+1é
The basics/when not agile
When not agile • Manufacture-like project • Fixed-price, fixed-scope, no changes • Very small projects (< 1 mm)
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. but we would also love to give you the freedom to change plans mid-project. How about that?
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.
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.
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)
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. • Customer is part of the process. • Every iteration must be planned in terms of business value.
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?
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 is set up and class ‘mailsender‘ can reliably connect to it. US01: a user will receive an email upon registration.
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].
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…
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..) 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
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 internally (code-oriented)
• Refining user story-based estimations by absolutely estimating individual tasks works better in volatile conditions (for us at least)
Lesson #5 Plan Parallelizeble work.
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
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
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 >> project
EASY TO ESTIMATE (FIXED)
Subject to possible changes
Lesson #6/ progressively elaborate time plans
Iteration backlog ß project backlog
elaboration
Lesson #6/ progressively elaborate time plans
scope Time
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) 1st time • Be a bit more general 2nd time • You get the idea…
Lesson #7/ don’t forget refactoring
Refactor sprints or continuous refactor? • immediate code quality drop vs. immediate velocity drop
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?)
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 the website by clicking “invite” and selecting from a list of friends (?).
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”
Lesson #8/ research “stories”
“Spikes” (research tasks) • Focused Technical investigation • Reduce uncertainty/risk early • Time-boxed to max. 1 sprint
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 your test> tests!
Lesson #9/add functional testing
Code units tested with Unit tests
System tested with Integration tests Business value tested with uat?
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.
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
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 agenda • Architectural • Business and procedural • Design & ux, etc
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
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
Agile means • Continuous feedback • Constant improvement • Regular deadlines • Better product
Take-aways
@apir47 linkedin.com/in/okruhlica
Thank you.