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.