Agile tour 2011 puiu mircea

Nov, 2011

Hands on tracking our SCRUM improving process

Planning for uncertainty 'Finished' does not mean 'complete' Observing the changes to be able to adapt

Agile tour 2011 – Hands on tracking our SCRUM improving process Mircea Puiu

Peter Drucker

(the father of modern management)

• Traditional planning asks:

What is most likely to happen?

• It is essential to frame things in a new way

• Planning for uncertainty asks instead:

What has already happened that will create the future?

SCRUM's Inspect & Adapt

2

Nov, 2011 Agile tour 2011 – Hands on tracking our SCRUM improving process

Early warning not visible during transition

Planning: either effective or less effective: constant effect not related to planning

(always after 4 days of a sprint)

CAUSE: 'Something' not accounted for when planning


3

We ignored uncertainty

The Cone of Uncertainty: a project management term used to describe the level of uncertainty existing at different stages of a project


4

We ignored uncertainty

User Stories not INVEST shaped

We really had no idea of what's required

We didn't know enough at that point to define the work

Not an 'effort estimating' issue!

a scoping issue

a risk management issue

BUT


5

Steps to manage uncertainty

1. Name, face, and accept uncertainties

2. Plan for uncertainty

understand that uncertainty cannot be wished or planned away

go for a balance between attempts to reduce the uncertainty and attempts to accommodate it

Use a wider range estimate to reflect the greater uncertainty Keep room for unplanned incoming work Break the work down into smaller units o Update the completion criteria based on better written user

stories

3. Adopt a deliberative or communicative approach

Make sprint execution visible to management o Make sprint execution visible to customers


6

Steps to manage uncertainty – we started planning for uncertainty

Accounting for: • knowledge transfer throughout the team • gaining skills • risk analysis


7

Steps to manage uncertainty – first sign that we went the right way

Good start in sprint

o Waiting for end of sprint to see if the unwanted effect is away


8

Steps to manage uncertainty – the confirmation


9

Well done at the end of the sprint

'Finished' does not mean 'complete'


10



11

The customer is not interested in "completed" activities on a planning chart

The customer is interested in delivered functionality (new or repaired)

Updating the completion criteria based on better written user stories

SCRUM's Inspect

SCRUM's Adapt

Updating the completion criteria based on better written user stories


Incorrect theme Hard to track

PBI = just a placeholder for 'something' intended to be done

Repaired functionality delivered

12


Further repairing foreseen for the next sprint(s)

Easier to track the "still to be done" work

Epic's polar map

13


'Finished' does not mean 'complete' a matter of wise decision

ReTasking Larger sprints vs.

– The longer the sprint, the harder for the feedback to come from the stakeholders

By keeping the sprints short, the stakeholders see more seldom the results

The more seldom they see

results, the more they feel their investment is returned

ReTasking fits very well to dynamic changes of requirements

14


'Finished' does not mean 'complete' building confidence

The more seldom the stakeholders see results ...

... the more they feel

... the bigger the deal each sprint review will be to the team

their investment is returned

win win

win

Customers

Managers

Devs

Observing the changes to be able to adapt


15

Observing the changes to be able to adapt 16


During each daily stand-up meeting, apart from answering to the classical three questions regarding "did", "impediments" and "will do", our team members answered to a fourth question:

How confident are you that the team will accomplish its objectives at the end of the sprint?

Objectives:

Estimate how responsive the team is to ReTasking (the newly introduced SBT state);

Estimate the trust within the team; Estimate how confident the team is in PO's support in case of ReTasking, as

any incoming work during the sprint execution is a disturbance to the running sprint process that the team must handle with success.



Good news:

The team is very responsive to any disturbance to the sprint execution process. The team members paid attention to the inputs and outputs.

The trust within the team continues to increase. Approaching the sprint end and

having tasks that have been linking the team members one to each other (in the sense that the start of one's work was dependent on the end of other's work), the team became pretty confident (a rating of 4 out 5) that they reach their goals at the end of the sprint.

When coming to ReTasking, the support received from the PO is highly important. And

here, the team sensed positively the presence of PO's support. Even though the sprint end was approaching and J continued to receive extra-work, while some of his current work needed to be ReTasked, the team was aware of the quick response of the PO in analyzing and handling the ReTasking, and expressed its trust in a good reaction (in due time) of the team and PO as a whole. In those conditions, the evaluation of the team for the chances to finish the sprint with success went up to 4!


19

1

2 3

Conclusions

1

2

3

Accept uncertainty and plan for it

„Finished“ ≠ „Complete“ update the completion criteria based on better written user stories o INVEST o ReTask

Observe the changes in order to be able to adapt

o Drucker on Management: Planning for Uncertainty, The Wall Street Journal, October 21, 2008. o Agile Estimation and the Cone of Uncertainty, Agile 101 at: http://agile101.net/2009/08/18/agile-

estimation-and-the-cone-of-uncertainty/ o The cone of uncertainty, Construx Software Development Best Practices at:

http://www.construx.com/Page.aspx?cid=1648 o The INVEST Model for User Stories, at: http://agilewisdom.wordpress.com/2011/01/21/the-

invest-model-for-user-stories/ o The Risks of SCRUM, Ralph Jocham, December 8, 2009 at:

http://www.slideshare.net/choose/ralph-jocham-the-risks-of-scrum-handout o Iterative, Incremental development - Continuous refactoring, Richard Kronfält, September 25,

2008, at: http://scrumftw.blogspot.com/2008/09/iterative-incremental-development.html o Scrum is a triple win proposition, Joseph Pelrine at:

http://www.metaprog.com/blogs/2009/02/scrum-is-a-triple-win-proposition/#comments

References:

http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/













http://www.construx.com/Page.aspx?cid=1648

http://agilewisdom.wordpress.com/2011/01/21/the-invest-model-for-user-stories/











http://www.slideshare.net/choose/ralph-jocham-the-risks-of-scrum-handout













http://scrumftw.blogspot.com/2008/09/iterative-incremental-development.html





http://www.metaprog.com/blogs/2009/02/scrum-is-a-triple-win-proposition/











Thank you for your attention .....

....please, debate


20

Mircea Puiu, Dpl.Eng, Ph.D , SCRUM Master E-mail: [email protected] Mobile: ++40 751 155 217

Agile tour 2011 puiu mircea

Technology

Transcript of Agile tour 2011 puiu mircea