Download - AGILE PROJECT MANAGEMENT METHODS: SCRUM AND TDD DR ELKE DUNCKER AND LINDSEY BRODIE Lecture 18
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)