1st

Commandment

"You shall not steal time from Kickoff meetings"​

www.cngroup.dk

Agile means rush

Typical mistake is not invest proper time on kickoff

Kickoff is success driver

With rough requirements kickoff is the place to minimise misunderstandings

Proper Kickoff agenda

• Product backlog refinement

  • Out of Scope, Prerequisites,

  • Non-Functional requirements

• Poker Planning

• Definition of Done

• Project cooperation rules

  • Meetings, Roles, US Workflow, Tools, LL,..

2nd

Commandment

"You shall not murder Poker Planning"​

www.cngroup.dk

Poker Planning

• getting high level estimates

• understanding requirements

• much more but it depends on how you do the technique

Murder technique No. 1

Do not try at home!

Not doing the estimation secretly

I think

8

5 8

?!?

Senior

Murder technique No. 2

Do not try at home!

Enabling cheating

8

Murder technique No. 3

Do not try at home!

Stopping the discussion

Poker planning DONE right:

• More accurate estimates

• Identifiy what needs to be defined

• Reduce misunderstandings

• Out of scope reminder

• New User Stories revelation

• Give space to less assertive people

• Helps PO understand effort

• Story Point estimation > MD estimation

• Use past velocity to improve prediction

3rd

Commandment

"You shall not take the name of STAND UP in vain"​

www.cngroup.dk

15 min. standups

And we are always too long and not on time

Familiar?

Restrict it to 3 questions

• What has been Done since last time

• Am I blocked?

• What are my plans for today

• If it doesn't help... try 1 leg standup

4th

Commandment

"You shall have no other GODS before PO"​

www.cngroup.dk

Remember good old Waterfall days

Source: NoEstimates book (Vasco Duarte)

Humphrey's law

The user of the software won’t know what she wants until she sees the software.

— Humphrey 's law

Who should attend Review/Demo

• Product owner (PO)

• Stakeholders

• End user

• PO of other teams

5th

Commandment

"Remember the Retrospective day, to keep it holy"​

www.cngroup.dk

How NOT to start Retro!

Does anybody have anything for Retro?

Retrospective time... so talk!

Skipping it and not doing at all

You can do Retro better!

• Physical retros over tools

• Experiment with different formats

• Do not criticise!

• Store your inputs and check if they were done!

• Select HERO of the sprint!

6th

Commandment

"Product Owner shall not commit adultery with other priorities"​

www.cngroup.dk

Ideal Product Owner

Product Owners = Managers

Busy!

Bad Product Owner

7th

Commandment

"Distributed teams shall not covet what have the collocated ones"​

www.cngroup.dk

Collocated teams as a must

Your projects are not agile if your teams are not collocated!

Collocated team

Sitting together however not communicating with each other

Distributed team

With good relationship and communication on good level

2017 Agile survey says

Source: 11th Annual state of Agile Report (VersionOne)

8th

Commandment

"Honour your Agile father

and Lean mother"​

www.cngroup.dk

Top problems agile projects are facing

Source: 11th Annual state of Agile Report (VersionOne)

Agile projects works in agile environment

• How much your company culture supports Agile?

• How much are you agile within management?

• How much do you embrace:

  • ​Communication, Transparency, Continues improvement

Within CN GROUP management

• Regular Management retrospectives

• Retrospective points can be your backlog

• Sprint can be time until next retrospective​

• Do a small review on coordination meetings

• Standup behaviour on management meetings

9th

Commandment

"You shall not make Agile idolatry"​​

www.cngroup.dk

Don't do Agile by the book

Every project is unique and deserves tailor-made solution

10th

Commandment

"You shall not bear false estimates to your PO

www.cngroup.dk

Estimation success rate

Source: NoEstimates book (Vasco Duarte)

Why estimates do not work?

Psychological aspects

Estimates are just personal ideas which are easily affected by

Parkinson's law

Work expands so as to fill the time available for its completion.

— Parkinson's law

Accidental complication

Cost of feature = f(g(e), h(a))

g(e) Essential complication

h(a) Accidental complication

- How hard the problem is itself

- Complication that comes out of our organizational structure and how programs are written.

— J.B. Rainsberger

Conclusion No. 1:

Accidental complication dominates the cost of the feature!

Conclusion No. 2:

Following best practices by doing Poker Planning right is just:

Reducing Accidental Complication

Possible solutions:

Measure and improve your accidental complication (Buffers)

noEstimates approach

OR

NoEstimates

Doesn't have to mean no estimation at all

1. Reduce estimation work to the minimum necessary, and then reduce it a bit more

2. Slicing stories right and as small as possible

3. Value Focused development

4. Measuring and having consistent rate of progress (Stories delivered/sprint)

• Breaking down stories help us assess progress faster & help with scope decision

- Vasco Duarte