Started at a company with psuedo-waterfall process. Added cardboard box, saw some success. Weren't in charge of dev team. They hired NASA engineer to create documentation process, told us we'd spend the first year of the contract designing. We quit.

(Take a cardboard box: "This was agile.")

Moved to Abraxas. Noah walked into a design meeting with six managers, one remote programmer, and a spreadsheet (which the remote programmer couldn't see).

Need to come up with a few key points that we keep reiterating

We were purists ourselves and we learned that the people are more important than the process, even if the process is agile

Six managers, a programmer, and a spreadsheet

(But we told ourselves there's a lot of stuff)

We thought internal team communication was adequate and collocation would be disruptive

Two teams, each of which sits in eye- and ear-shot.

Didn't realize sitting together was about communication.

Didn't really have a customer role, even though we thought we did.

One person working on each story in isolation

Concept of team flow. Peopleware talks about noise and interruptions stopping individual flow, so that was our concern. We didn't realize that constant communication enhances team flow and it feels just as natural as what people call "flow" for individuals.

Team flow; now the whole team is working on the same story in the same part of the code with no problems

Did review and iteration planning in a single 1-hour meeting

Didn't distinguish between iteration planning and release planning; needed more time to design, both to decide what should be done, and to plan how to implement it. (*Not* BDUF, but rather getting everyone on the same page about how the story would proceed)

1.5 hour review, 2 hour iteration kickoff, 1 hour retrospective, "customer" doing release planning away from team, Moved from 1-week to 2-week iteration

Laid out what we thought would get done

Every day, team is asked to commit to iteration again. If they can't, that's feedback that we can provide to the customer to allow him to reprioritize if needed.

Wildly varying story sizes

Didn't necessarily complete any stories in an iteration

Didn't *commit*; didn't really understand what commitment means. Didn't understand that the purpose of the commitment was to allow for planning. Actively refused to commit to anything because it was about whether we could be blamed, rather than about providing feedback

The definition of "commitment" in agile. Trust was lacking, but we never acknowledged or addressed it. Customer did not trust us to meet our commitments (because we rarely did), we didn't trust customer to not blame us. (Intermingled with sustainable pace). We needed to start the cycle of trust. ("Agile is a social process.")

We Every day, team is asked to commit to iteration again. If they can't, that's feedback that we can provide to the customer to allow him to reprioritize if needed.

"Customer" (who wasn't really an XP customer) doesn't want to be involved in planning; just wants to tell us what we want.

We didn't notice that he wasn't fulfilling the complete customer role. Definition of XP customer role is elusive in the same way that the XP definition of "commitment" is elusive. (Is it elusive, or do we just not know how to commit, as men?)

Jeff is our customer analyst tester manager and all around great guy.

Argued about ideal hours vs. story points

It doesn't really matter. Took a lot of time and energy and distracted from the "people" part of agile.

T-shirt sizes. Make stories small and understandable. Don't obsess; estimating doesn't need to be a massive undertaking.

Weren't writing customer tests; had off-site contractor capturing customer tests and running full manual regression tests after each iteration (took a week)

A week is a really long turnaround time for acceptance tests

Replaced off-site regression tester with on-site test-as-we-go tester. Haven't yet come up with a full regression test technique

Released every week, put it in front of the customer to test. This was Noah and Brian's first agile practice they implemented.

Small releases, continuous integration and TDD *were* agile to us; this is what we took away from the agile docs on the net. Even though they're big wins, they're missing the point of agile, which is that it's a social process. It was easy to take those two processes, then stop.

Original story board (at ENSCO) was a cardboard box.

Cardboard box didn't communicate as effectively as we needed

Multiple whiteboards covered in information

Bug tracking software

Archiving was unnecessary. Bug trackers don't radiate information.

("How I learned to stop worrying and love using the whiteboard for bugs")

There's a difference between incremental and iterative. We get incremental; we make stories small. We still don't entirely get iterative; we still try to plan so that we don't have to go back and change them (we try to guess what we're going to need rather than just implementing the features we need now).

Whoever was working on a component would do whatever they thought was right when they got there

It's useful to the team as a whole to discuss the design of features. Collective code ownership doesn't mean you shouldn't talk about the design.

At the iteration kickoff meeting we get together as a team and task out all the stories. We've decided the person who *doesn't* have a vision of the story in his head should be the one to write the tasks to ensure more than one person has a sense of the design.

We lack a shared understanding of what simple design is

Didn't do it much. Why? People didn't want to do it.

It's not acceptable to not do it, but you don't have to do it all the time. That means that everyone should do it some of the time, not that some people should do it all the time. What's unacceptable is one person doing it none of the time.

Starting to pair more. Coordinate pairing schedule starting at the standup and throughout day, so everyone knows who they'll be pairing with that day.

Cannot *really* understand the benefits until you've tried it for a while.

Sometimes you have to be a teacher

Test-Driven Development

Tests need to be really loosely coupled in order to be fast. We could easily make a change that would cause a thousand tests to break. This should have told us that our design was wrong, but we didn't recognize that (or if we did, we didn't do much about it)

20 minute turnaround on CI

ASP.NET is untestable

Continuous Integration

Collective Code Ownership

Bringing agile to others having never done it ourselves

Opened everything to discussion, tried to accommodate all points of view

People's instinctive resistance to these ideas prevented us from trying them. We were better at implementing practices that didn't require the whole team to buy in (CI, TDD). Those were the things we obsessed over.

People self-select out (choose not to stay). When starting out, we want to get to the point where people can self-select out without worrying that the team will break down.

Needed to be in a better position to dictate how things are done -- needed team to be able to handle the friction so that we didn't have to fear the response.

We were so obsessed with making the agile process work that the process became more important than having things work.

Topic	What we did	What we didn't get	What we do
Intro
	Started at a company with psuedo-waterfall process. Added cardboard box, saw some success. Weren't in charge of dev team. They hired NASA engineer to create documentation process, told us we'd spend the first year of the contract designing. We quit.	(Take a cardboard box: "This was agile.")
	Moved to Abraxas. Noah walked into a design meeting with six managers, one remote programmer, and a spreadsheet (which the remote programmer couldn't see).
	Need to come up with a few key points that we keep reiterating
	We were purists ourselves and we learned that the people are more important than the process, even if the process is agile
Subtitles
Six managers, a programmer, and a spreadsheet
(But we told ourselves there's a lot of stuff)
Just relax
Whole Team
		We thought internal team communication was adequate and collocation would be disruptive	Two teams, each of which sits in eye- and ear-shot.
		Didn't realize sitting together was about communication.	Talk all day
		Didn't really have a customer role, even though we thought we did.	Have shared music
	One person working on each story in isolation	Concept of team flow. Peopleware talks about noise and interruptions stopping individual flow, so that was our concern. We didn't realize that constant communication enhances team flow and it feels just as natural as what people call "flow" for individuals.	Team flow; now the whole team is working on the same story in the same part of the code with no problems
Planning Game
	Did review and iteration planning in a single 1-hour meeting	Didn't distinguish between iteration planning and release planning; needed more time to design, both to decide what should be done, and to plan how to implement it. (Not BDUF, but rather getting everyone on the same page about how the story would proceed)	1.5 hour review, 2 hour iteration kickoff, 1 hour retrospective, "customer" doing release planning away from team, Moved from 1-week to 2-week iteration
	Laid out what we thought would get done		Every day, team is asked to commit to iteration again. If they can't, that's feedback that we can provide to the customer to allow him to reprioritize if needed.
	Wildly varying story sizes
	Didn't necessarily complete any stories in an iteration
	Didn't commit; didn't really understand what commitment means. Didn't understand that the purpose of the commitment was to allow for planning. Actively refused to commit to anything because it was about whether we could be blamed, rather than about providing feedback	The definition of "commitment" in agile. Trust was lacking, but we never acknowledged or addressed it. Customer did not trust us to meet our commitments (because we rarely did), we didn't trust customer to not blame us. (Intermingled with sustainable pace). We needed to start the cycle of trust. ("Agile is a social process.")	We Every day, team is asked to commit to iteration again. If they can't, that's feedback that we can provide to the customer to allow him to reprioritize if needed.
	"Customer" (who wasn't really an XP customer) doesn't want to be involved in planning; just wants to tell us what we want.	We didn't notice that he wasn't fulfilling the complete customer role. Definition of XP customer role is elusive in the same way that the XP definition of "commitment" is elusive. (Is it elusive, or do we just not know how to commit, as men?)	Jeff is our customer analyst tester manager and all around great guy.
	Argued about ideal hours vs. story points	It doesn't really matter. Took a lot of time and energy and distracted from the "people" part of agile.	T-shirt sizes. Make stories small and understandable. Don't obsess; estimating doesn't need to be a massive undertaking.
Customer Tests
	Weren't writing customer tests; had off-site contractor capturing customer tests and running full manual regression tests after each iteration (took a week)	A week is a really long turnaround time for acceptance tests	Replaced off-site regression tester with on-site test-as-we-go tester. Haven't yet come up with a full regression test technique
Small Releases
	Released every week, put it in front of the customer to test. This was Noah and Brian's first agile practice they implemented.	Small releases, continuous integration and TDD were agile to us; this is what we took away from the agile docs on the net. Even though they're big wins, they're missing the point of agile, which is that it's a social process. It was easy to take those two processes, then stop.	Everything else.
	Original story board (at ENSCO) was a cardboard box.	Cardboard box didn't communicate as effectively as we needed	Multiple whiteboards covered in information
	Bug tracking software	Archiving was unnecessary. Bug trackers don't radiate information.	("How I learned to stop worrying and love using the whiteboard for bugs")
Simple Design
		There's a difference between incremental and iterative. We get incremental; we make stories small. We still don't entirely get iterative; we still try to plan so that we don't have to go back and change them (we try to guess what we're going to need rather than just implementing the features we need now).
	Whoever was working on a component would do whatever they thought was right when they got there	It's useful to the team as a whole to discuss the design of features. Collective code ownership doesn't mean you shouldn't talk about the design.	At the iteration kickoff meeting we get together as a team and task out all the stories. We've decided the person who doesn't have a vision of the story in his head should be the one to write the tasks to ensure more than one person has a sense of the design.
		We lack a shared understanding of what simple design is
Pair Programming
	Didn't do it much. Why? People didn't want to do it.	It's not acceptable to not do it, but you don't have to do it all the time. That means that everyone should do it some of the time, not that some people should do it all the time. What's unacceptable is one person doing it none of the time.	Starting to pair more. Coordinate pairing schedule starting at the standup and throughout day, so everyone knows who they'll be pairing with that day.
		Cannot really understand the benefits until you've tried it for a while.
		Sometimes you have to be a teacher
Test-Driven Development
		Tests need to be really loosely coupled in order to be fast. We could easily make a change that would cause a thousand tests to break. This should have told us that our design was wrong, but we didn't recognize that (or if we did, we didn't do much about it)
		TDD is about design
	20 minute turnaround on CI
Design Improvement
	User controls	ASP.NET is untestable	JavaScript
Continuous Integration
Collective Code Ownership
Coding Standard
Metaphor
Sustainable Pace

Bringing agile to others having never done it ourselves
	Opened everything to discussion, tried to accommodate all points of view	People's instinctive resistance to these ideas prevented us from trying them. We were better at implementing practices that didn't require the whole team to buy in (CI, TDD). Those were the things we obsessed over.	People self-select out (choose not to stay). When starting out, we want to get to the point where people can self-select out without worrying that the team will break down.
		Needed to be in a better position to dictate how things are done -- needed team to be able to handle the friction so that we didn't have to fear the response.
			We were so obsessed with making the agile process work that the process became more important than having things work.