Agile and Extreme Programming: A Pragmatic Approach

Agile and Extreme Programming: A Pragmatic Approach
Neal Ford Application Architect ThoughtWorks Blog: memeagora.blogspot.com

Questions, Slides, and Samples
Please feel free to ask questions anytime The slides will be available at I’ll show that address again at the end

What This Session Covers
The history and context of Agile development generally and Extreme Programming specifically What makes XP a discipline and not just a random set of activities How to gradually introduce Agile practices within an organization and still get the benefits What to say to your boss What to say to your boss’s boss Lots of questions and answers

Evolution of Methodology
Lots of thought on this subject since groups started building software “Use of GOTO Considered Harmful” Communications of the ACM, Dijkstra By the 1990’s, we had arrived at the Waterfall methodology Also known as BDUF (Big Design Up Front)

Waterfall and Similar Methodologies

Characteristics of Waterfall Methodologies
Requirements are gathered up front Business analysts End users Interested departments Maybe a JAD (Joint Application Design session?) Requirements lead to design Design leads to implementation Implementation leads to acceptance testing It is deployed

Where Does Waterfall Work Well?
Organizations where requirements don’t change Stable requirements leads to stable design… Stable design leads to “no surprise” implementation Etc. Who has requirements like this? NASA . . . Does this reflect your requirements? What happens when requirements change?

Changing Requirements
The later in the development cycle that a requirement changes, the bigger the impact on the scope of the change Documented by Barry Boehm Changes to well established code may have a ripple effect, causing side effects in other code How can you make coding changes with confidence?

The Evolution of Agility
Problem: much of the methodology work in software engineering has been based on traditional engineering Design Implement Deploy Software is fundamentally different In its very nature The way that people want to design, use, and modify software Problem: we’ve been trying to tell developers how to successfully write software…maybe we should find out how they work best

Lots of smart guys got together and re-thought how software is built
Agility Lots of smart guys got together and re-thought how software is built In the nick of time Most software projects fail The business risk of software development is far too high It seems hard to predict what will cause one project to succeed and another fail Observe successful projects and figure out what they did right Observe unsuccessful projects and figure out what they did wrong This led to the Agile Manifesto

17 Really Smart Guys met in Snowbird, Utah in February 2001:
The Agile Alliance 17 Really Smart Guys met in Snowbird, Utah in February 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Stephen J. Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas The agreed on a manifesto and supporting principles

The Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more”. The Agile Alliance

The Culmination of Current Thinking
The ideas in the Agile Manifesto didn’t just fall from the sky They had been percolating for several years in different forms The Agile Manifesto just documented what a lot of people were already thinking

Principles of Agile Development
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Agile focuses on the delivery of software Delivering software early and often allows for quick wins and early feedback about the requirements, the team, and the process The emphasis is to deliver the most important parts first If the project ends, there are still valuable artifacts Development proceeds from most important to less important Note that this may (and will!) change during the course of the project

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Most projects run 1 to 3 month cycles [Cockburn] Within the cycle, work is done in short iterations Iterations usually last from 2 to 4 weeks The iteration is complete at the end of the iteration, at the expense of moving requirements XP iterations are 2 to 3 weeks Users review progress throughout the process

Working software is the primary measure of progress. Code is the most important deliverable Agile methodologies place a premium on getting something up and running early and evolving it over time Agile does not discard the need for design documentation Diagram to understand, then move to code Documentation is secondary to working code

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. This works because of Early and frequent delivery of running software Use of iterative and timeboxing techniques Continual attention to architecture Willingness to update the design If you can gracefully accommodate changing requirements and your competition cannot, you win

Business people and developers must work together daily throughout the project. There is a strong correlation between links to users and project success [Frakes 1995] The best links are through onsite business expertise and daily discussion The longer it takes to get information to and from the developers, the more damage will occur in the project Information flow is similar to convection currents XP insists that business stakeholders are part of the development team

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. “It is better to have motivated, skilled people communicating well and using no process at all than a well-defined process used by unmotivated individuals.” [Cockburn 2002] “We hire good people, give them the tools and training to get their work done, and get out of their way.” [Thomas]

Developers are the Key You cannot overemphasize this point: developers, project managers, and business analysts make or break the project "All other factors being equal, a 90th-percentile team of analysts and programmers will be about four times as productive as a 15th-percentile team.“ [Boehm 1981] You should hire the smartest people you can find

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Communication is like air conditioning Cockburn defines modalities of communications and their effectiveness (Agile Software Development, 2002)

Cockburn’s Modalities and Effectiveness

Face to face communication about specific topics is most efficient
Agile also takes advantage of “knowledge radiators” Simple, low-tech information stores Poster board with index cards or Post-it notes Project status beside the coffee pot Automated build report via web browser (I’ll talk about continuous integration later)

The best architectures, requirements, and designs emerge from self-organizing teams. This means either that architectures, requirements, and designs emerge in small steps over time as a logical consequence of human-centric rules the team uses All 3 must be allowed to adjust over time An architecture that grows in steps can follow the changing knowledge of the team and the changing wishes of the users

Continuous attention to technical excellence and good design enhances agility. The design must evolve You must create good designs initially You must review and improve designs regularly Design cleanup as compared to debt [Cunningham 2001] Technical excellence applies to all aspects of the project Build management Coding standards Collaboration documentation

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Social aspect An alert, engaged staff is more effect than a tired, plodding staff Long hours are a symptom that something has gone wrong Only work 8 hours a day; never put in overtime 2 weeks in a row Technical aspect Software development can be viewed as a long strategic game Each move sets up the next move

Simplicity--the art of maximizing the amount of work not done--is essential. “This letter is longer than I wish, for I had not the time to make it shorter” Blaise Pascal It is sometimes more difficult to make things simpler A cumbersome model is easier to produce than a simple one DRY principle (Don’t Repeat Yourself) “Design for simplicity; add complexity only where you must.” Art of Unix Programming, Raymond 2003 “Code smell”

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Constant awareness is key Never get lazy XP encourages this every step of the way Questions: How light is too light? How simple is too simple? Can we make this simpler

Some Agile Methodologies
Extreme programming Scrum The Crystal Methodologies Crystal Clear Crystal Orange Crystal Orange Web

What Spawned Extreme Programming?
In the early 1990s, Kent Beck was thinking about better ways to develop software. He and Ward Cunningham had experienced an approach to software development that made every thing seem simple and more efficient. Kent contemplated on What made software simple to create What made it difficult In March of 1996 Kent started a project at DaimlerChrysler using new concepts in software development -- the result was the Extreme Programming (XP) methodology.

The 4 XP Dimensions What Kent came to realize is that there are four dimensions along which one can improve any software project. You need to improve communication. You need to seek simplicity. You need to get feedback on how well you are doing. And you need to always proceed with courage. Communication, Simplicity, Feedback, and Courage are the four values sought out by XP programmers.

XP: Rules and Practices
Planning User stories are written. Release planning creates the schedule. Make frequent small releases. The Project Velocity is measured. The project is divided into iterations. Iteration planning starts each iteration. Move people around. A stand-up meeting starts each day. Fix XP when it breaks.

Design Simplicity. Choose a system metaphor. Use CRC cards for design sessions. Create spike solutions to reduce risk. No functionality is added early. Refactor whenever and wherever possible.

Coding The customer is always available. Code must be written to agreed standards. Code the unit test first. All production code is pair programmed. Only one pair integrates code at a time. Integrate often. Use collective code ownership. Leave optimization till last. No overtime.

Testing All code must have unit tests. All code must pass all unit tests before it can be released. When a bug is found tests are created. Acceptance tests are run often and the score is published.

A Tour Through XP: The Project

A Tour Through XP: Iteration

A Tour Through XP: Development

A Tour Through XP: Collective Code Ownership

Recall the 4 dimensions of XP
Feedback Loops Recall the 4 dimensions of XP You need to improve communication. You need to seek simplicity. You need to get feedback on how well you are doing. And you need to always proceed with courage. The goal: a less extreme (pragmatic?) version of XP First pass: let’s get rid of the stuff that scares the boss and just do the rest

Why You can’t Pick and Choose Your Practices
XP isn’t just a group of fun activities that fit together because Kent Beck says they do XP is carefully calibrated for feedback Remember the diagrams for XP?

Feedback Loops in XP XP relies on feedback to work
Feedback loops relate to time scales The tighter the time scale, the more immediate the feedback

Creating a Kinder, Gentler XP
If you want to only do some of the XP practices, you have to replace the current XP activity with something that gives you the approximate same level of feedback That’s the only way you get the benefits from XP You cannot randomly pick and choose what practices you want to use! XP becomes worse than many other methodologies because you’ve destroyed one of the dimensions You are sure to fail with XP You’ll unfairly talk badly about XP to others

Substituting Practices: Planning
The Planning Practices User stories are written. Release planning creates the schedule. Make frequent small releases. The Project Velocity is measured. The project is divided into iterations. Iteration planning starts each iteration. Move people around. A stand-up meeting starts each day. Fix XP when it breaks.

User stories are written. User stories
Used to create the time estimates for release planning and acceptance testing Written by the customers as things the system needs to do for them Similar to usage scenarios but not limited to describing a user interface In the format of about 3 sentences of text written by the customer in the customer’s terminology without techno-speak Differ from traditional requirements in the level of detail

User Story Substitutions
Traditional requirements gathering tools Must be very flexible Must be granular CaliberRM is an outstanding choice for this Especially for companies that require traceability for requirements Easy to modify requirements Easy to attach custom fields to requirements records Requirements should be as narrative as possible, not just a dry list of facts The narrative conveys not just functionality but also workflow

User Story Substitutions
Requirements must be flexible User stories have lower detail than traditional requirements The developers and customer create detailed requirements face to face when it comes time to implement the feature Requirements and dependencies must be fluid Neither user stories or requirements should ever delve into technical details

Release planning creates the schedule
A release plan meeting is used to create a release plan, which lays out the overall project The release plan is used to create iteration plans for each individual iteration Decisions Technical decisions made by technical people Business decisions made by business people The development team estimates each user story in terms of ideal programming weeks

A project may be quantified by 4 variables
Release Planning Do not change the estimates for user stories if management is displeased with the amount of time it takes A project may be quantified by 4 variables Scope - how much is to be done Resources - how many people are available Time - when the project or release will be done Quality - how good the software will be and how well tested Management may choose 3 of the 4 values Development gets the remaining variable Lowering quality may have later project impact

Release Planning Substitutions
The goal is to achieve consensus between developers, management, and business people Don’t stop until everyone is happy (or at least equally unhappy) XP release planning makes the business stakeholders a integral part -- don’t allow the substitution to leave them out You must have business stakeholders to make it work You wouldn’t change your accounting practices without someone from accounting there, would you?

Make frequent small releases to customers (or customer proxies)
These are releases, not “90% done” This is a critical feedback loop You need customer feedback to feed the remainder of the development cycle The longer you wait to introduce an important feature, the less time you will have to fix it Small releases tend to focus developer productivity Forces the development team to solve tough problems rather than delay them

Small Release Substitutions
This one is hard to substitute This is the feedback loop between the customer (i.e., consumers of the application) and the developers You can simulate this by creating small releases within your department You’ve got to be diligent If you start slipping into the “90% done” mode, you’re sunk Try hard to get User Acceptance Testing into this small release cycle if you can “Quick releases: Help find bugs faster Let’s the users get to play with it faster”

The Project Velocity is measured
This is the measure of how fast work is getting done on your project Count how many user stories (or programming tasks) were completed during the iteration Total up the estimates that these stories received This helps future estimations during the next Iteration Planning Meeting During the Iteration Planning Meeting, developers sign up for the same number of programming tasks equal to the project velocity measured in the previous meeting

Don’t divide the velocity by the number of developers in the iteration
Project Velocity This mechanism allows developers to recover and clean-up after a difficult iteration Don’t divide the velocity by the number of developers in the iteration Doesn’t help determining the overall velocity Can’t compare it to other projects Discourages team building Project velocity will rise and fall during the project, which is normal Re-estimate if you see dramatic changes

Project Velocity Substitutions
It’s OK to use other metrics for this as long as They are reasonable, accurate metrics1 They are team based, not individual based They provide real value They are simple enough to understand In general, don’t try to measure this with Microsoft Project Perhaps the most misused piece of software ever written People use it to create meaningless charts and statistics Testing is important in XP, including Meta-testing of the methodology as it proceeds 1 There are very, very few of these -- see Brian Sletten’s Applied Object-oriented Metrics or David Bock’s Software Metrics and the Great Pyramid of Giza

Iterations The project is divided into iterations Divide the development schedule into about a dozen iterations, each lasting 1 to 3 weeks Don’t schedule tasks in advance Schedule tasks in the Iteration Planning Meeting It is against the rules to look ahead and try to implement anything not scheduled in this iteration YAGNI - You Ain’t Gonna Need It There is plenty of time later to respond to changing requirements

Iteration Substitutions
Iterative development is hard to substitute Tight iterations provides valuable feedback Keep development team focused Keep iterations short and cohesive Keep tasks very small and cohesive Avoid the temptation of gold plating Avoid “Big Bang” deployments Even if you must deploy that way in your organization, do internal “Little Bang” deployments Deploy often to User Acceptance Testing “Faster feedback on bugs and problems”

Iteration planning starts each iteration
A meeting is called at the first of every iteration Development work is selected User stories are chosen by the customer From the release plan Most important first Failed acceptance tests Development work is translated onto index cards Each task should be 1 to 3 Ideal programming days Developers sign up for tasks then estimate how long it will take

Don’t be tempted to change your task and story estimates
Iteration Planning The Project Velocity is used to determine if the iteration is overbooked Don’t be tempted to change your task and story estimates The planning process relies on the cold reality of consistent estimates Fudging them to be lower means you are lying to yourself It is normal to re-estimate stories and release plan every 3 to 5 iterations Always implement the most valuable stories first

Iteration Planning Substitutions
You can change this phase with a similar planning session It should be tied to iterations Long-term estimates must be fluid It is important for developers to create their own estimates Gets developer buy-in Their estimation skill gets better over time “We’re getting developers more interested in the project management side and honing their estimation skills”

Change developer assignments weekly, daily, or hourly
Move People Around Move people around Change developer assignments weekly, daily, or hourly Prevents serious knowledge loss and bottle necks Spreads overall knowledge around May be as simple as encouraging everyone to try working on a different section of the system at least part of each iteration Pair programming eliminates transition time Move one of a pair at a time Play “Musical Chairs” after lunch every day

Move People Around Substitutions
Harder if you don’t pair program The feedback goal here is to spread understanding around the project You can do this with regular code reviews Much less effective than pair programming Better than nothing This helps avoid the Truck Number anti-pattern Explain Truck Number Call this “cross training”

A stand-up meeting starts each day
Every day starts with the entire development team standing in a circle to communicate Problems Solutions Impediments To improve team focus It is more efficient to have one short meeting with everyone than a lot of little meetings Cross-team communication is the primary purpose

Stand-up Meeting Substitutions
This is part of the daily feedback loop Substitute with something that provides daily updates, problems encountered and solved, etc. You can set up A Wiki to share information Information Radiators However, this isn’t as rich a communications channel Cockburn defines modalities of communications and their effectiveness (Agile Software Development, 2002)

Cockburn’s Modalities and Effectiveness

Fix XP Fix XP when it breaks Fix the process when it breaks You should be willing to do this with any methodology Don’t buy into strictly prescriptive solutions

It is important to evolve your approach over time
Build Your Own Tools At ThoughtWorks, most of the Project Managers create their own tools for tracking projects Mostly created around Excel It is important to evolve your approach over time It changes from project to project You get better and better at it By the way - it's really, really important that PMs (especially client PMs) build their own tracking sheet. Taking someone else’s and mushing it around to make it work for the next project doesn't work. It's a psychology thing about owning the thing you built - and it's really important that PMs own their tracking tools. Roger Marlow, PM, ThoughtWorks

Substituting Practices: Designing
The Designing Practices Simplicity. Choose a system metaphor. Use CRC cards for design sessions. Create spike solutions to reduce risk. No functionality is added early. Refactor whenever and wherever possible.

Simplicity Simplicity A simple design takes less time than a complex one When you find something complex, replace it with something simple Keep things as simple as possible as long as possible by never adding functionality before it is scheduled Keeping a design simple is hard work “The present letter is a very long one, simply because I had no leisure to make it shorter. “ Blaise Pascal

Simplicity Substitutions
There is no substitute! Follow The Pragmatic Programmer rules The Art of Unix Programming 2. Rule of Clarity - Clarity is better than cleverness. 5. Rule of Simplicity - Design for simplicity; add complexity only where you must 6. Rule of Parsimony- Write a big program only when it is clear by demonstration that nothing else will do. 13. Rule of Economy - Programmer time is expensive; conserve it in preference to machine time. 14. Rule of Generation -Avoid hand-hacking; write programs to write programs when you can.

Choose a system metaphor
Keeps the team on the same page by naming classes and methods consistently Good names => Understanding the overall design of the system Code reuse Stick as close to the problem domain as possible

System Metaphor Substitutions
Take the time to do this no matter what your methodology Makes everything in the project make sense because it provides context “We’re trying to create a way that we can describe this to the business side to get their buy-in”

CRC Cards Use CRC (Class, Responsibility, and Collaboration) cards for design sessions Allows people to break away from procedural thought and more fully appreciate object technology Individual CRC Cards represent objects

CRC Cards A CRC session proceeds with someone simulating the system by talking about which objects send messages to other objects By stepping through the process weaknesses and problems are easily uncovered Design alternatives can be explored quickly by simulating the design being proposed

CRC Card Substitutions
This is one of the easier characteristics to change Make sure that you find a design technique that is Very flexible Interactive Involves the entire development team Serves the needs of the stakeholders Allows for “What if” games Many organizations prefer more documentation CRC cards OK as long as you don’t get the cart before the horse Don’t let a static medium discourage flexibility

Documentation “We have to have documentation so that…
We can re-create it? We can kill more trees? We know what it does?” The tests are better documentation than any outdated Word document You have to keep them updated if the requirements change You can verify the requirements (tests) anytime You know what it does by the tests If he has to have documentation… Make it a task within the iteration Spread it around Try to apply the DRY principle to it as much as possible

Spikes Create spike solutions to reduce risk Proof of concept projects to reduce technical risk Ignores all outside concerns Expect to throw it away (this is not a prototype!) This is common in most methodologies Avoid the temptation to just build up from the spike

YAGNI No functionality is added early One of the hardest things for developers to not do! We are all tempted to add functionality now that we are just sure is going to be needed later Extra functionality always slows us down and squanders resources

No Functionality Added Early Substitutions
Don’t! You start creeping towards Big Design Up Front Focus on the task at hand

Refactor Refactor whenever and wherever possible You must be willing to change code anytime it should be changed Don’t’ live with broken windows Too much software becomes brittle because of 100’s of tiny compromises You must be willing to refactor

Substituting Practices: Coding
The Coding Practices The customer is always available. Code must be written to agreed standards. Code the unit test first. All code is pair programmed. Only one pair integrates code at a time. Integrate often. Use collective code ownership. Leave optimization till last. No overtime.

The customer is always available
Customers The customer is always available Business stakeholder must be available If you can’t get a business person, get a worthy substitute One of the few hard requirements of XP “We have to know what to build… Requirements documents are out of date as soon as they are written Getting this right is important to the business We want to be able to respond quickly to changing requirements Developers != business people”

Standards Code must be written to agreed standards Almost every methodology does this Don’t try to substitute this!

Test-first Coding Code the unit test first Creating a unit test helps a developer to really consider what needs to be done Requirements are nailed down firmly by tests There can be no misunderstanding a specification written in the form of executable code

Test-first Coding Substitutions
Test-first coding is the most effective way to write code You get nearly as good feedback if you make sure you write tests concurrently They must be written right away Planning to write them next week doesn’t count! You can delay testing your code slightly, but you must write tests! Tests are the only way you can write code with confidence “This is the set of requirements” “Here is a coverage test that shows how much of our code is verified.”

Pair Programming All code is pair programmed The most Extreme practice in XP! Two people working at the same computer will add as much functionality (or more) than 2 people working separately except that it will be much higher in quality Pair programming increases software quality without impacting time to deliver Works best with 2 developers of more or less equal skill

Get Comfortable Pair programming feels awkward at first It helps if you are set up for it Pair Programming at ThoughtWorks

Pair Programming Substitutions
Tough because this represents the most immediate code feedback loop, on the order of minutes You can achieve the (greatly diminished) similar effect with very frequent code reviews Very frequent means daily or at least once weekly Think about how much code is written before it is peer reviewed Still pair on particularly complex parts (to help figure out how to make it simpler) Try it, with useful metrics, to help convince your boss

Pair Programming -- Politically
“You’re going to do what!?!” You must show quantifiable results Try keeping useful metrics before and after Don’t make it about silly things like lines of code Use bug counts Use passed tests If you already support code reviews in your organization, this is really just real-time code reviews Start doing it without telling anyone on really complex parts

Integration Only one pair integrates code at a time Designed to cut down on regression test failures that cascade This is do if you have effective source code control in place This assume a canonical source for your code Strongly consider continuous integration to automate testing

Integrate Often Integrate often Developers should be integrating and releasing code into the code repository every few hours, whenever possible Always work in the context of the latest code There is a direct correlation to this feedback loop and its benefit which has nothing to do with XP

Collective Code Ownership
Use collective code ownership Any developer can change any line of code to Add functionality Fix bugs Refactor There is no one person (not even an architect) who has the entire vision The code base is continually changing Unit tests and frequent integration preserve order

Collective Code Ownership Substitutions
Hard! You should try to adopt this attitude no matter what your methodology This is a meta-feedback loop -- it enables the others to work This is one of the enabling characteristics for real teamwork

Optimization Leave optimization until last Do not optimize until the end Never try to guess what the system's bottle neck will be Measure it! Make it work, make it right, then make it fast We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Donald Knuth

Overtime No overtime Working overtime sucks the spirit and motivation out of a team Projects that require overtime to be finished on time will be late no matter what you do Hard to substitute this because its worth is self evident Make a rule that you never work overtime 2 weeks in a row Prevents the (very real) danger of complete burnout “Our developers start writing code that causes a lot of test failures after 12 hour days!”

Substituting Practices: Testing
The Testing Practices All code must have unit tests. All code must pass all unit tests before it can be released. When a bug is found tests are created. Acceptance tests are run often and the score is published.

Testing: Unit Tests All code must have unit tests One of the cornerstones of XP (and modern development practices) Compilers only tell you if the spelling is right Tests tell you if it does what you think it does Don’t substitute for this, incorporate it

Unit tests are both feedback and meta-feedback
All code must pass all unit tests before it can be released to version control Unit tests are both feedback and meta-feedback A strong suite of unit tests enables refactoring, collective code ownership, etc. Don’t substitute or slack on this one either Be careful about getting behind on tests (you’ll never catch up) Won’t happen if you do Test-first development Don’t substitute, incorporate

Bugs and Tests When a bug is found tests are created If you are testing anyway, you should create a test every time you find a new bug Prevents that bug from ever reoccurring Don’t substitute, incorporate

Acceptance Tests Acceptance tests are run often and the scores are published Created from user stories Another important part of testing Provides confidence that you are creating the right thing The highest scope feedback loop, from Create User Stories all the way to final coding You must have some criteria to determine when you are done Requirements => Acceptance tests

Organization Roles in XP Projects
Project Manager Planning Project Velocity Cat herding Business Analyst/Stakeholder Knows why the application is being written Developer Tester Architect Doesn’t remove the need for Enterprise Architecture Application Architects act as on-going policeman for the overall structure of the code May be overridden at any time by developers

Substitution Scale User Stories, Release Planning, Fix XP, CRC Cards, Spike Solutions Easy Small Releases, Project Velocity, Iteration Planning, Move People Around, Stand-up Meeting, Coding Standards, Pair Programming, No overtime Intermediate Iterations, Simplicity, System Metaphor, Early Functionality, Test-first Coding, Integrate Often, Collective Code Ownership, Optimize last, Acceptance tests are run often Hard Refactor, Customer is Always Available, All code must have unit tests, All code must pass unit tests, Create tests when a bug is found No Substitute

You are never going to convince him with just arguments
What to Tell You are never going to convince him with just arguments Too much of XP is counter-intuitive He thinks you are trying to pull a fast one Demonstrate that this works Create a pilot project Pick a small-scoped, orthogonal project Pick a team that can work together Rock and roll! Use useful metrics Number of tests passed (should be higher) Number of bugs (should be lower) Extrapolate

When All Else Fails… Trade this guy for that guy

Questions? Samples & slides at www.nealford.com
memeagora.blogspot.com This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 license.

Agile and Extreme Programming: A Pragmatic Approach

Similar presentations

Presentation on theme: "Agile and Extreme Programming: A Pragmatic Approach"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Agile and Extreme Programming: A Pragmatic Approach

Similar presentations

Presentation on theme: "Agile and Extreme Programming: A Pragmatic Approach"— Presentation transcript:

Similar presentations

About project

Feedback