agile software developmentagile processes promote sustainable development at a constant pace •...
TRANSCRIPT
Agile Software Development
T-110.6130 Systems Engineering in Data T 110.6130 Systems Engineering in Data Communications Software
24.9.2010
Kristian Rautiainen, Aalto University, y
AgendaAgenda
A il S ft D l t B i• Agile Software Development Basics• eXtreme Programming (XP)
S• Scrum• 10 Ways to Fail when Going Agile
24.9.2010Kristian Rautiainen
2
Agile Software Development BasicsAgile Software Development Basics
24.9.2010Kristian Rautiainen
3
Agile software developmentAgile software development
• Structured and disciplined fast-paced Iterative and Incremental• Structured and disciplined, fast-paced Iterative and Incremental Development (IID)
– NOT “build-and-fix” or “hack away”• Packages existing good software engineering practicesPackages existing good software engineering practices
– Nothing new, except the underlying philosophy and the combination of practices• Embraces change rather than controls it
– Suitable for extremely turbulent environments– Suitable for extremely turbulent environments• Focuses on delivering business value in frequent increments
– Customer/User involvement paramountCan’t be used in all projects!• Can’t be used in all projects!
– E.g. small teams recommended• More information:
htt // il lli /– http://www.agilealliance.org/
24.9.2010Kristian Rautiainen
4
Agile ManifestoAgile Manifesto
• Signed by authors of ASD, XP, Scrum, Crystal, FDD, DSDM, and ”pragmaticSigned by authors of ASD, XP, Scrum, Crystal, FDD, DSDM, and pragmatic programming” + some others in Feb 2001
• Agree at the first levelneed to respond to change– need to respond to change
• Agree at the second level (Agile Manifesto)– individuals and interactions over processes and tools– working software over comprehensive documentation– customer collaboration over contract negotiation– responding to change over following a plan
• Agree at the third level– 12 more detailed statements (Principles)
• Don’t agree at the fourth level• Don t agree at the fourth level– detailed project tactics
24.9.2010Kristian Rautiainen
5
Principles of the Agile AlliancePrinciples of the Agile Alliance
• Satisfy the customer through early and • The most efficient and effective way of continuous delivery of valuable software
• Agile processes harness change for the customer’s competitive advantageD li ki ft f tl
yconveying information is face-to-face conversation
• Attention to technical excellence and • Deliver working software frequently• Working software is the primary
measure of progress• Agile processes promote sustainable
good design enhances agility• Simplicity--the art of maximizing the
amount of work NOT done--is essential• Agile processes promote sustainable
development at a constant pace• Business people and developers must
work together daily
• The best architectures, requirements, and designs emerge from self-organizing teamsAt l i t l th t t d• Build projects around motivated
individuals, give them support and trust them to get the job done
• At regular intervals the team tunes and adjusts its behavior to become more effective
624.9.2010Kristian Rautiainen
Agile process modelsAgile process models
• Provide the “project tactics”Provide the project tactics– A set of specific values, principles, and practices
• Many models have been proposed• Many models have been proposed– eXtreme Programming (XP)– Adaptive Software Development (ASD)– Rapid Application Development (RAD)p pp p ( )– Dynamic Solution Delivery Model (DSDM)– Scrum– Crystal
F t D i D l t (FDD)– Feature-Driven Development (FDD)– Lean Development (LD)– ...
• Most agile process models employ time pacing
24.9.2010Kristian Rautiainen
7
The concept of time pacingThe concept of time pacing
• Time pacing refers to• Time pacing refers to– Creating a rhythm for product development by timeboxing
development workTh h d l i fi d• The schedule is fixed
• The scope is flexible (prioritization needed)
• Time pacing can be done on several time horizons– Time horizon = planning time horizon, i.e. the length of the timebox– Long-term goals are split into short-term sub goals– Long-term goals are split into short-term sub goals– This provides
• visible progress on shorter time horizons by reaching the sub goals• flexibility to reflect on and change plans and goals in the control points• flexibility to reflect on and change plans and goals in the control points
based on visible and concrete progress
24.9.2010Kristian Rautiainen
8
Agile philosophy and time horizonsEvery idea, feature, bug, etc. Roles:
P d t B kl
considered for the product is kept inRoles:
1 Product Owner1 Team1 Coach
Product Backlog
planned scope for release allocated intoce us
Release Backlog Release Backlogover
nanc
ress
sta
t
IterationBacklog
IterationBacklog
IterationBacklog
parts chosen and allocated intoGo
Pro
g
Progress of a Releasechecked in Iteration Demo
consists of tasks that are needed toimplement the allocated backlog items
Progress status of the tasksof an Iteration checked inDaily Heartbeat meetings
24.9.2010Kristian Rautiainen
9
Sweet spots of agile softwareSweet spots of agile software development
3 8 l i• 3-8 people in one room– Information moves the fastest face-to-face
O it t• Onsite expert user– Minimized time for feedback of the solution– Possibility to ask questions immediately fastest response time
• One-month (max) iterations– Feedback of the product and the process– Today’s “industry standard” is 2-week iterationsToday s industry standard is 2 week iterations
• Supporting infrastructure/technology in place– Continuous Integration environment with automatic build processContinuous Integration environment with automatic build process– Fully automated regression tests
• Confidence to changing and improving the system
24.9.2010Kristian Rautiainen
10
Comparing process modelsComparing process models
Specification
Design
Tim
e
Implementation
T
Test
S ti l It ti & XtSequential Iterative & Incremental (IID)
eXtreme Programming (XP)
24.9.2010Kristian Rautiainen
11
eXtreme Programming (XP)eXtreme Programming (XP)
(Based on the original book by Kent(Based on the original book by Kent Beck)
24.9.2010Kristian Rautiainen
12
XP Values (1/2)XP Values (1/2)
• Communication • Simplicity• Communication– Lack of it is the reason for most
problemsPunishment from bad news kills it
• Simplicity– What is the simplest thing that
could possibly work?General vs simple design– Punishment from bad news kills it
– XP employs practices that keep programmers, customers and managers communicating
– General vs. simple design• anticipatory design assumes
more work today saves work latera age s co u ca g a e
– YAGNI • low rate of changes
– anticipatory designp y g• high rate of changes
– refactoring and continuous designg
– A simple solution is easier to understand
24.9.2010Kristian Rautiainen
13
XP Values (2/2)XP Values (2/2)
• Feedback• Feedback– Concrete feedback about the state
of the systemScale of minutes or days– Scale of minutes or days
• unit tests, quality of stories (requirements), progress of tasksas s
– Scale of weeks or months• acceptance tests, schedule,
system in productiony p
• Courage– Changing the system– Throwing code away– Throwing code away– Pair programming
24.9.2010Kristian Rautiainen
14
XP PrinciplesXP Principles
• Fundamental principles Secondary principles• Fundamental principles– rapid feedback
• critical for learning– assume simplicity
• Secondary principles– teach learning– small initial investment
assume simplicity• treat every problem as if it can
be solved with simplicity– incremental change
– play to win– concrete experiments– open, honest communication
• series of smallest changes that make a difference
– embracing changebest strategy preserves most
– work with people’s instincts, not against them
– accepted responsibility• best strategy preserves most
options while actually solving your most pressing problem
– quality work
– local adaptation – travel light– honest measurement
• excellent quality• nobody likes doing a bad job
24.9.2010Kristian Rautiainen
15
XP PracticesXP Practices
• Practices• Practices– planning game– small releases– test driven development– continuous integration – system metaphor– simple design– refactoring– pair programming– collective code ownership– coding standard – whole team (on-site customer)– sustainable pace
24.9.2010Kristian Rautiainen
16
XP ProcessXP Process
24.9.2010Kristian Rautiainen
17
ScrumScrum
24.9.2010Kristian Rautiainen
18
Scrum Process OverviewScrum Process Overview
24.9.2010Kristian Rautiainen
19
Scrum roles – Product Owner (PO)Scrum roles Product Owner (PO)
• Represents the interests of everyone with a stake in the project/product• Represents the interests of everyone with a stake in the project/product• Creates the project’s ROI objectives and release plans• Manages and controls the Product Backlog (PBL)
E th t th PBL i i ibl t– Ensures that the PBL is visible to everyone– Sets priorities for the items in the PBL– For PO to succeed, everyone must respect his/her decisions
Works with others to estimate items in backlog (for total effort)– Works with others to estimate items in backlog (for total effort)– Participates in Sprint Planning Meeting (and Sprint Review)– Participates in re-scoping or re-prioritizing the sprint
• PBL• PBL– PBL is an evolving, prioritized queue of business and technical functionality that
needs to be developed into a system– PBL emerges from many sourcesg y
• Marketing, Sales, R&D, Support, ...
24.9.2010Kristian Rautiainen
20
Scrum roles – Scrum MasterScrum roles Scrum Master
A il h• Agile coach– Master of the Scrum process and practices– Coaches the team membersCoaches the team members
• Facilitator/impediment removerp– Shields the team from outside interruptions– Helps remove impediments
24.9.2010Kristian Rautiainen
21
Scrum roles – Development teamScrum roles Development team
R ibl f li i th PO’ i i f th d t• Responsible for realizing the PO’s vision for the product– The team makes the technical choices and delivers working
software to demo at the end of Sprintsp• Shared responsibility
S lf i d d d• Self-organized and empowered– The team chooses its ways of working– No appointed team leaders leaders emerge for different– No appointed team leaders, leaders emerge for different
situations
24.9.2010Kristian Rautiainen
22
10 Ways to Fail when going Agile10 Ways to Fail when going Agile
24.9.2010Kristian Rautiainen
23
Ceremony Without UnderstandingCeremony Without Understanding
D i thi b f b t lli it A il• Doing everything as before, but calling it Agile– New terminology, but same routines– E g Weekly meeting => weekly ScrumE.g. Weekly meeting > weekly Scrum...
• ...or Daily Scrum that lasts as long as a weekly meeting
• Fallacy of allowing feature creep during iterations– ”because we’re supposed to be agile”
24.9.201024
Kristian Rautiainen
Underestimating Transition Effort andUnderestimating Transition Effort and Time
O i ti l h i t i• Organisational change or process improvement is always challenging and takes a lot of time– ”This agile thing doesn’t work for us We tried it for a couple ofThis agile thing doesn t work for us. We tried it for a couple of
months, but...”– Fallacy of not risking some time now in order to win a lot of time
i th f tin the future• Transition to Agile slows down productive work for an unknown
period of time– Business representatives tend to be impatient...
24.9.2010Kristian Rautiainen
25
Throwing Away Existing Good PracticesThrowing Away Existing Good Practices
”L t’ t t f t h ith thi A il thi ”• ”Let’s start from scratch with this Agile thing”
”W d t b t li it i t N• ”We used to observe users to elicit requirements. Now we invite them to iteration demos instead”
• ”Something that works for us is not considered Agile. We have to throw it away ”have to throw it away.
24.9.2010Kristian Rautiainen
26
Cultural ConflictsCultural Conflicts
P j t > S M t• Project manager => Scrum Master– You often see this role transition in companies
• But the differences in the roles cause trouble and confusionBut the differences in the roles cause trouble and confusion• (technical) project manager => (technical) product owner is actually
an easier transformation
• Breaking down ”silos”– Creating truly cross-functional teams is a big challenge...Creating truly cross functional teams is a big challenge...
• ...but without them lots of effort for coordination is needed
24.9.2010Kristian Rautiainen
27
Challenging RolesChallenging Roles
P d t O• Product Owner– Need I say more...?
• Empowered, self-organised team– ”Say what?”– Say what?– A transition from a ”clear roles and responsibilities + a project
manager to tell us what to do” to self-organised is rocket science d h t f t land a huge step for most people
• A lot of coaching and support is needed for the role• A lot of coaching and support is needed for the role transitions (also for top-level managers!)
24.9.2010Kristian Rautiainen
28
Lacking CompetenceLacking Competence
G tti id f th diffi lt ti b th t k• Getting rid of the difficult practices because they take too much time to learn– ”Test-Driven Development (TDD) was really hard to understandTest Driven Development (TDD) was really hard to understand
and learn, so we stopped doing it”– You need to understand the trade-offs and underlying
ti th i d i t t l d hassumptions, otherwise you end up in total ad-hocracy
• Working at high velocity requires high discipline and• Working at high velocity requires high discipline and skills + good-quality software– Work on building competence to the people, it will always pay offg p p p y p y
24.9.2010Kristian Rautiainen
29
Minimal Plans = Minimal PlanningMinimal Plans Minimal Planning
F ll f l i l i R l It ti l i• Fallacy of planning only in Release or Iteration planning sessions– ”I just saw the demo Now I need time to figure out what youI just saw the demo. Now I need time to figure out what you
should do next”– Planning should be made ”continuously” in a rolling wave
f hifashion• Requirements refinement (Agile Product Management)*• 5% workshops (aka story time) have not been around in most
companies (not for long, anyhow)
*K. Vlaanderen, S. Jansen, and S. Brinkkemper, “The agile, , p , grequirements refinery: applying scrum principles to softwareproduct management,” in Proc. 3rd International Workshopon Software Product Management, 2009.
24.9.2010Kristian Rautiainen
30
Emerging architecture =Emerging architecture no upfront architectural work• Working in short iterations may compromise the• Working in short iterations may compromise the
architecture– ”The best architectures emerge”
• Sure thing, as long as you have the best people– ”Just enough arcitecture”
• How do you know how much is enough?How do you know how much is enough?– ”We have these 10 teams working on the release of this
product”• ”Architectural runway” is a mustArchitectural runway is a must
• Architectural work is challenging no matter what you call th d l t !the development process!
24.9.2010Kristian Rautiainen
31
Anyone Seen the Onsite Expert User?Anyone Seen the Onsite Expert User?
W ki ith i l b kl l i i ht f• Working with a simple backlog may cause losing sight of the ”Big Picture”– Most backlogs only contain vague one-liners not even properMost backlogs only contain vague one liners, not even proper
user stories– If the onsite expert is not there to explain things, the end result
i ht b l t l ff t tmight be completely off target• The positive thing is that we know it pretty fast, but it is still waste
– How much explanations should be written?p
24.9.2010Kristian Rautiainen
32
Agile Only Concerns R&DAgile Only Concerns R&D
• After all the Product Owner is part of the team and is• After all, the Product Owner is part of the team and is responsible for all ”that other stuff”– Still, agile (and lean especially) does change the way everybody
should be thinking about developing software
Agile requirements ( backlogs stories ) mean that• Agile requirements (= backlogs, stories, ...) mean that Business representatives need to work in new ways too!
• Customers still want detailed plans and contracts!– Business/sales representatives force the teams to produce
detailed plans upfront– Who trains the customers?
24.9.2010Kristian Rautiainen
33
Questions or comments?Questions or comments?
24.9.2010Kristian Rautiainen
34