AGILE PROJECT MANAGEMENT METHODS: SCRUM AND TDD

DR ELKE DUNCKER AND LINDSEY BRODIE

Lecture 18

Learning Outcomes

Understand ScrumUnderstand Test-driven DevelopmentDiscuss some of the challenges that Scrum

and TDD present to organisations

SCRUM

SCRUM History4

Developed by Jeff Sutherland and Ken SchwaberBased on "The New New Product Development

Game" by Hirotaka Takeuchi and Ikujiro Nonaka published in the Harvard Business Review in 1986

First published in 1995 at OOPSLA ’95 (conference)Now used by 75% of agile teams worldwide

(Sutherland 2011)Often in combination with other Agile PM methods

such as pair programming and TDD

SCRUM is

…Lightweight …Easy to understand …Extremely difficult to master

A process framework

SCRUM isEmpirical as opposed to a defined process

Empirical = derived from or guided by experience or experiment s

Normative = how it ought to be done Prince 2 is a collection of best practice, what is the

difference to SCRUM?Focusing on process control to

optimize predictability control risk Never compromise standards of quality

SCRUM Principles

Called ‘pillars’ in SCRUM terminologyTransparency

Significant aspects of the process must be visible to those responsible for the outcome

Inspection frequent inspection of Scrum artifacts and progress

toward a goal to detect undesirable variances. Must not get in the way of work

Adaptation If one or several undesirable variances have been detected

and the resulting product will be undesirable, the process and/or the material being processed have to be adjusted

(Deemer et al. 2010)

SCRUM Team

Product OwnerSCRUM MasterDevelopment Team

Scrum Roles10

Product OwnerOne personOwns product backlogSets the prioritiesSays when things are “done”

Scrum MasterService to team, product owner and

organisationCoaches everybody involved on ScrumFinds the Product OwnerRemoves impediments to team progress

Developers

Development Team

3-9 DevelopersSelf-organizing

No project managerCross-functional

All skills present in the team as a whole Everybody does everything

No special titles – all team members are called developers

Some developers can focus on specialist areas but the responsibility for the work remains with

the whole teamNo sub-teams within the development team

SCRUM Events12

Are time-boxedSprint

Between 1 week and 4 weeks All sprints of a project have the same duration

Sprint Planning Meeting Between 2 and 8 hours 2 hours for each week of the sprint First half: What’ will be delivered? Second half: How will it be achieved?

Daily Scrum 15 minutes at the start of each working day

Sprint Review 4 hours At the end of the sprint Evaluating the prototype

Sprint Retrospective 3 hours Evaluating the team

(Sutherland and Schwaber, 2011)

SPRINT

Iteration of 1 to 4 weeks durationDuring the each sprint a product increment is

developed, which has to be ‘Done’

Coding, debugging and testing finished Usable

Usability testing Potentially releasable

Not all end products of a sprint have to be released, but they all have to be fully functional and in good working order

Definition of ‘Done’

Identified by the Product OwnerDefinition must be a shared by the Scrum

teamTypical definition of “done”:

All planned sections of code Written Fully tested (from unit testing to application testing) Documented Turned into a deliverable

No quality shortcuts as that leads to ‘technical debt’ building up future problems and delay (Sutherland and Schwaber 2011)

Sprint Rules

During the Sprint: No changes affecting the Sprint GoalDevelopment Team composition remains

constantQuality goals are not allowed to decreaseScope may be clarified and re-negotiated

between the Product Owner and Development Team as more is learned

(Sutherland and Schwaber 2011)

Scrum Artifacts I

Product Backlog Prioritized functionality for the whole product with

estimated effortSprint Backlog

Set of tasks necessary to implement the functionality selected from the Product Backlog for a sprint

The functionality of the product backlog needs to be broken down into tasks needed to achieve the functionality

The tasks can then be assigned to individuals or pairs of developers

Cancellation of a Sprint

Only the product owner can cancel a sprintWhen is it advisable:

Only, when the sprint goal has become obsolete Mostly due to external events Rare event because of short cycles

What needs to be done Completed tasks have to be reviewed if they are still

releasable Non-releasable tasks have to be put back on the product

backlog and re-estimated Sprint cancellations are consuming resources and

are traumatic to the team and have to be avoided

Sprint Planning Meeting

Team plans the work to be done during the sprint Product owner can be present SCRUM Master should be present Time-boxed

2 hours for each week of a sprint E.g. a four week sprint has an 8 hour planning meeting

Two parts What will be done during this sprint?

Defining the product increment to be delivered at the end of the sprint Product owner presents ordered and relevant items from the product backlog for this sprint Team forecasting product backlog items for this increment

How will the work be achieved? Plan of delivery Work to be cut into daily units Re-negotiation of estimated effort

By the end of the meeting team explains to SCRUM Master what has to be achieved and how they are planning on achieving the planned increment

Daily Scrum

To be held at the same time and place each day Each Developer explains:

What s/he has accomplished since the last meeting? What s/he will do before the next meeting? What obstacles are in the way?

Not a ‘state of the project’ meetingabout work in progress to create the deliverable

(Sutherland and Schwaber 2011)

Sprint Review

Focus on the product increment and the work done Product Owner identifies what has been “Done” and what has

not been “Done” Development Team discusses what went well during the Sprint,

what problems it ran into, and how those problems were solved Development Team demonstrates the work that it has “Done”

and answers questions about the Increment Product Owner discusses the Product Backlog as it stands. He or

she projects likely completion dates based on progress to date The entire group collaborates on what to do next, so that the

Sprint Review provides valuable input to subsequent Sprint Planning Meetings

(Sutherland and Schwaber 2011)

Sprint Retrospective

Focus on the teamInspect how the last Sprint went with regards

to people, relationships, process, and toolsIdentify and order the major items that went

well and potential improvementsCreate a plan for implementing improvements

to the way the Scrum Team does its work

(Sutherland and Schwaber 2011)

(Deemer et al. 2010)

Scrum Artifacts II

Release Burndown Implemented functionality against total functionality

estimated in points Must be based on previous performance

Sprint Burndown Implemented functionality against functionality to be

implemented during a sprint Also based on previous performance

Benefits

Scrum delivers in time and in budgetScrum aims at delivering high quality

softwareScrum reduces the risk to IT development

projectsScrum is very agileScrum puts the customer value at the centre

of the project

Drawbacks

In practice, the time boxing of sprints leads to a neglect of system and application test cases Reduces the quality Increases risks that emerge when the software goes

life

Questions?

Test-Driven Development

Test-Driven Development

A concept originally known as part of Extreme Programming

Has become successful independently from XP

Re-discoverery is attributed to Kent Beck (XP creator)

Basic Concepts of TDD

Extremely short development cyclesFirst, the developer writes an initially failing automated

test The test case for the automated test defines the desired outcomes of

the function to be added or improvement to be made The developer has to make sure the test fails initially

Then the developer writes the minimal amount of code that is necessary to pass the test

He also runs all previous test to make sure his software still passes those

Then the developer refactors the code, i.e. removes duplications and do other things so that the code adheres to accepted standards

Principles of TDD

Two basic principles: Never write a single line of code unless you have a

failing automated test Eliminate duplication

Other “principles”: “Fake it till you make it” (writing the code that passes

the test) “KISS” – Keep it simple, stupid! “YAGNI” – You aren’t gonna need it

Variations and Expansions

ATDD = acceptance-test driven development Communication tool between customer/user, developer and

tester to ensure well-defined and testable requirements Differences to TDD:

Test automation not required in ADTT, but required in TDD Test cases in TDD can be derived from ADTT, but not the other

way round Test cases in ADTT have to be comprehensible for customers, TDD

test cases only have to be comprehensible for developers and testers

If automated testing is used, the developer writes one test case Also called BDD=Behaviour-driven development

Aim: Detailed, executable requirements on a just-in-time basis

Links between BDD and TDD

(Re-)write Acceptance test case

Does the acc. test fail?

Hand over to TDD with a change suggestion

Does the acc. test fail?

Full TDD cycle

yes

no

Run acc test

Run acc test

no

yes

Developm. complete?

yes

no

Benefits and Drawbacks of TDD

Benefits: Increased productivity Less debugging required Very quickly functioning code

The correlation with software quality is not quite as straightforward Unit testing and integration testing: very good System and application testing: less good Functional requirements testing: very good Non-function requirements testing: less good

Questions?

Organisational Challenges of Scrum and TDD

Increases transparency Not everyone is in favour of transparency

Some people like to use information as power base Some staff members may not want to share their

timesheets or productivity logs

Can reveal organisational problems That some organisations don’t want to fix Can lead to people starting to customise Scrum instead

of fixing the organizational weaknesses e.g. not adapting the organizational structure to support

Scrum teams

Organisational challenges of Scrum and TDD

Requires training effort to get cross-functional teamsRequires training effort to get TDD goingRequires letting-go and trusting the teamsTransition from management to leadershipNeed to act to remove the impediments in order to

increase the velocityCustomer company and developer company have to

agree with the use of agile methodsCustomer Company may not want to be involved in

development process

Scaling Scrum and TDD

What about large projects?SAP and other organisations are using Scrum

for large projectsScrum of ScrumsTDD for complex systems:

Use of test cases even more beneficial Potentially counteracted by an increasingly complex

test case system Maintenance of test software becomes an issue of its

own

© Scott Ambler + Associates

Criteria for a Disciplined Agile Team

Businessvalue

Produce a working solution on a regular basis which provides quantifiable value to stakeholders

Validation Do continuous regression testing, and better yet take a Test-Driven Development (TDD) approach

Stakeholder Collaboration

Work closely with their stakeholders, or a stakeholder proxy, ideally on a daily basis

Self organization

Are self-organizing and work within an appropriate governance framework

Improvement

Regularly reflect on, and measure, how they work together and then act to improve on their findings in a timely manner

39

© Scott Ambler + Associates

Criteria for a Disciplined Agile Team

Teams Claiming to be Agile

Teams Moving to Agile

Businessvalue

91% 83%

Validation 88% 69%

Collaboration

99% 94%

Self organization

72% 51%

Improvement

92% 90%

All Criteria 65% 39%

40

Summary

Scrum Principles: Transparency, Inspection and Adaptation Teams: Scrum Team including product owner, Scrum Master and

development team Events: Sprints, sprint planning meeting, daily scrum, sprint review

and sprint retrospective Artefacts: Product backlog, sprint backlog, release burn down, sprint

burn down High productivity, low risk, questionable quality

TDD Principles: very small iterative steps; write test case first then write

code to satisfy the test case; refactoring ATDD or BDD: include user acceptance testing and improve

requirements spec High productivity, bug free code but quality still not 100%.

Next Week

Extreme Project managementLean project management

Reference

The slides of this slideshow are based on SCRUM:

Schwaber, K. and J. Sutherland. 2011. “The SCRUM Guide”, available at http://www.SCRUM.org accessed 28/5/2013

TDD: Beck, K. Test-Driven Development by Example, Addison

Wesley - Vaseem, 2003 Scott W. Ambler, Introduction to Test-driven Development at

http://www.agiledata.org/essays/tdd.html , accessed 2nd of June 2014

The statistics about the agility of disciplined development teams are taken from www.ScottAmbler.com

References44

Agile Manifesto. Available from: http://agilemanifesto.org/ [Accessed 1 November 2009].

Deemer, P., Benefield, G., Larman, C. and Vodde, B. (2010) The Scrum Primer [online]. Available from: http://www.scrumprimer.com/ [Accessed 23 May 2012].

Larman, C. (2004) Agile and iterative Development: A Manager’s Guide. Addison-Wesley. ISBN 0131111558.

Østergaard, J. (2009) Why is Scrum so Hard? [online]. Available from: http://www.youtube.com/watch?v=q3t8twm3aUk&feature=related [Accessed 23 May 2012].

Sutherland, J. and Schwaber, K. (2011) Scrum Guide [online]. Available from: http://www.scrum.org [Accessed 1 November 2009].

Sutherland, J. (2011) Takeuchi and Nonaka: The Roots of Scrum [online]. Available from: http://scrum.jeffsutherland.com/2011/10/takeuchi-and-nonaka-roots-of-scrum.html [Accessed 23 May 2012].

Further Agile Reading/Viewing45

Larman, C. & Basili, V. (2003), Iterative and Incremental Development: A Brief History, IEEE Computer, June 2003, pp 2-11. See http://www.craiglarman.com for a copy of this paper. Or via ‘Further Reading’ on Wikipedia information on ‘Agile Software Development’

Fowler, M. (2005) The New Methodology [online]. Available from: http://martinfowler.com/articles/newMethodology.html#XpextremeProgramming [Accessed 1 November 2009].

Gilb, T. http://www.Gilb.com under ‘Downloads’ then under ‘Gilb Papers’ Decomposition April 4 2008.pdf: Decomposition of Projects - How to design small incremental result steps CAI tomgilbinterview1.pdf: What are Evolutionary (EVO) Development Methods? CAI Interview on 21

February 2006 Evo Principles.pdf: Fundamental Principles of Evolutionary Project Management

Abrahamsson, P., Salo, O., Ronkainen, J. and Warsta, J. (2002), Agile Software Development Methods. Review and Analysis, VTT Publications, Espoo, Finland, ISBN 9513860094. http://www.inf.vtt.fi/pdf/

Schwaber Scrum Video http://video.google.com/videoplay?docid=-7230144396191025011&q=Google+Tech+Talks&hl=en#(61 minutes)