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.

Agile Development + User Centered Design: Some observations

It seems a little strange to jump right in and start a blog with observations on Agile Development Methodologies and Design, but I had a great email conversation with Marty Cagan at the Silicon Valley Product Group that lead to me creating this list.

1. Using Agile is not an excuse for a lack of road-map planning. As a product owner, you still need to have a good idea where you're going or you won't know if you're making progress in that direction.
2. You represent the interest of the user. Users will tell you what they want, business owners will tell you what they want, technologist will tell you things are "hard". It's up to you to decipher what the users and the business NEEDS. This may be very different than what they say they want. (See the iPhone as an example)
3. The best way to get information is to go and ask the user. Watch how they work in their own workspaces. See if they use your product (or competing products) in unexpected ways. Ultimately, if you support their goals, you win.
4. If you have the bandwidth, take your team with you on the user visits, including your developers. You'll be surprised how much becomes "possible" when the engineers have seen your users struggling to complete a basic task with your product
5. Prototype early and validate frequently. You and your interaction designer should be joined at the hip. They should be able to implement your vision early, and should be able to provide you with a different perspective on the problem.
6. Show the prototype to user when you go visit them. Finish off your interviews by soliciting their feedback. Never underestimate the value of collaborative design with highly motivated users.
7. That being said, don't fall into the trap of building a solution for your most vocal user. You need to be able to sell your solution to a number of people if you're going to be successful.
8. As a product owner, the best thing you can do is have clear and un-ambiguous User Stories that your team can build. Your goal is to ensure that development time is fully utilized - you want to get the most bang for your buck
9. Let your engineers chunk functionality as they see fit. They will have quality criteria that the will need to meet each Sprint. It's your job to ensure that there is sufficient functionality to warrant a release to the user. Constant change can be more upsetting to your customers than less frequent upgrades.
10. Get training for your entire team. If everyone understands the mechanisms around Agile, then you can focus on the execution. If people don't understand, you'll get bogged down in the semantics and dogmatic issues.
    

You and your designers should always try and be 1 to 2 sprints ahead of your team. This allows you to validate difficult features with sufficient time to improve them. It also keeps you from getting too dissociated from the facts on the ground. You should strive for at least 90% coverage via usability testing.