How to handle overflow work

One of the challenges that being Agile creates is the need for dedicated resources for each Scrum. It's wonderful when you're fully staffed, but can be a challenge when you aren't. One of the early programs we instituted in my current position was called User Experience Office Hours (OH). There are many different variations of OH, but this is how ours worked.

Each designer was asked to allocate two hours per week to Office Hours, recurring, on the same day. We booked a conference room every Tuesday, Wednesday, and Thursday from 3 - 5, and assigned two designers and one usability analyst to the slot. We then put the slots on a public calendar and let anyone sign up.

For a 5% investment of a designers time each week we were able to cover not only the 30% of Scrum teams without a dedicate resource, but also other teams that needed some User Experience feedback (Marketing, Operations, Release Management).

Below is the Wiki page I created to outline the program.

---------------

The Challenge

• User Experience is not able to formally support a number of SCRUMS and features
• UE doesn't want to ignore unsupported features
• Ease-of-use is important as a Company.com differentiator
• Consistency helps our users be more efficient and effective
• Small fixes can go a long way

Office Hours

• 2 hours, 3 times a week
• 2 x 60 minutes each day
• Tuesday, Wednesday, Thursday, 3:00 – 5:00 – Halia Conference Room
• 2-3 UE team members
• Unsupported SCRUM teams get preference. Non-Scrum team are welcome (Tech Ops, Marketing, etc.)

What it is

• A way to vet designs and approaches with the UE Team.
• A forum for getting recommendations on implementation and best practices
• An opportunity for an heuristic evaluation
• A means to petition for usability testing or addition design resources

What it isn't

• Not a mechanism to get designs done for you from scratch
• Not a (preferred) way to get extra time with your allocated SCRUM UE resource
• Not a means to circumvent other existing design review processes
• Not a avenue to get icons or images produced

How it works
SIGN UP on the UE Office Hours calendar in Outlook at //Public Folders/All Public Folders/Development/UE Office Hours. Select the time you want and add yourself as an attendee. Enter your topic, and any links to relevant Wiki or Project Requirements pages. Note: Adding attachments to the invite has proved to be problematic in the past, so consider doing a "reply all" to the meeting instance.

Must Have: Before you come, please have the following items ready. This will maximize our effectiveness and your results:

• User Stories – To help us understand who is going to be using your feature, and how it will be used.
• Design objectives – How will your design match up to your use cases
  
• A design artifact (i.e., something visual for us to look at) – Any or all of the following are fine: paper sketches, Power Point, Excel, Visio, web page
  

Nice to Have:

• Page flow diagrams – A chart or sketch that shows how all your pages will fit together
• Similar examples in the UI – Have we done something similar before in the application?
• Comparative / Competitive examples – Has anyone else done something similar before?
• Customer feedback – This can include feature requests, emails, ideas, forum posts, sales input
• Testing results – Have we tested similar functionality before, and if so, what did we say?
• Prototypes – If you have an interactive example to work with, that's great.

Typical Agenda

1. Project review - <>
2. Artifact presentation – 10 min – Show us what you've brought and what you're thinking.
3. Discussion / other examples –35 min – Converse about the artifacts and objectives, and get some of our feedback.

-----------------
Here's the weekly update I send out on Mondays:

Hi everyone -

For any questions on Office Hours, please see our wiki page (http://wiki/Main/UEOfficeHours ), or drop me an email. Feel free to book a slot on our Public Calendar at Development > UE Office Hours. Just a reminder that we meet in Halia on the 8th floor.

Office Hours Schedule - Current
Tuesday: 4-5, Administering Groups/Queues/Territories (Adam Smith)
Wednesday: All Open
Thursday: All Open

==============================

===========

Office Hours Schedule - Last week (75% utilization)

Tuesday, 3-4 Project X (Bob)
Tuesday 4-5 Feature Backwards Compatibility (Susan, Eric )
Wednesday 3-4 Content in the Sidebar Search (Jane, Sally, Fred)
Wednesday 4-5 Open
Thursday 3- 5 UE Team Event

------------------

The program worked so well, that it was adopted by our Documentation team, our Systems Test group, and our Architecture team.

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.