Feedback Loops in Agile Development

Feedback Loops in Agile Developmentfrom the basic concepts to a prescriptive start Jamie Allsop http://www.agile-trac.org

Who Am I● On a payroll running distributed agile teams since 2004● Worked across different sectors in the software industry, from coding specialised DSP algorithms to delivering financial products worth 10s of millions in revenue● Currently in a company hoping to scale revenue significantly within the next two years by scaling and growing their software products● C++ Developer and co-author of a book on C++● Creator of agile-trac plugin http://www.agile-trac.org

Overview● Setting the context...Typical Development ● And why it can suck● Enter Agile Development...and useful Feedback ● What an Agile Methodology entails ● User Stories ● Agile Estimating and Planning ● Feedback in Agile Development● Tool Support and Practices ● Source Control Management ● Automation, Automation, Automation● A Brief Prescription

Typical Development● Inputs to development are usually ● Product Requirements Documents from marketing and business development (new development) ● Ticket Issues from customers (continuing development)● Product Requirements Documents ● full product specification generated up front ● used by development to create a Software Requirements Document● Transform Requirements Documents into a Development Plan ● develop a Gantt chart and Spreadsheets to provide an estimate of the work involved, typically covering a full release● Progress measured by Task Completion per Resource● Ticket Issues generally become deviation points for the plan

Typical Development● Inputs to development are usually ● Product Requirements Documents from marketing and business development (new development) Gat Gat ed I ed In Ticket Issues from customers (continuing development) ● nputs puts Product Requirements Documents used● full product Task Task used to D Deli to De specification generated up front Dtolcreate a Software r e ive ● very ry = P eriive = Prointo ve Task ● used by development Requirements Document● r gre Tasks Transform Requirements Documentsog a Development Plan ress s ● ss develop a Gantt chart and Spreadsheets to provide an estimate of the work involved, typically covering a full release● Progress measured by Task Completion per Resource● Ticket Issues generally become deviation points for the plan

Problems with Typical Development● Tasks are hard to trace to business value● Emphasis is on following a plan● The Plan is always out-of-date - changing it is heavyweight● Very difficult to assess where we are NOW● Incremental delivery of Product is hard as Tasks are not aligned with User Value● Incoming Issues deflect and interrupt the Plan – poor integration● Emphasis on where we would like to be: not where we are, or where we could be. Basically “wishful planning”

Problems with Typical Development● Tasks are hard to trace to business value● Emphasis is on following a plan● The Plan is always out-of-date - changing it is heavyweight Very difficult to assess where we are NOWllan P an P nhard e Tasksaare not iin Th e tais Thas rhe ad● Incremental delivery of Product a maiin t an he d full to m ve tiime ove r aligned with aiin fu to e ove● Pa n PUser Value iive t m mass interrupt the Plan – poor ass Incoming Issueses a a mand uiir es Req u r deflect integration q● Re● Emphasis on where we would like to be: not where we are, or where we could be. Basically “wishful planning”

Problems with Typical Development● Tasks are hard to trace to business value● Emphasis is on following a plan● The Plan is always out-of-date - changing it is heavyweight Some where we are NOW n S assess Very difficult to ometim times es man iin T h e Plla n he P a● n aniifeTt erhe ad mtaisfhard as Tasksaare not Incremental delivery of Product a nes Protje maiint Proto c a he d full jo ct Mvan tiimseeod er e m Ma t ov a m v s e ed as● aligned with aiin fu User Value t n Pa P nt r ssiive agers e ag e a ma ss interrupt the Plan – poor deflect a Incoming Issueses a mand iir es s Requ r Re u integration q●● Emphasis on where we would like to be: not where we are, or where we could be. Basically “wishful planning”

Progress is Measured Against the First, and Most Inaccurate, Estimate● Garbage in – Garbage Out● ISO 9001 – Clean Pipes, Dirty Water – Focus on how things are done, not why things are done● RAG status – How we are doing against our most inaccurate estimate? – Green for the lifetime of a delivery but still be late? R – Red for the lifetime of a delivery but be early? A – What does late and early actually mean? – We can base performance metrics on this data G● Focus on gated delivery and traceability● Often unclear whats done and whats not

Progress is Measured Against the First, and Most Inaccurate, Estimate● Garbage in – Garbage Out● ISO 9001 – Clean Pipes, Dirty Water – Focus on how things are done, not why things lu a eue lare done Va d V our most RAG status – How we are doingiite d te against Liim● inaccurate estimate? of Lm – Green for the lifetime of ck of ba ck R baadelivery but be early? a delivery but still be late? – Red for the lifetimed ee d ee of Fand early actually mean? F A – What does d iim m te d te late iibase performance metrics on this data G LL – We can● Focus on gated delivery and traceability● Often unclear whats done and whats not

Just iterating is not enough...● Bad data more often, doesnt make it good data● Reacting more often to bad data is worse● Reinforces bad habits● Insufficient time and freedom to make positive changes● Lack of useful data to build feedback loops gives you the overhead of iterations without the benefits● Keeping plans up-to-date is very expensive

Just iterating is not enough...● Bad data more often, doesnt make it good data● Reacting more often to bad data is worse Reinforces bad habits nent a ne nt● Perto a erm make positive P m● akes M akes ct Insufficient time and freedom tiice M erfe ct changes Prac t ce Prac NOT P erfe TP● NO build feedback loops Lack of useful data to gives you the overhead of iterations without the benefits● Keeping plans up-to-date is very expensive

What can we do?● Shift our focus from Plans that deliver Tasks● Instead focus on Planning and Value delivery● Observe and learn from Feedback paths● Avoid reacting to bad data● Understand what has been delivered● Have a view on what is still left to be done● Easier said than done...

What can we do?● Shift our focus from Plans that deliver Tasks Instead focus on Planning and Value delivery p......● ellp paths Observe and learn from Feedback n he an h t ca● nt c Avoid reacting to badme n me op data ellop● ev e been delivered D ev Understandille D has what gi e● Ag A● Have a view on what is still left to be done● Easier said than done...

Agile Development is Value Driven

Agile Development is Value Driven 30% Complete T3 T2 T1

Agile Development is Value Driven 30% Complete S1 S2 S3 T3 T2 T1

Agile Development is Value Driven 30% Complete Little or No User ValueTask to Value Correlation Low S1 S2 S3 T3 T2 T1

Agile Development is Value Driven 30% Complete Little or No User Value Means 30% DONETask to Value Correlation Low 30% User Value Delivered S1 S2 S3 T3 T2 T1

Agile Development is Value Driven 30% Complete Little or No User Value Means 30% DONETask to Value Correlation Low 30% User Value Delivered S1 S2 S3 T3 T2 T1 Selection of Ingredients vs Slices of the Cake

Where to begin...?

http://www.halfarsedagilemanifesto.org/ Where to begin...?

Where to begin...?http://www.halfarsedagilemanifesto.org/ d...... sse d A sse H H allf- A a f- iing e ng of b e of b are w ar e Be w Be

Lets try again Point your browser tohttp://agilemanifesto.org/

The Agile Value System

We All Need Principles● Early and continuous delivery of valuable software● Welcome changing requirements● Deliver working software frequently● Business people and developers work together● Trust motivated individuals● Working software is the primary measure of progress● Promote sustainable development● Technical excellence and good design● Simplicity is essential● Self-organising teams● Team reflection and adjustment● Face to Face Communication is the most effective

We All Need Principles● F ee F Early and continuous ack dbac k eedbdelivery of valuable software● Welcome changing requirements● Deliver working software frequently● Business people and developers work together● Trust motivated individuals● Working software is the primary measure of progress● Promote sustainable development● Technical excellence and good design● Simplicity is essential● Self-organising teams● Team reflection and adjustment● Face to Face Communication is the most effective

We All Need Principles● F ee F Early and continuous ack dbac k eedbdelivery of valuable software k● eedbac k F ee dbac Welcome changing requirements F● Deliver working software frequently● Business people and developers work together● Trust motivated individuals● Working software is the primary measure of progress● Promote sustainable development● Technical excellence and good design● Simplicity is essential● Self-organising teams● Team reflection and adjustment● Face to Face Communication is the most effective

We All Need Principles● F ee F Early and continuous ack dbac k eedbdelivery of valuable software k● eedbac k F ee dbac Welcome changing requirements F k● F eedbac k Deliver working software frequentlyee F dbac● Business people and developers work together● Trust motivated individuals● Working software is the primary measure of progress● Promote sustainable development● Technical excellence and good design● Simplicity is essential● Self-organising teams● Team reflection and adjustment● Face to Face Communication is the most effective

We All Need Principles● F ee F Early and continuous ack dbac k eedbdelivery of valuable software k● eedbac k F ee dbac Welcome changing requirements F k F eedbac k Deliver working software frequentlyee F dbac back●● eedbac k Business people and developers work together d F ee F● Trust motivated individuals● Working software is the primary measure of progress● Promote sustainable development● Technical excellence and good design● Simplicity is essential● Self-organising teams● Team reflection and adjustment● Face to Face Communication is the most effective

We All Need Principles● F ee F Early and continuous ack dbac k eedbdelivery of valuable software k● eedbac k F ee dbac Welcome changing requirements F k F eedbac k Deliver working software frequentlyee F dbac back●● eedbac k Business people and developers work together d F ee F● Trust motivated individuals ck● Feedba ck Fe Working software is the primary measure of progress edba● Promote sustainable development● Technical excellence and good design● Simplicity is essential● Self-organising teams● Team reflection and adjustment● Face to Face Communication is the most effective

We All Need Principles● F ee F Early and continuous ack dbac k eedbdelivery of valuable software k● eedbac k F ee dbac Welcome changing requirements F k F eedbac k Deliver working software frequentlyee F dbac back●● eedbac k Business people and developers work together d F ee F● Trust motivated individuals ck● Feedba ck Fe Working software is the primary measure of progress edba● Promote sustainable development● Technical excellence and good design● Simplicity is essential● Self-organising teams k● F eedbac k Team reflection and adjustment ee F dbac● Face to Face Communication is the most effective

We All Need Principles● F ee F Early and continuous ack dbac k eedbdelivery of valuable software k● eedbac k F ee dbac Welcome changing requirements F k F eedbac k Deliver working software frequentlyee F dbac back●● eedbac k Business people and developers work together d F ee F● Trust motivated individuals ck● Feedba ck Fe Working software is the primary measure of progress edba● Promote sustainable development● Technical excellence and good design● Simplicity is essential● Self-organising teams k● F eedbac k Team reflection and adjustment ee F dbac● Face to Face Communication is the mosteedback F eedback effective F

The Essence of Agile● Incrementally delivering actual value to the stakeholders● Coping deterministically with change: not trying to protect against it● Recognising that a productive environment for developers leads to more productivity in general and higher quality overall● Observing how well we work and adapting to make improvements● Maximising project transparency, fostering shared ownership and a shared vision of the project

The Essence of Agile● Incrementally delivering actual value to the stakeholders Coping deterministically with change: not trying to Ma x M ax● Thi T im protecthagainst itimi is iis s s ise U se U Recognising a mu productive environment for a ma that u s ef sefu ch b ull Fe ch b productivity in general and● developers leads to more ette Feedba e tt edb higher quality overall er p r plla ack ck ace ce to to s t star Observing how well we work and adapting to make art● improvements t● Maximising project transparency, fostering shared ownership and a shared vision of the project

Agile Development in a Nutshell

Agile Development in a Nutshell STARTIncubation Incubation

Agile Development in a Nutshell STARTIncubation Incubation Initiation Initiation

Agile Development in a Nutshell START Incubation Incubation Initiation Initiation User Stories Story 12 Story 2Story 1 Story 17 Story 13 Story 3Story 6 Story 7 Story 9Story 14 Story 4 Story 10 Story 8 Story 5 Story 16 Story 11 Story 15 Story 12 Story 18 Story 22Story 23 Story 21 Story 25 Story 19 Story 24 Story 20

Agile Development in a Nutshell START Incubation Incubation Initiation Initiation User Stories Story 12 Story 2Story 1 Story 17 Story 13 Story 3 ArchitectureStory 6 Story 7 Story 9 ArchitectureStory 14 Story 4 Story 10 Story 8 Story 5 Story 16 Story 11 Story 15 Story 12 Story 18 Story 22Story 23 Story 21 Story 25 Story 19 Story 24 Story 20

Agile Development in a Nutshell START Incubation Incubation Initiation Initiation TacitKnowledge User Stories Story 12 Story 2 Story 1 Story 17 Story 13 Story 3 Architecture Story 6 Story 7 Story 9 Architecture Story 14 Story 4 Story 10 Story 8 Story 5 Story 16 Story 11 Story 15 Story 12 Story 18 Story 22 Story 23 Story 21 Story 25 Story 19 Story 24 Story 20

Agile Development in a Nutshell START Incubation Incubation Initiation Initiation TacitKnowledge User Stories Story 12 Story 2 Story 1 Story 17 Story 13 Story 3 Architecture Story 6 Story 7 Story 9 Architecture Story 14 Story 4 Story 10 Story 8 Story 5 Story 16 Story 11 Story 15 Story 12 Story 18 Story 22 Story 23 Story 21 Story 25 Story 19 Story 24 Story 20 M1 M2 M3 Mn

Agile Development in a Nutshell START Incubation Incubation Initiation Initiation Tacit SharedKnowledge User Stories Vision Story 12 Story 2 Story 1 Story 17 Story 13 Story 3 Architecture Story 6 Story 7 Story 9 Architecture Story 14 Story 4 Story 10 Story 8 Story 5 Story 16 Story 11 Story 15 Story 12 Story 18 Story 22 Story 23 Story 21 Story 25 Story 19 Story 24 Story 20 M1 M2 M3 Mn

Agile Development in a Nutshell START Incubation Incubation User Stories Iteration Planning Iteration Planning Initiation Initiation Tacit SharedKnowledge User Stories Vision Story 12 Story 2 Story 1 Story 17 Story 13 Story 3 Architecture Story 6 Story 7 Story 9 Architecture Story 14 Story 4 Story 10 Story 8 Story 5 Story 16 Story 11 Story 15 Story 12 Story 18 Story 22 Story 23 Story 21 Story 25 Story 19 Story 24 Story 20 M1 M2 M3 Mn

Agile Development in a Nutshell START Iteration Development Iteration Development Incubation Incubation User Stories Design Task List Write Tests Code Iteration Planning Iteration Planning Refactor Initiation Initiation User Doc Acceptance Tests Use Cases y da Update 1 Status Test Tacit Shared CasesKnowledge User Stories Vision Story 12 Story 2 Story 1 Story 17 Story 13 Story 3 Architecture Story 6 Story 7 Story 9 Architecture Story 14 Story 4 Story 10 Story 8 Story 5 Story 16 Story 11 Story 15 Story 12 Story 18 Story 22 Story 23 Story 21 Story 25 Story 19 Story 24 Story 20 M1 M2 M3 Mn

Agile Development in a Nutshell START Iteration Development Iteration Development Incubation Incubation User Stories Design Task List Write Tests Code Iteration Planning Iteration Planning Refactor Initiation Initiation User Doc Acceptance Tests Use Cases y da Update 1 Status Test Tacit Shared CasesKnowledge User Stories Vision Working Software Story 2 Story 12 & Documentation Story 1 Story 17 Story 13 Story 3 Architecture Story 6 Story 7 Story 9 Architecture Story 14 Story 4 Story 10 Story 8 Story 5 Story 16 Story 11 Story 15 Story 12 Story 18 Story 22 Story 23 Story 21 Story 25 Story 19 Story 24 Story 20 M1 M2 M3 Mn

Agile Development in a Nutshell START Iteration Development Iteration Development Incubation Incubation Tacit User Stories Knowledge Design Task List Write Tests Code Iteration Planning Iteration Planning Refactor Initiation Initiation User Doc Acceptance Tests Use Cases y da Update 1 Status Test Tacit Shared CasesKnowledge User Stories Vision Working Software Story 2 Story 12 & Documentation Story 1 Story 17 Story 13 Story 3 Architecture Story 6 Story 7 Story 9 Architecture Story 14 Story 4 Story 10 Story 8 Story 5 Story 16 Story 11 Story 15 Story 12 Story 18 Story 22 Story 23 Story 21 Story 25 Story 19 Story 24 Story 20 M1 M2 M3 Mn

Agile Development in a Nutshell START Iteration Development Iteration Development Incubation Incubation Tacit User Stories Knowledge Design Task List Write Tests Code Iteration Planning Iteration Planning Refactor Initiation Initiation User Doc Acceptance Tests Use Cases y da Update 1 Status Test Tacit Shared CasesKnowledge User Stories Vision Working Software Story 2 Story 12 & Documentation Story 1 Story 17 Story 13 Story 3 Architecture Story 6 Story 7 Architecture Story 14 Story 9 Story 4 Iteration Review Iteration Review Story 10 Story 8 Story 5 Story 16 Story 11 Story 15 Story 12 Story 18 Story 22 Story 23 Story 21 Story 25 Story 19 Story 24 Story 20 M1 M2 M3 Mn

Agile Development in a Nutshell START Iteration Development Iteration Development Incubation Incubation Tacit User Stories Knowledge Design Task List Write Tests Code Iteration Planning Iteration Planning Refactor Initiation Initiation User Doc Acceptance Tests Use Cases y da Update 1 Status Test Tacit Shared CasesKnowledge User Stories Vision Working Software Story 2 Story 12 & Documentation Story 1 Story 17 Story 13 Story 3 Architecture Story 6 Story 7 Architecture Story 14 Story 9 Story 4 Iteration Review Iteration Review Story 10 Story 8 Story 5 Story 16 Story 11 Story 15 Story 12 Story 18 Story 22 Story 23 Story 21 Story 25 Story 19 Iteration Retrospective Iteration Retrospective Story 24 Story 20 M1 M2 M3 Mn

Agile Development in a Nutshell START Iteration Development Iteration Development Incubation Incubation Tacit User Stories Knowledge Design Task List Write Tests Code Iteration Planning Iteration Planning Refactor Initiation Initiation User Doc Acceptance Tests Use Cases y da Update 1 Status Test Tacit Shared CasesKnowledge User Stories Vision Working Software Story 2 Story 12 & Documentation Story 1 Story 17 Story 13 Story 3 Architecture Story 6 Story 7 Architecture Story 14 Story 9 Story 4 Iteration Review Iteration Review Story 10 Story 8 Story 5 Story 16 Story 11 Story 15 Story 12 Story 18 Story 22 Story 23 Story 21 Story 25 Story 19 Iteration Retrospective Iteration Retrospective Story 24 Story 20 Ownership M1 M2 M3 Mn Evolution

Agile Development in a Nutshell START Iteration Development Iteration Development Incubation Incubation Tacit User Stories Knowledge Design Task List Write Tests Code Iteration Planning Iteration Planning Refactor Initiation Initiation User Doc Acceptance Tests Use Cases y da Update 1 Status Test Tacit Shared CasesKnowledge User Stories Vision Working Software Story 12 & Documentation Story 2 Issues Issues POs Story 1 Story 17 Story 13 Defects POs Requests Story 3 User Stories Architecture Story 6 Story 7 Architecture User Story Story 14 Story 9 Story 4 M1 M2 M3 GA Mn User Story User Story Iteration Review Iteration Review Story 10 Story 8 Story 5 Story 16 Story 11 Story 15 Story 12 Story 18 Release Planning Story 22 Release Planning Story 23 Story 21 Story 25 Story 19 Iteration Retrospective Iteration Retrospective Story 24 Story 20 Ownership M1 M2 M3 Mn Evolution

Agile Development in a Nutshell START Iteration Development Iteration Development Incubation Incubation Tacit User Stories Knowledge Design Task List Write Tests Code Iteration Planning Iteration Planning Refactor Initiation Initiation User Doc Acceptance Tests Use Cases y da Update 1 Status Test Tacit Shared CasesKnowledge User Stories Vision Working Software Story 12 & Documentation Story 2 Issues Issues POs Story 1 Story 17 Story 13 Defects POs Requests Story 3 User Stories Architecture Story 6 Story 7 Architecture User Story Story 14 Story 9 Story 4 M1 M2 M3 GA Mn User Story User Story Iteration Review Iteration Review Story 10 Story 8 Story 5 Story 16 Story 11 Story 15 Story 12 Story 18 Release Planning Story 22 Release Planning Story 23 Story 21 Story 25 Story 19 Iteration Retrospective Iteration Retrospective Story 24 Story 20 Shared Vision Ownership M1 M2 M3 Mn Evolution

Agile Development in a Nutshell START ITERATE Iteration Development Iteration Development Incubation Incubation Tacit User Stories Knowledge Design Task List Write Tests Code Iteration Planning Iteration Planning Refactor Initiation Initiation User Doc Acceptance Tests Use Cases y da Update 1 Status Test Tacit Shared CasesKnowledge User Stories Vision Working Software Story 12 & Documentation Story 2 Issues Issues POs Story 1 Story 17 Story 13 Defects POs Requests Story 3 User Stories Architecture Story 6 Story 7 Architecture User Story Story 14 Story 9 Story 4 M1 M2 M3 GA Mn User Story User Story Iteration Review Iteration Review Story 10 Story 8 Story 5 Story 16 Story 11 Story 15 Story 12 Story 18 Release Planning Story 22 Release Planning Story 23 Story 21 Story 25 Story 19 Iteration Retrospective Iteration Retrospective Story 24 Story 20 Shared Vision Ownership M1 M2 M3 Mn Evolution

Milestones, Iterations & Releases Milestone A Milestone B Iteration x Iteration x+1 Iteration x+2 Time

Milestones, Iterations & Releases Milestone A Milestone B Iteration x Iteration x+1 Iteration x+2User Stories Completed Over Time Time

Milestones, Iterations & Releases Milestone A Milestone B Iteration x Iteration x+1 Iteration x+2 User Stories Completed Over Time TimeRelease at end of Iteration Internal External Release x

Milestones, Iterations & Releases Milestone A Milestone B Iteration x Iteration x+1 Iteration x+2 User Stories Completed Over Time TimeRelease at end of Iteration Internal Milestone A External Release x Release x+1

Milestones, Iterations & Releases Milestone A Milestone B Iteration x Iteration x+1 Iteration x+2 User Stories Completed Over Time TimeRelease at end of Iteration Internal Milestone A External Release x Release x+1 Release x+2

Milestones, Iterations & Releases Milestone A Milestone B Iteration x Iteration x+1 Iteration x+2 User Stories Completed Over Time TimeRelease at end of Iteration Internal Milestone A External Release x Release x+1 Release x+2Release at end Milestone A of Milestone Internal External

Milestones, Iterations & Releases Milestone A Milestone B Iteration x Iteration x+1 Iteration x+2 User Stories Completed Over Time TimeRelease at end of Iteration Internal Milestone A External Release x Release x+1 Release x+2Release at end Milestone A of Milestone Internal External Release A?

Milestones, Iterations & Releases● Milestones are prioritised collections of User Stories● Iterations are fixed-length, time-boxed periods over which User Stories are Delivered● Release scope is defined by the User Stories it contains, not the Iteration it is delivered in● You may time Releases with Iterations but the scope will always be bounded by the Stories● Think of a Release as an Externalised Milestone

Milestones, Iterations & Releases● Milestones are prioritised collections of User Stories Miilles M est tones on fixed-length, time-boxed periods Iterations are es Grou● Itera Iterat Group tiio User p & Pr Delivered over whichons DeStories&areiiorit ns Del Pr or Rellea Re eas liiver T ver Th itiise S se Sto ses Ex is defined em the UsertStories it es Ex Release scope ter hem in by in T oriies r es ternal Tiime-b● naliise it is deliveredoin contains, not the Iterationto Ss e to me-b Stake oxes x es takeho hollder● You may time Releases with Iterationsdbut the ers s scope will always be bounded by the Stories● Think of a Release as an Externalised Milestone

User Stories: Sized, Measurable Units of Value● Identifies the need to Deliver Value to a User without committing to all the details● Just-In-Time Understanding● Captures both functional and non-functional requirements in a uniform way● Stories Relatively Sized from a fixed scale 1 2 3 5 8 13 20 40 100 A reasonable size to consider Too large to consider for work in an for work in an Iteration. Iteration. Needs to be split.

User Story Dependency View Implicit Implementation Ordering● The flatter this view the more flexible the release planning Dependency View of User Stories

User Story Dependency View Implicit Implementation Ordering● The flatter this view the more flexible the release planning Dependency View of User Stories iings h ngs me t h ers o me t h ers fe:: S o re ot h iife S o e ot of L t of L n bef or Fac t Fac e n bef happ e h ap p ha h ve to a ve to

User Story Dependency View Implicit Implementation Ordering● The flatter this view the more flexible the release planning Dependency View of User Stories Howe Howev ver cle er clev iings h ngs allllow a ow ver SSome t h er :SSo me t e : t ory Se others Spif iLiif e t ory r pli thers Spif iL f o k ng t befo Se lottiing act o k ngethrou or p it t ng can F ac t F app pp n r efgh enhbough can ve to h a e to h the t the tr ree ha v ha ee

Split Large Stories as their Priority Increases● Large Stories in upcoming milestones should be split● Stories too big for an iteration must be split● This is not easy, but improves understanding● The User Story Tree gets broader and deeper SystemAdmin should be SourceAdmin should have able to enjoy an the ability, within the SourceAdmin can AWESOME automated context of this product, configure which sources install on Windows 2000, to report on sources are collectable. XP, 2003 available to the product SourceAdmin SourceAdmin SourceAdmin can ... can ... ... can ... SystemAdmin ... can ... SourceAdmin can ... SystemAdmin should ... SourceAdmin SourceAdmin can ... should ... SystemAdmin can ... SystemAdmin Capability View of User Stories SourceAdmin will ... will ...

Split Large Stories as their Priority Increases● Large Stories in upcoming milestones should be split● Stories too big for an iteration must be split This is not easy, but improves understanding iiew biilliity V ew Capa b ty V pa ugh the Ca and deepercture ugh the● The Userkiing Th ro StoryTh ro gets broader chiite cture Spiik n Sp g Tree the Ar ch te ugh the Ar● g th r o u g h piikiin g thro llllows S p k n a ow s S SystemAdmin should be SourceAdmin should have a able to enjoy an the ability, within the SourceAdmin can AWESOME automated context of this product, configure which sources install on Windows 2000, to report on sources are collectable. XP, 2003 available to the product SourceAdmin SourceAdmin SourceAdmin can ... can ... ... can ... SystemAdmin ... can ... SourceAdmin can ... SystemAdmin should ... SourceAdmin SourceAdmin can ... should ... SystemAdmin can ... SystemAdmin Capability View of User Stories SourceAdmin will ... will ...

From Not Done to DONE● We want consistent delivery of User Stories● We plan to deliver User Stories NOT Tasks● Sizing and Iterations allow us to predict future work

From Not Done to DONE● We want consistent delivery of User Stories● We plan to deliver User Stories NOT Tasks● Sizing and Iterations allow us to predict future work 5 1 13 8 2 5 1 8 20 3 3 1 5 2 13 5 3 40 8 5 5 3 2 5 13 8 3 1 8 2 13 1 13 20 20 8 100 5 8 3 13

From Not Done to DONE● We want consistent delivery of User Stories● We plan to deliver User Stories NOT Tasks● Sizing and Iterations allow us to predict future work 5 1 13 8 2 5 1 3 8 20 Time and Effort 3 1 5 2 13 5 3 40 8 5 5 3 2 5 13 8 3 1 8 2 13 1 13 20 20 8 100 5 8 3 13

From Not Done to DONE● We want consistent delivery of User Stories● We plan to deliver User Stories NOT Tasks● Sizing and Iterations allow us to predict future work 8 Time and Effort 3 1 5 2 13 5 2 3 40 1 8 3 5 5 3 2 2 8 5 5 13 8 3 1 8 5 3 8 2 13 1 13 5 1 13 20 20 8 100 13 5 8 3 13 8 8

Planning to Deliver “Planning is everything, plans are nothing”● Agile focuses on the practice of planning but avoids trying to follow a plan● We do planning to help us understand where we might be in the future, based on what we know today, and what we observed in the past● Planning allows us to continually update our view of the future for the short, medium and long term● In Agile we plan at several levels and throughout the development of a product

Planning to Deliver “Planning is everything, plans are nothing”● Agile focuses on the practice of planning but avoids trying to follow a plan rst and dwhattwed We do planning to help us understandawhere we n de rs n know might be in the future,etter u n e● b et t er u to b based on atiing e whatd toobservedtiin the ng needwe today, W e nee d Est im at past W and n Es m niing a nd● Pllan n nto a P an us g continually update our view of Planning allows the future for the short, medium and long term● In Agile we plan at several levels and throughout the development of a product

Understand Different Levels of Planning

Understand Different Levels of Planning Strategy

Understand Different Levels of Planning Strategy Portfolio

Understand Different Levels of Planning Product is composed of Releases Strategy Portfolio Product

Understand Different Levels of Planning Product is composed of Releases Milestone 1 Strategy Portfolio Product Release

Understand Different Levels of Planning Product is composed of Releases Milestone 1 Milestone 2 is Release 1.0 Strategy Portfolio Product Release

Understand Different Levels of Planning Product is composed of Releases Milestone 1 Milestone 2 is Release 1.0 Milestone 3 Strategy Portfolio Product Release

Understand Different Levels of Planning Product is composed of Releases Milestone 1 Milestone 2 is Release 1.0 Milestone 3 Strategy Portfolio Product Release Iteration 1

Understand Different Levels of Planning Product is composed of Releases Milestone 1 Milestone 2 is Release 1.0 Milestone 3 Strategy Portfolio Product Release Iteration 1 Iteration Task Time Design X 1 hour Implement X ½ day Implement Y 4 days Meetings 1 hour Automate Tests 2 days

Understand Different Levels of Planning Product is composed of Releases Milestone 1 Milestone 2 is Release 1.0 Milestone 3 Strategy Portfolio Product Release Iteration 1 Iteration Task Time Design X 1 hour Implement X ½ t? day midays m4 Implement Y Co MeetingsC an 1 hour Automate Tests 2 days

Understand Different Levels of Planning Product is composed of Releases Milestone 1 Milestone 2 is Release 1.0 Milestone 3 Strategy Portfolio Product Release Iteration 1 Iteration 2 Iteration Task Time Design X 1 hour Implement X ½ t? day midays m4 Implement Y Co MeetingsC an 1 hour Automate Tests 2 days

Understand Different Levels of Planning Product is composed of Releases Milestone 1 Milestone 2 is Release 1.0 Milestone 3 Strategy Portfolio Product Release Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration Task Time Design X 1 hour Implement X ½ t? day midays m4 Implement Y Co MeetingsC an 1 hour Automate Tests 2 days

Understand Different Levels of Planning Product is composed of Releases Milestone 1 Milestone 2 is Release 1.0 Milestone 3 Strategy Portfolio Product Release Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration Task Time Daily Design X 1 hour Story Active Done Implement X ½ t? day midays OpsUser ... Implement Y Co m4 SysAdmin ... MeetingsC an 1 hour Trader ... Automate Tests 2 days

Understand Different Levels of Planning Product is composed of Releases Milestone 1 Milestone 2 is Release 1.0 Milestone 3 Strategy Portfolio Product Release Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration Task Time Daily Design X 1 hour Story Active Done ½ t? Implement X day midays OpsUser ... ? m4 ues Implement Y an Co SysAdmin ... I ss MeetingsC 1 hour Any Trader ... Automate Tests 2 days

Understand Different Levels of Planning Product is composed of Releases Milestone 1 Milestone 2 is Release 1.0 Milestone 3 Strategy Portfolio Product Release Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration Task Time Daily Design X 1 hour Story Active Done ½ t? Implement X day midays OpsUser ... ? m4 ues Implement Y an Co SysAdmin ... I ss MeetingsC 1 hour Any Trader ... Automate Tests 2 days The Planning Onion shows how the different levels of planning are layered

Understand Estimating● People generally give poor 160 % estimates for how long they think something will take 100 %● The larger or further away Knowledge, Iterations Observed something is the less 60 % accurate the estimation● However people generally are consistent with their poor estimates ● They get their estimates consistently wrong● If we decouple the estimation from the representation of the time the estimate means, we can have quite accurate estimates

Splitting Stories as an Example Large StoryNot Well Understood

Splitting Stories as an Example Large Story Split Large Story toNot Well Understood Smaller Stories

Splitting Stories as an Example ? Large Story Split Large Story toNot Well Understood Smaller Stories

Splitting Stories as an Example ?Rescoping Improves Understanding Large Story Split Large Story toNot Well Understood Smaller Stories

Splitting Stories as an Example ?Rescoping Improves Understanding Large Story Split Large Story toNot Well Understood Smaller Stories Refinement Improves Understanding

Smaller Stories means Better Estimates● It has been shown that in general people are better at estimating smaller things ● A single 100 sized story will take longer than a number of smaller stories with the same total size ● The cone of uncertainty supports this● However when splitting beware of creating gaps in story coverage● Splitting can also help clarify scope ● The total size may increase after splitting but the size needed to be accomplished within the same milestone is often less – only some of the stories are needed now

Smaller Stories means Better Estimates● It has been shown that in general people are better at estimating smaller things For U A single 100 sized story will take longer than a number of Fostories with the same total size ● smaller r User se r Stor Stor Must uncertaintyiies Musofk The cone t kn es to b ● now w ow wh to be supports this e usef● However when splitting n the ofusefull we he n t e beware creating gaps in hey ar u we story coverage y are D e DON ONEE● Splitting can also help clarify scope ● The total size may increase after splitting but the size needed to be accomplished within the same milestone is often less – only some of the stories are needed now

The Discipline of DONE● Learn how to articulate when a Story is DONE● This is more than just saying “Im finished”● Assumes detailing the precise scope of what has been, or was supposed to be, achieved● Means learning to go from the easy 80% finished to cover that elusive last 20%● Ensures that we are truly, incrementally, delivering value● Implies knowing when to defer scope for later

The Discipline of DONE● Learn how to articulate when a Story is DONE● This is more than just saying “Im finished” Assumes detailingnthetatement t o profciiselly e se y o precwhat● S tement t tprecise scope lletiion S a pwasosupposed totbe,yachieved om p et a C oor hasse a C Us e m DONE o r y D O NE akes a S tor been, U m akes a S ate whatgo from the n pllanniing e what m Meansdlearning to of iiteratiioeasy nn ng iin diic at n c● at on p a 80% art of ter last 20% finished hiiscover rt elusive T h s iis p a that Tto s p● Ensures that we are truly, incrementally, delivering value● Implies knowing when to defer scope for later

So Where Are We?● We have Relatively Sized User Stories ● Both Functional and Non-Functional● We have Time-Boxed Iterations ● In which we deliver User Stories● We have prioritised Milestones ● Which are groups of User Stories● We can identify what a Release will be ● Either the result of an Iteration or a Milestone● We know how we can plan at different levels and that estimates can be relative and decoupled from time

So Where Are We?● We have Relatively Sized User Stories ● Both Functional and Non-Functional● We have Time-Boxed Iterations ther...... toge ther allll toge ● In which we deliver User Stories th s a We have prioritised ullll thiis me to p u Tiime to p Milestones● T ● Which are groups of User Stories● We can identify what a Release will be ● Either the result of an Iteration or a Milestone● We know how we can plan at different levels and that estimates can be relative and decoupled from time

Consistently Inaccurate Historical Data can be a very good Estimator● This is because there are many feedback loops at play in Agile Development● Ensuring that observed data based on decoupled estimates can oscillate towards accurate estimates● The key is to consistently make similar estimates and allow the completion rate to compensate for inaccuracy● Use the principles of the cone of uncertainty to provide Date Range Estimates for future dates

Consistently Inaccurate Historical Data can be a very good Estimator● This is because there are many feedback loops at play in Agile Development● Ensuringethat observed data based on L ets llook L ts ook ag aga cant plan decoupled estimatesiin at oscillate towards a n a planni diifferent d fferent le ning at ng a t lev e s thi t accurate estimates ells,, this v attentiion s tiime payin me p a y i g atttonconsistently make similarnestimates The key is e t on to fe to feedback g edback lloop● and allow the completion rate to oops s compensate for inaccuracy● Use the principles of the cone of uncertainty to provide Date Range Estimates for future dates

Planning and Feedback

Planning and Feedback Identify Identify Milestones Milestones Release Planning provides the long term strategic and product view Issues Issues POs User Stories Issues POs POs Release Planning User Story User Story M1 M2 M3 GA Mn User Story Identify Identify Prioritise Prioritise ReleasesReleases Milestones Milestones

Planning and Feedback Identify Identify Milestones Milestones Release Planning provides the long term strategic and product view Issues Issues POs User Stories Issues POs POs Release Planning User Story User Story M1 M2 M3 GA Mn User Story Identify Identify Prioritise Prioritise ReleasesReleases Milestones Milestones Candidate Candidate Iteration Planning provides Stories Stories prioritised short term view User Stories Iteration Expand Expand Estimate if Estimate if Stories Stories can commit can commit

Planning and Feedback Identify Identify Milestones Milestones Release Planning provides the long term strategic and product view Issues Issues POs User Stories Issues POs POs Release Planning User Story User Story M1 M2 M3 GA Mn User Story Identify Identify Prioritise Prioritise ReleasesReleases Milestones Milestones Candidate Candidate Iteration Planning provides Stories Stories prioritised short term view User Stories Iteration Expand Expand Estimate if Estimate if Stories Stories can commit can commit Doc Doc Accept Accept Task List Code Code Daily Use Test Cases Cases Test Refactor Refactor Test Design Design

Planning and Feedback Identify Identify Milestones Milestones Release Planning provides the long term strategic and product view Issues Issues POs User Stories Issues POs POs Release Planning User Story User Story M1 M2 M3 GA Mn User Story Identify Identify Prioritise Prioritise ReleasesReleases Milestones Milestones Candidate Candidate Iteration Planning provides Stories Stories prioritised short term view User Stories Iteration Iteration Iteration Expand Expand content affects content affects Estimate if Estimate if Stories Stories release times release times can commit can commit Doc Doc Accept Accept Task List Code Code Daily Use Test Cases Cases Test Refactor Refactor Test Design Design

Planning and Feedback Identify Identify Milestones Milestones Release Planning provides the long term strategic and product view Issues Issues POs User Stories Issues POs POs Release Planning User Story User Story M1 M2 M3 GA Mn User Story Identify Identify Prioritise Prioritise ReleasesReleases Milestones Milestones Candidate Candidate Iteration Planning provides Stories Stories prioritised short term view User Stories Iteration Iteration Iteration Expand Expand content affects content affects Estimate if Estimate if Stories Stories release times release times can commit can commit Doc Doc Accept Accept Task List Code Code Daily Use Test DONE Stories DONE Stories Cases Cases move towards move towards Test Refactor Refactor releases releases Test Design Design

Planning and Feedback Identify Identify Milestones Milestones Release Planning provides the long term strategic and product view Issues Issues POs User Stories Issues POs POs Release Planning elliivery D e very User Story User Story M1 M2 M3 GA Mn User Story Story D t St o r y llook a t Identify Identify Prioritise s ook a Prioritise payiing p ay n gReleasesReleases Milestones Candidate et s Milestones Candidate llet Iteration Planning provides N ow Now e m or e iim e more k Stories Stories prioritised short term view ,, thiis t m iin th s t edbac k aga n aga Fe edbac Iteration iion to Fe User Stories nt on to Iteration Expand atte nt Iteration Expand a tte content affects content affects Estimate if Estimate if Stories Stories release times release times can commit can commit Doc Doc Accept Accept Task List Code Code Daily Use Test DONE Stories DONE Stories Cases Cases move towards move towards Test Refactor Refactor releases releases Test Design Design

Story Delivery and Feedback

Story Delivery and Feedback Stories Added Stories Added Initial Idea to Iteration to Iteration As Iterations are Roadmap Roadmap completed and stories Stories DONEStories Captured Stories Captured Stories DONE Content Content DONE we better in Iteration& Relatively Sized& Relatively Sized understand our in Iteration Updated Updated product Roadmap Roadmap Dates Dates Updated Updated

Story Delivery and Feedback Stories Added Stories Added Better at Initial Idea Stories may need to Iteration to Iteration estimating to be split or what we can scope refined commit to As Iterations are Roadmap Roadmap completed and stories Stories DONEStories Captured Stories Captured Stories DONE Content Content DONE we better in Iteration& Relatively Sized& Relatively Sized understand our in Iteration Updated Updated product As Roadmap Roadmap Roadmap content changes dates are Dates Dates updated Updated Updated

Story Delivery and Feedback Stories Added Stories Added Better at Initial Idea Stories may need to Iteration to Iteration estimating to be split or what we can Iteration scope refined commit to produces working software As Iterations are Roadmap Roadmap completed and stories Stories DONE UsefulStories Captured Stories Captured Stories DONE Useful Content Content DONE we better in Iteration Software& Relatively Sized& Relatively Sized understand our in Iteration Software Updated Updated product Working software As Roadmap Roadmap Roadmap provides feedback content changes dates are Dates Dates on what is required updated Updated Updated

Story Delivery and Feedback Stories Added Stories Added Better at Initial Idea Stories may need to Iteration to Iteration estimating to be split or what we can Iteration scope refined commit to produces Allll we nee working A we need software Roadmap d to do now i Stories DONE t o d o n ow s As Iterations areStories Captured s Stories Captured om Roadmap some reall da e rea data a Content Content captu re is in Iteration re c a p tu completed and stories Stories DONE DONE we better Useful Useful& Relatively Sized& Relatively Sized Updated ta and iinterin Iteration nd nterpret understand our Software Software pret iit Updated iin a meani t product n a meaningf ngfull way u way Working software As Roadmap Roadmap Roadmap provides feedback content changes dates are Dates Dates on what is required updated Updated Updated

Observe the Progress of Each Iteration● How many points are completed each iteration?● On average how many points are usually completed in an iteration?● Good estimate of what we are likely to complete in future iterations● At the very beginning of a project the completion rate is generally less● Completion rate typically increases throughout a project eventually plateauing at about 60%

Observe the Progress of Each Iteration● How many points are completed each iteration?● On average how many points are usually completed in an iteration? rude but c rude but at e s a c Rate iis are likely to r on R we a Complle tiio what rate iindiicato r Good estimatetof n Comp e nd c at o● complete in risiinglly accu rate future y accu ng iterations surp ris su rp tiimates e es t mates te-a ang e esthe At the very eriiviing da te-r ang beginning of r project for dd er v n g d a● for rate is generally less completion● Completion rate typically increases throughout a project eventually plateauing at about 60%

Date Ranges From Historical Data Gradient based on Completion Rate Weeks “x Points per Iteration with Maximum Iteration Period of y Weeks” Estimated Time Minimum Estimated Time Estimated Completion Date Range W1 to W2Translated to real dates. Story Points

Date Ranges From Historical Data Gradient based on Completion Rate Weeks “x Points per Iteration with Maximum Iteration Period of y Weeks” Estimated Time Date-Ran Date-Range ges are a ve s are a very to encaps to encapsul ry powerful powerful wa ulate riisk in a te r s k i a way y Time Minimum n a form su Estimated form suiitab for strat for strateg tablle e Estimated egiic pllannin c p anning Completion Date Range W1 to W2 gTranslated to real dates. Story Points

Dont Forget: Iteration Length and Feedback

Dont Forget: Iteration Length and Feedback viide o v de ns p r o o n s pr ratiio ck t e ra t er I te eedba ck rt er I F eedba ho rt S ho S Fa F ster F a ster

Use a Tool to help Track Progress● User Stories are like tickets in an Issue Tracking System● Some tools are adapted for Agile Development like agile-trac (http://www.agile-trac.org)● At a minimum keep a record of the sizes of all Stories completed in an iteration● Records of completed iterations provide raw data to estimate future iterations● Tools can automate all of this for you

Good Tools Require Minimal Effort● Some things have to be done by a human● For everything else expect your tool to automate it● For example: ● You must enter User Stories ● You must say which Milestone they belong to and which Iteration they appear in ● You must say when they are DONE ● The tool should be able to use all that information to update the Roadmap, expected Completion Dates, allow Release Notes to be derived and so on

A Quick Lk at agile-tracRelatively SizedRelatively Sized User Stories User Stories

A Quick Lk at agile-tracRelatively SizedRelatively Sized User Stories User Stories Time-boxed Time-boxed Iterations Iterations

A Quick Lk at agile-trac Summary Summary View with predicted View with predicted Completion dates Completion datesRelatively SizedRelatively Sized User Stories User Stories Time-boxed Time-boxed Iterations Iterations Virtual Story- Virtual Story- Board Board

Strategic View is the Roadmap is the Release Plan The progress bar The progress bar represents the represents the relative size of each relative size of each Milestone MilestoneMilestones areMilestones are arranged in arranged inpriority order priority order This provides a fast This provides a fast Uncompleted Uncompleted visual comparison of the visual comparison of the Milestones have an Milestones have an relative complexity of relative complexity of Expected Completion Expected Completion each Milestone each Milestone Date Range Date Range Earliest Expected Earliest Expected Date Date Latest Expected Latest Expected Date Date

Milestones are Composed of Stories Completion Stages Completion Stages capture a Storys capture a Storys Completion Pipeline Completion Pipeline Iterations that a Iterations that a Story was added to Story was added to

Iteration pages are Live Plans Summary View Summary View Default wiki pages Default wiki pages shows current and shows current and associated with associated with future iterations future iterations the iteration the iteration An indication of An indication of when the iteration when the iteration will end will end Overview of the Overview of the iterations iterations progress progress Storyboard view Storyboard view of the current of the current iteration iteration Story DONE Story DONE status. Either status. Either Done or Not Done Done or Not Done

Iteration History is Maintained The number of The number of points previously points previously completed in an completed in an iteration iteration

Questions?Sttartted buttS ar ed b uNOT doneNOT done

Basic Principles of SCM● There are two sides to tool support ● One is to manage the project life-cycle ● One is to manage the artefacts produced during the life-cycle● The two are highly coupled● You should adopt tools that mirror and exploit this coupling● Weve briefly looked at the life-cycle tools – now well briefly look at the artefact tools

Use a Source Code Repository● Chose from one of Subversion, Mecurial or Git● Subversion is a Centralised Concurrent Copy-Modify-Write Model● Mecurial and Git support a Distributed Concurrent Clone-Modify-Push Model● Subversion has the best tool support and will meet nearly all your needs● Mecurial and Git are fast becoming the main alternatives to Subversion – a good string to your bow

Use a Source Code Repository● Chose from one of Subversion, Mecurial or Git● Subversion is a Centralised Concurrent Copy-Modify-Write Model support ndersta Mecurial and Gitme to undDistributednd code ersta nd code to u a Take tiime● Concurrent e t TakClone-Modify-Pushposiitory r e p os t or y ent iin a re age m e n t n a man agem Model ma n● Subversion has the best tool support and will meet nearly all your needs● Mecurial and Git are fast becoming the main alternatives to Subversion – a good string to your bow

Basic Source Control Etiquette● Only commit code that builds ● Breaking the Build means that the integrity of the code- base can no longer be verified ● Regression tests cannot be executed ● Integration with non-breaking code cannot happen● Commit early and commit often ● Ensures that integration happens early when problems are smaller● Always reference a User Story in your Commit Comment● Try to limit commits to changes for Single Stories

Basic Source Control Etiquette● Only commit code that builds ● Breaking the Build means that the integrity of the code- base can no longer be verified Earlly E ar y an ● and Oft d Often Regression tests cannot be executed Imme encodean non-breaking me ans a happen me cannot I Integration withmm ediiate s allmos most d a te f e ● fee db Commit early and commit often dbace ack t k● ● Ensures that integration happens early when problems are smaller● Always reference a User Story in your Commit Comment● Try to limit commits to changes for Single Stories

Branch Only When Essential● Branching is cheap but merging is expensive● Branch only for ● Major changes between releases ● High risk or invasive changes that will break the build ● Making fixes to an already released code-base ● To allow breaking changes to be committed without affecting other developers (usually in a short time)● Tag often to provide markers for building against, or branching from, should the need arise● Prefer a freeze-then-release model to minimise branching

Branch Only When Essential● Branching is cheap but merging is expensive● Branch only for athe iinst Major changes between releases t aga buildt c t g a ns ● High risk or invasive changes thatrote c e yto p will e o p rotbreak sollellyreleased code-baseidea g already t ● Making fixeshiin g so Branc h a nc to n b a d i d ea s iis a bad Br breaking changes subes s a an n iis toue committed without affecting ● iio n ss e tegrat o in a short time) In tegrat ● To allow In other developers (usually● Tag often to provide markers for building against, or branching from, should the need arise● Prefer a freeze-then-release model to minimise branching

Test Your Code● If possible do Test Driven Development ● Tool support can help here ● At a minimum ensure that all core components are tested● Ensure all components are testable ● Promotes looser coupling between components● Maintain all your tests as part of your code base so that they can be executed at any time ● Execute tests as part of your build● Use a unit test framework for the language you are working in

Test Your Code● If possible do Test Driven Development ● Tool support can help here TDD TDD At a minimum ensure that all core components are tested iis allll a s a abo ● q ck an Ensure alluiic bou are testable qucomponents t llearni ut e a k and va rning fr● ng from d valluabetween components om u b e fe Promotes looser couplingablle feedba ● edback c code base● Maintain all your tests as part of your k so that they can be executed at any time ● Execute tests as part of your build● Use a unit test framework for the language you are working in

Remember to Refactor!● You rarely, if ever, get things right the first time● Not refactoring is essentially discarding feedback● A common problem with TDD is that naïve practitioners omit the refactoring phase● You want good code that passes tests, not any code that passes tests

Support Automated Building● Automated builds rely on tools like Ant, Make and Scons● For your language and platform identify and learn an appropriate tool● If in doubt Scons works well both for Java and C++ and uses Python● Ensure all build files (and scripts) are checked in as part of your source code

Automate Everything that you can● Automate the execution of your builds● Automate the execution of your tests● Learn one scripting language like Python to help you with your automation● The Scons + Python combination is very powerful as it minimises what you have to learn● If possible move towards a Continuous Integration model● Understand that automation also costs time

Automation is at the heart of Agile● Automation is one of the key enablers of Agile Development● Automation allows a higher return on your effort and therefore minimises greatly wastage in a project● Automation can provide almost instant feedback on progress allowing you to be more reactive to changes

Got a Prescription for that?Almostt finishedAlmos finished butt bu NOT done NOT done

The real world? A Simple Prescription● Define iterations to be, say 2-3 weeks, starting mid-week● Take 2-3 weeks to Initiate your project (Iteration 0) ● A list of Relatively Sized User Stories ● A Shared Vision with your stakeholders ● An implicit idea of what you need to do and how youll do it ● An Architecture on which to build● Commit to delivering one or more Stories in the First Iteration (Iteration 1) ● Define what it means for the Stories to be DONE ● Make some notes on how you can verify each Story is DONE ● Include Stories that cover automation and development environment setup

Continue to Iterate● Remember youll have a lot of setup work to do in early iterations as you learn and adopt new tools● Focus on making sure you deliver some key functionality each iteration● As time passes youll be able to deliver more as you gain familiarity with your problem domain and your software matures● Make sure you always perform an evaluation of your iteration so that you have the opportunity to learn and adapt● Continually update the roadmap and split large stories into smaller stories are you learn more● Limit the size of stories in iterations and imminent milestones

And remember!● You should know the Agile Values and Principles● Know why you want to do Agile Development● Understand how an Agile Methodology helps● Understand that Agile is team focused● Understand that past progress is used to predict future progress● Minimise waste – minimise time spent on work possibly not required● Observe and learn from Feedback at all planning levels

What about those birds?

What about those birds? Rulles,, ack Ru es eedb ack lle F eedb Siimp e F S mp ea r n ed L ea r n ed ed a n d L r v e d an dw he n Obse rv he n Obse werfull p o w er f uw e v er y p o n b e v er y m,, ca n b fro m ca f ro

Questions? DONE DONE ja11sop@agile-trac.orghttp://www.agile-trac.org

http://agileonthebeach.com	81
http://www.agileonthebeach.com	48
http://www.agileonthebeach.co.uk	3
http://cache.historious.net	1

Feedback Loops in Agile Development

by AgileOnTheBeach

Accessibility

Categories

Upload Details

Usage Rights

4 Embeds 133

Statistics

Feedback Loops in Agile Development Presentation Transcript