Agile Development + User Centered Design: Some Executional Oberservations

Here are some additional thoughts around Agile Development Execution that came up in my conversation with Marty Cagan at the Silicon Valley Product Group.

Agile Execution

1. Because Agile promotes a philosophy of "Just In Time / Just Enough" there is a push away from heavy documentation specifications. This makes face-to-face communication more vital than ever. It also reinforces the need for a central set of artifacts that everyone can share (User Stories, Task Cards, Prototypes)
2. The daily status meetings are the beginning of the communication process, not the end. There should be a constant stream of discussion about all aspects of the product. Designers should be previewing functionality to the developers and QA. Developers should be showing off completed code to each other, QA and the User Experience team. QA should be identifying potential pitfalls during prototyping, and should help the team make better implementation trade-offs.
3. Proximity helps. Teams that sit together can often have the informal conversations that drive the product forward faster. The one caveat is that those conclusions should be shared with remote team members so nobody is surprised (see bullet 1)
4. Good estimation is the foundation of great execution. It may take a couple of cycles to figure out, but once you know your team's velocity and productivity you can more accurately assess future work and only commit to what you can finish.
5. It's better to under-commit and be able to take on more work, than over-commit and finish a set of impoverished functionality.
6. Agile generally doesn't require heroics. If you find that you're doing 16 hour days regularly (and you don't love working 16 hour days), there's some expectation error somewhere in your process. Either you need to train the Product Owners better on how Agile works, or you need to reassess your estimation abilities and commit to less.
7. Never underestimate the value of a full-team / full-company review. At the end of each Cycle (Sprint) pull everyone together and show off the great work that you've finished. Talk candidly about what you signed up for and what you got done, and then demo.
   
8. Demo your completed code, as well as the prototype for the next phase. Having everyone see what you finished validates your hard work, gives the entire company insight into the product, exposes people to functionality they probably aren't familiar with, and increases consistency by socializing common interactions.
9. Planning matters. If you've done your user validation steps and have built and tested your prototypes, planning should be a snap. As the product owner you have the responsibility of helping to create the "Story" or "Theme" that ties your release together. Based on your theme, you should pick the User Stories that support that theme for your current release. The developers can then estimate those stories for effort and you get to draw the bright-line cut off to say what gets in.
10. Practice continuous improvement. At the end of each cycle, ask what worked, what didn't work, and what blocked your success. If these are in your control - fix them. If they're not, escalate them and/or get more training.
    

Sometimes teams get all of these, and sometimes teams get some. The best process is one that suggests and scaffolds, rather than dogmatically proscribes the steps to follow. Every team is different so you need to find the way that works best for you.