What we did
What we didn't get
What we do
wedge 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
wedge Subtitles
* Six managers, a programmer, and a spreadsheet
* (But we told ourselves there's a lot of stuff)
* Just relax
wedge 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
wedge 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.
wedge 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
wedge 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")
wedge 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
wedge 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
wedge 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
wedge Design Improvement
User controls
ASP.NET is untestable
* Continuous Integration
* Collective Code Ownership
* Coding Standard
* Metaphor
* Sustainable Pace
wedge 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.