1. Agile Methods: So What? This talk by Ed Gehringer based on notes by
Roy W. Miller
RoleModel Software, Inc.
How many have heard of agile methods?
How many have tried to use them on a project?
How many are trying to use it now?
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

2. Why Agile Methods? Be more valuable than your peers.
Be more productive.
Make you happier.
How many people have heard about Agile?
How many people have done it?
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

3. The Real Project Lifecycle
Dream
Plan
Capture requirements
Design a lot, code a little, test if there’s time
Limp to the finish
Create a comprehensive plan, stick to it at all costs, kill change, hope you survive
Requirements docs tend to be too detailed.
Customers think they have a narrow window of opportunity to ask for anything.
So it may take 6 mos. to get req’ts. done. Then you spend more x doing design.
“High-level design” – can take months
Death Marches common (Ed Yourdon’s book Death March.)
Chart a course and follow it--Stick to the plan <= deviation is viewed as expensive.
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

4. The Results Junk Late For a lot of money
Data from 2000 CHAOS Report, Standish Group
Junk
Late
For a lot of money
40K projects , 50K projects since 2002
Many people question validity of #s because they claim to do an exhaustive study on 30K projects.
IEEE SW paper: 8380 projects had data, but based on only 365 respondents
In 2012, 74% had time overruns and 59% had cost overruns
>70% of projects don’t measure up
Challenged: Late, over budget, didn’t deliver what they promised.
Not that numbers improved 10% from 2004 to 2012
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

5. “Modern resolution”
Exercise: Look up the controversy over this report, and submit observations here.
See
The rise and fall of the Chaos report figures, IEEE Software, Jan. 2010
Old definition: meets original forecast of functionality.
New definition: achieves a satisfactory result.
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

6. Making software is like a factory – an efficiency optimization problem
The Source: Taylorism
Frederick Winslow Taylor, Principles of Scientific Management (1911)
Accepted wisdom by 1950s
Software began in 1950s
Software “production” ~= industrial production
Exercise: Find an interesting fact about Taylorism. Submit here.
“[I]n each…trade there is always one method and one implement which is quicker and better than any of the rest. And this one best method and best implement can only be discovered or developed through a scientific study and analysis of all of the methods and implements in use, together with accurate, minute, motion and time study. “
Passed Harvard entrance exam, but allegedly due to deteriorating eyesight, became a machine-shop worker in 1880s, ascended to a posn. of mgt.
Worked in steel pn.
1880s – 1910s in lots of industrial settings
Inefficiency everywhere – low efficiency YIELDS low output YIELDS low profits
Rules of thumb--mgrs. would let workers do their own thing.
Soldiering − “work slowdown.” They’ll expect us to produce highly always.
Find “the one best way” – science of work
Workers work, managers think
Detailed task breakdown, follow the steps
Apparently followed people around w/stopwatch.
He created ≈ cards for all workers to follow.
No room for creative genius on an assembly line
To be successful, they had to be “dumb as oxen.”
But software is not like that--we don’t make the same thing every time.
You don’t know how to do it before you start out.
Making software is like a factory – an efficiency optimization problem
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

7. Software Is Different Software is emergent
Exercise: How is software different from other industrial processes? Submit here.
Traditional view…
Reality…
Software like industrial production
Software like predicting the weather
Problem always the same
Solution always the same
Optimize process
Change is disruptive
Increase predictability
Problem always different
Solution always different
Can’t optimize
Change is constant
Can’t predict accurately
Traditional view is LINEAR, reality is NON-LINEAR
Software that’s the same every time is a waste
Requirements change--perhaps hourly.
Unpredictable – deterministic, but non-periodic
Multiple factors
Emergent – feedback from iterations
Different kind of problem, needs different kind of solution
Software is emergent
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

8. Agile creates the right conditions for emergent software
Growing Software
Need a solution that…
Allows us not to know
Allows us to explore
Gives feedback to direct us
Creates the right conditions, lets software emerge
Lets us produce the right software at the END
If we say we know in advance, either we’re delusional or we’re lying.
We need to get feedback often.
Kent Beck: Making sw. is like steering a car.
XP boiled down: What is the simplest thing we can do & still make great software?
Most other processes are after prediction & control, not simplicity.
Discipline vs. agility – you need both (
Look up “The Agile debate.”
Agile creates the right conditions for emergent software
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

9. What is the simplest thing we can do and still make great software?
Agile In a Nutshell
4 core values:
Simplicity, Communication, Feedback, Courage
19 practices
1 team
3 roles: Customer, Manager, Programmer
What is the simplest thing we can do and still make great software?
Values are “why” behind the practices
Simplicity keeps us from getting bogged down in process/code
Communication – problems always start here
everything that I’ve seen go wrong is from so. not talking to so. else at the right time.
Feedback helps us “steer”
Courage keeps us going
It takes guts to tell a manager, You can’t have everything yesterday, but I can give you this ...
Practices: Originally 12, but 19 in four groups seems about right
The extra 7 flesh out the non-technical (business) side of making sw.
Team: Who is the 1 team?
Not just programmers, but the customers, managers.
Everybody in this thing together
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

10. Agile is about more than programming
The Practices
Joint
Common Vocabulary
Iterations
Open Workspace
Retrospectives
Development
Test-First Development
Pair Programming
Refactoring
Collective Ownership
Continuous Integration
Just-In-Time Design
Management
Accepted Responsibility
Air Cover
Quarterly Review
Mirror
Sustainable Pace
Customer
Storytelling
Release Planning
Acceptance Tests
Frequent Releases
Categories are new
We do some things together, some things apart
Creating software is about more than programming
Agile is about more than programming
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

11. Create an environment where “one team” can exist and thrive
Joint Practices
Common Vocabulary
Formerly “metaphor” – shared understanding
Iterations
Steering – frequent, regular checkpoints so we can get lots of concrete feedback
Open Workspace
Easy to communicate and learn
Retrospectives
Being “Reflective Practitioners” (Donald Schon), learn as we go
Exercise: Look up one of these practices (your row number mod 4), and find an interesting fact about it. Submit here.
What we do together to create “one team”
Common vocabulary--originally called “metaphor.”
Metaphor didn’t work – people missed the point
Original XP project was at Chrysler. They named parts of the project after parts of the assembly line.
We’re not just thinking of cute names, but things that people can use to refer to concepts w/the same terminology.
E.g., Letter, open, address book, mailbox.
E.g., surfaces: Window, scroll, canvas, pen, brush, palette, clipboard, menu.
Common vocabulary -- shared understanding.
Iterative development not new.
RoleModel iterations run a week.
Have a planning session on Monday, on Friday, say we’re done.
Focuses programmers on what they should be doing right now.
Forces business people to make decisions. They can’t make programmers figure it out.
Open workspace
Dilbert world--filled w/cubes.
You can’t work like that on a team.
The only way we can communicate at that level is to see each other.
Today’s cubes are getting smaller: 100 sq. ft. 15 yrs. ago, 54 sq. feet now.
You can’t get 2 people behind the same computer in a cube that small.
So move them out of cubes & into studios.
Cockburn: If so. is on another floor, they might as well be on another planet.
With electronic communication, level of granularity is coarser.
Telecommuting—only if you can break project into parts that require little communication.
Retrospective: At end of every iteration, we look at what we did well, badly.
Create an environment where “one team” can exist and thrive
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

12. “Drive” the entire process
Customer Practices
Storytelling
Describe each system feature in a small chunk that fits in an iteration
Release Planning
Tell programmers which features come first
Customer Tests
Also “acceptance tests” or “functional tests” – tell programmers when they’re done
Frequent Releases
Get software to users so the team can get feedback to steer with
Storytelling: Customer has to drive the whole project.
Customers tell us stories, write on index cards.
We make a stack of cards. When we get to this, we’ll come back to you & talk about it.
Customers aren’t used to doing this; they are used to req’ts. docs.
This avoids need to get down to nth level of detail all at once.
Release planning is a step above iteration planning.
Two levels: Iteration planning (weekly), Release planning (a step above that; just asks what features are needed)
Release planning asks, What do we need to get a minimally useful system?
Finally we get to the end of the project when somebody says, “That’s about enough.”
Customers need to do tests.
They aren’t used to testing; they are customers!
But customer has to test to tell us when what we’ve made is good enough.
If system passes this script of tests, then we are done.
We don’t want to do more--or less--than we need to.
Frequent releases
A discipline for customers as well as programmers.
Tendency is not to let anything out the door unless it is “perfect.”
XP says, the only way to find out if we’re getting close is to have customer tell us. Need to put real sw. in hands of real people.
“Release early, release often.”
Customer drives--exactly the reverse of usual.
Choose sensibly: Only whole features should be included in a release.
Exercise: Look up one of these practices (your row number mod 4), and find an interesting fact about it. Submit here.
“Drive” the entire process
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

13. Educate, facilitate, stay out of the way
Management Practices
Accepted Responsibility
Say what needs to be done, let the team decide who does it and how
Quarterly Review
Make sure the team knows what it needs to; make sure management knows what it needs to
Air Cover
Soften up the defenses to make room for the infantry
Sustainable Pace
Help people avoid burnout
Mirror
Point out problems, suggest, advise, encourage
Accepted responsibility
People don’t like to talk about the fact that mgrs. are part of the team.
But they have to be part of the team w/o getting in the way.
Managers don’t dictate (or people leave).
Turnover is one of the biggest contributors to cost in most businesses.
Managers nudge. This needs to be done. You figure out how.
Quarterly review
Mgrs. don’t need to be part of the release-planning sessions as much as customers & programmers.
Job of a mgr. is to educate, facilitate, stay out of the way.
Mgr. needs to know enough to do this.
So maybe mgr. sits in on a release-planning session.
Air cover
Air cover during WW II was to soften things up.
Mgrs. are to say, Team needs to go over here.
Mgr. needs to work way through the organization so team can do that.
Get signoffs for access to environments, getting broken workstns. fixed.
Sustainable pace. Have a life!
Most programmers don’t want to give up on a problem, regardless of how late it is.
If you burn the candle at both ends, sooner or later you’re out of wax.
If you work 15 min. more, I’ll unplug your PC!
When a project gets behind schedule, overtime is often the first response.
Hours start to stretch, then some groups may have mandatory overtime.
This can lead to a “death march” (Yourdon 1999).
Developers’ family life suffers; they may put in hours physically but not mentally.
Keep team running a marathon, not a sprint.
“Yesterday’s weather” rule—the next iteration will accomplish about as many estimated days’ work as the current one did.
Mirror
Mgr. needs to say to team--look at what you’re doing. Is that right?
If they are off track, management can suggest ways to break logjam.
Exercise: Look up one of these practices (your row number mod 5), and find an interesting fact about it. Submit here.
Educate, facilitate, stay out of the way
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

14. Development Practices
Test-First Development
No code without a failing programmer test
Pair Programming
All code gets two pairs of eyes
Refactoring
Remove “smells”
Collective Ownership
Everyone owns all of the code
Continuous Integration
Integrate many times each day
Just-In-Time Design
Keep design simple
These ARE XP to most people
Test-first development
I won’t write code till I have a failing test that tells me what code to write.
Continuous integration
Microsoft integrates 1x/day.
This is not fast enough; we build once every hr., or more often.
Just-in-time design: YAGNI--You ain’t gonna need it.
This is antithetical to an analysis phase, ff’ed. by a design phase, & then by programming.
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

15. Test-First Development
Write tests before you write code
Write just enough code to get each test to pass
All about confidence
Programmer tests tell you when the code “works”
Programmer tests must pass 100% all the time
Test anything you need to be sure it works
People say, “Huh? I can’t do that…”
No code without a test
Use one of the XUnit testing frameworks, e.g., JUnit.
Write a class that subclasses TestCase.
You have a test method that makes an instance of the class & call a method on it.
Then make an assertion about result you get back.
At 1st, the test won’t even compile.
Then it runs, but “red bar”--means failure.
Write just enough code to get the test to pass—no more.
How long does this take? One to 5 minutes, maybe 10 at the outside.
What if it’s taking longer? Move to smaller tests
All about confidence--it is just to give you confidence that your code works.
Some systems have 1000 tests; they all need to pass. This may be extreme (XP …).
Otherwise, you’ll probably run out of time & don’t have time to test.
Can’t happen w/XP--you don’t have any code unless you have the tests 1st.
I’ve never seen any tests anywhere near as comprehensive as with XP.
Writing just enough code to make test pass--keeps you closer to the simplest poss. code.
Also, if I want to know how to use the class, it helps to look at the tests!
Tells you how to instantiate & use the object. And is up to date.
Complete test coverage, simplest code that could possibly work, clear intent
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

16. Continuous code review, more efficient learning, lower project risk
Pair Programming
2 developers, 1 computer, solving problems together
One person “drives,” the other “navigates”
Not Driver/Passenger
Not Pair Watching
Pairs should rotate
Love your pair
All production code gets two pairs of eyes
Why do people not do it? Pride.
Code reviews are good. Do them all the time!
Research shows code reviews are good
Hate them
Hard to do well
Pairs should rotate.
You don’t have a pair for a week. You may switch after 30 min.
That spreads expertise around, discourages reliance on heroes.
Jim Coplien: Truck #.
This way, everyone learns.
Yes, I could go read a book, post something to a newsgroup.
But if so. would just sit down & teach me, it would take a couple min.
Mantra of medical residency: “See one, do one, teach one.”
Seems interesting if so. is removing an organ.
We have it easier--all we lose is information.
Each member of the pair has a job
High “truck number” – no heroes
Love your pair.
Treat your pair as you would want to be treated.
You will be embarrassed.
If so. gets upset & is going to be a pill the rest of the day, then your pair will suffer.
Continuous code review, more efficient learning, lower project risk
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

17. Keep code simple, build learning in
Refactoring
Changing the design of existing code without changing function
All about speed
Refactor when code “smells”
Methods, classes that are too long.
Duplicate code (or “almost” duplicate code).
Switch statements (instead of polymorphism).
“Struct” classes—getters & setters but little else.
Refactor before adding a feature, and after
Can’t do this well without tests
Refactoring is about speed.
If there is duplicated code & you want to change the business logic, it takes longer.
So you use the “extract method” refactoring.
Examples of code “smells” (Wake, XP Explored)
Classes, methods that are too long.
Switch statements.
“Struct” classes--getters & setters but not much else.
Duplicate code, almost-duplicate code.
Overdependence on primitive types (instead of introducing a domain-specific type)
Useless or wrong comments.
Scope of variables larger than necessary.
You refactor before adding a feature to make it easier to add.
You refactor afterwards “to atone for all your sins.”--Kent Beck.
Keep code simple, build learning in
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

18. Convert “my code” to “our code” to lower risk
Collective Ownership
Any developer can change any code anytime
Programmer tests and customer tests tell you if you broke something
You break it, you fix it
Exercise: Is this a good idea? Look up points pro and con. Submit here.
Convert “my code” to “our code” to lower risk
Who should own code?
No one? Then everyone will avoid it or treat it as a black box.
“Black box” results in awkward interfaces.
What’s wrong w/individual ownership?
You have to negotiate w/someone if you want to change the interface.
 pressure to get interface done early so the rest of the project can proceed.
The owner of a class may veto a change, and then others design around it, worsening the design in general.
If the owner leaves, then this reverts to “no one.”
Can’t do this well without tests
You don’t need to ask permission to change anyone’s code.
If you don’t get green bars, you fix it.
But--
Hurts people’s pride--I like my code; you keep your hands off!
“Tragedy of commons”--everyone is responsible can mean no one is responsible.
But, test first & pair programming tend to mitigate this; no one can pollute in secrecy.
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

19. Continuous Integration
Integrate changes multiple times each day
One failing Programmer Test = no integration
Daily is not enough
No “Big Bang”
Exercise: Is this a good idea? Look up points pro and con. Submit here.
Maintain speed and spread risk by integrating many times per day
If you don’t integrate frequently, people can go off in drastically wrong directions, which becomes apparent only at the end.
Integration becomes a lot of work for whoever must resolve problems.
Daily is not enough.
If you build once/day & something breaks, you have to investigate who is responsible.
If you build immediately after finishing your change & it breaks, you are responsible.
Can’t do this well without tests
Developers must keep all unit tests running at 100%.
You have to check in your code when you finish.
The manager should verify that you are doing this.
For our Expertiza projects, you need to integrate frequently w/the projects that are related to yours.
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

20. Just-In-Time Design
Only design for what you’re building
Always keep the design as simple as possible (OAOO)
Simplicity allows for change
Change is constant
Exercise: Is this a good idea? Look up points pro and con. Submit here.
Simple design: passes all tests, has no duplication, expresses intent, has least amount of code
Expresses intent--refactored to the point where people can understand it.
Runs all tests, OAOO (once & only once), fewest classes/methods, clear intent
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

21. The closer you get to all, the better off you are
All Or Nothing?
Some practices can stand alone
Refactoring, Test-First Development, Pair Programming
All is better, some often better than none
All doesn't mean starting all at once
The closer you get to all, the better off you are
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

22. Agile Practices Roadmap
Copyright 2002 by RoleModel Software, Inc.

23. Project Success Revisited
Source: Dr. Dobbs, 2010
Ad-hoc projects
49% are successful, 37% are challenged, and 14% are failures.
Traditional projects
47% are successful, 36% are challenged, and 17% are failures.
Iterative projects
61% are successful, 28% are challenged, and 11% are failures.
Agile projects
60% are successful, 28% are challenged, and 12% are failures.
Ad-hoc. On ad-hoc software development projects the team does not follow a defined process.
Traditional. On a traditional software development project the team follows a staged process where the requirements are first identified, then the architecture/design is defined, then the coding occurs, then testing, then deployment. Traditional processes are often referred to as "waterfall", "classical", or simply "serial" processes.
Iterative. On an iterative software development project the team follows a process which is organized into periods that are often referred to as iterations or time boxes. On any given day of the project team members may be gathering requirements, doing design, writing code, testing, and so on. Rational Unified Process (RUP) is an example of an iterative software process.
Agile. On an agile software development project the team follows an iterative process which is also lightweight, highly collaborative, self-organizing, and quality focused. An example of an agile process is OpenUP, Scrum, and Extreme Programming (XP).
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

24. Agile vs. Waterfall
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

25. So What? Agile doesn’t matter – results do
Agile reflects the true nature of the problem (complex)
Agile is change-tolerant
Agile is realistic
Agile has the potential to facilitate organizational change
Agile increases likelihood for success
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer

26. Resources http://www.xprogramming.com (Ron Jeffries)
(JUnit testing framework)
Addison Wesley XP Series:
Extreme Programming Explained: Embrace Change, Beck
Extreme Programming Installed, Jeffries, Hendrickson, Anderson
Planning Extreme Programming, Fowler and Beck
Extreme Programming Applied: Playing to Win, Auer and Miller
Refactoring, Fowler
IBM developerWorks XP Column, starting in August (
Growing Software (working title), Addison Wesley, 2003
(Agile Alliance)
Copyright © 2002 by RoleModel Software, Inc., © 2017 Edward F. Gehringer