Queen’s Round – download audio file

Agile Product Management in Practice

I will try to update this sadly neglected blog with a summary of said talk sometime soon.

The basics

If you can do these three things, you can get useful results for most searches on common topics:

1. Read really fast. I don’t know if this is the same as speed reading or not, but the ability to skim rapidly for keywords is critical to being able to sort out what you’re looking for from the masses of link spam. If you don’t know how to speed read, check out lifehacker.com or similar for tips.

2. Start with the phrases you would expect someone to use. Whatever question you have, chances are someone else has already asked it on a bulletin board somewhere  Actually type in a whole phrase instead of just a couple of keywords – often this is all you need to do. For example “how to create a site map” will get you much better results than “site map”

3. It’s a big internet, be specific. Start specific and then broaden your terms if you don’t get the results you’re looking for. For example if you’re looking for the best way to generate a site map for a large site “best approach to site map creation for a large site” is the place to start. If the first 5 results don’t contain anything useful, then try “best approach to site map creation.”

Just following the tips above should get you something within the first page of results. If that doesn’t work, move on to the next section.

When that doesn’t work

Sometimes I’m googling for stuff that’s a little more obscure or non-technical (my hobby is costuming, especially historical costuming).

4. Don’t stop at the first page of results If there are sponsored results at the top of the page, that often correlates to the first page is full of search engine optimized pages. Most of what I’m looking for is *not* from folks that spend a lot of time on SEO. Before giving up on a particular search, I usually scan all the results on the first and second page and then click to a page further into the results (10th or thereabouts). If there’s nothing close to what I’m looking for then it’s time to move on to the next step.

5. Find synonyms. Maybe you’re searching for the wrong words.  Click on the most likely results you can find in the first couple of pages. Focus on things that look like bulletin boards or discussion forums. Sponsored results also come in handy here; people who are selling you something will be trying to use clear language. Skim those pages looking for synonyms. Now repeat steps 1-3 using your new search terms.

If all else fails

6. Try a different type of search. If you can’t get what you want from a standard google search, take the same thing to image search. People’s captions and diagrams are often quite relevant. Click through the likeliest looking images and scan the resulting pages… If that doesn’t work, try an abbreviated form of your search on twitter. Then repeat step 5. Until it works

Happy searching!

Note: This was supposed to be an easy post – take something I’m good at, break it into steps, voila. But when I started dissecting what I do it’s actually more complex than it feels…  posting it anyway in case it’s helpful to others.

example of a lightbox

Lightboxes have come to replace pop-up windows as a way of drawing the user’s attention to particular information by dimming the rest of the screen. They are a great way of focusing user attention on a particular message or interaction. But, like pop-ups before them, lightboxes are a tool that’s easy to misuse. Here’s some simple guidelines for friendlier, more effective lightboxes:

Lightboxes are not a replacement for pages:

• Use lightboxes sparingly. A lightbox stops a user in her tracks. Are you sure that’s what you want to do?
• The lightbox should not cover more than 50% of the screen–if it’s that big, it’s time to launch a new page.
• Beware of scrolling in lightboxes — if there’s enough content in the lightbox to require scrolling, it might be time for a new page.

Dimmed content may be needed so keep it legible:

• Be careful how much you dim. If the overlay is too opaque, the user loses context, if it is too transparent, there is too much visual “noise” for the lightbox to be effective.  40% opacity seems to work well for a solid black overlay.
• If the lightbox depends upon the user being able to read the dimmed content, make sure the lightbox is repositionable and has clear affordances for repositioning such as a title bar with cursor change on mouseover.

Always give the user an out:

• When the user needs to take  a specific action such as submitting a form, make sure the button or link is immediately visible and  recognizable. Don’t depend on users to read your helpful instructions.
• When there is no specific action required, for example when expanding a thumbnail image,  add a close control indicated  either by an “X” in the upper right corner or with the text “CLOSE”.

Idea courtesy of Fi’s decision *not* to be a ninja for halloween after all.

Preconditions:

• User has access to ingredients consisting of:
  • 9″ pie shell/crust (trader joe’s makes a good one)
  • about a dozen apples (you can use Granny Smith if you can’t get Gravenstein, but then you need more sugar)
  • sugar
  • cinnamon
  • nutmeg
  • vanilla
  • salt
  • 1 large lemon
  • 1 stick of butter
  • flour
• User has access to typically equipped United States kitchen including oven, cookie sheet, spatula, aluminum foil, pastry cutter and medium mixing bowl
• Oven is preheated to 400°

Success Case: Pie.

1. User sets the frozen pie shell out to defrost.
2. User peels the apples and slices them up thinly into bowl.
3. User drizzles a small amount of lemon juice as each apple is sliced into bowl.
   1. Acid in lemon juice destroys enzymes preventing phenols and enzymes in apples from reacting – apples brown more slowly
4. User repeats steps 2-3 until bowl is approximately 2/3 full or contents will overfill pie shell.
5. User sprinkles cinnamon and nutmeg on to apples in bowl.
6. User adds up to 1 teaspoon of vanilla
7. User adds up to 1 cup of sugar
8. User stirs contents of bowl with spatula
   1. Apples are coated with sugar/spice mixture and a syrup develops in bottom of bowl.
   2. An odor of cinnamon and vanilla permeates the area immediately surrounding the bowl.
9. User dumps contents of bowl into defrosted pie shell, mounding in middle.
10. User washes and dries bowl.
11. User adds 1 stick butter 2/3 cup flour, 2/3 cup sugar and 1/2 tsp of baking soda to bowl.
12. User repeatedly mashes butter into dry ingredients with pastry cutter
    1. Mixture takes on appearance of coarse crumbs
13. User pats handful of crumble topping onto apple mixture in pie shell. (repeat until bowl is empty)
14. User places pie shell on cookie sheet.
15. User places cookie sheet (with pie shell containing apple mixture covered in crumble topping) in oven and sets timer for 15 minutes
    1. Pie cooks, high temperature browns bottom crust
    2. Timer sounds
16. User protects edge of crust with strips of aluminum foil
17. User reduces oven temperature to  350º
    1. Filling cooks  slowly, bubbling up through crumble topping onto cookie sheet.
    2. Fructose and Sucrose oxidize resulting in caramelization
    3. Kitchen smells really good
    4. Timer sounds
18. User removes cookie sheet with pie from oven.
19. User turns off oven.
20. User sets timer for 1 hour.
    1. Pie cools.
    2. Pectin from apples gels.

OUTCOME: Delicious apple pie!

Variations

Error Case a: Pie shell not defrosted

Proceeds as in success case with the following variations:

10_a. User curses under breath, then washes and dries bowl.

Steps 11-14  unchanged.

15_a. User goes and finds something else to do for an hour, then places cookie sheet in oven.

Steps 16-20  unchanged.

Error Case b: Bowl not sufficiently dry.

Unrecoverable error. If user does not dry bowl, crumble topping will be tough and chewy, consider adding bowl dryness detection requirement.

Error Case c: Overworked Crumble-topping

Unrecoverable error. If step 12 is repeated too frequently, crumble topping will be tough and chewy, add visual inspection of consistency after each repetition?

Error Case d: Cookie sheet omitted

Proceeds as in success case with the following variations:

Step 14 omitted

15_d. User places pie shell containing apple mixture covered in crumble topping in oven and sets timer for 15 minutes

Pie cooks, high temperature browns bottom crust Timer sounds

17_d. User reduces oven temperature to  350º

1. Filling cooks  slowly, bubbling up through crumble topping onto oven heating element
2. Kitchen fills with smoke
3. Timer sounds

Proceed as in success case steps 18-20, only with more cursing.

Deferred Use Case: Eat Pie.

Theoretically, self-organizing teams evolve over time from hierarchical teams… but in this case 24 people, who knew each other only slightly, came together and taught 50 other people complex technical skills over the course of 10 hours. This happened with relatively little advance planning for the bulk of the participants. Despite, or perhaps because of (more on this later), the typical chaos of last-minute additions and cancellations, the weekend went more smoothly than many heavily-organized corporate trainings.

Here’s some of why I think it worked:

• Start informally. Installation had been previously identified as a roadblock to learning, so the first night of these workshops is an installfest where volunteers are available to troubleshoot as attendees go through the process of setting up a development environment. This had the added advantage of letting people get to know each other in a fluid, non-hierarchical manner so that they were better able to work together during the instruction portion of the workshop the following day.
• Establish clear goals and leave the details to the people doing the work. Excellent leadership counts for a lot; the Sarahs set (and repeated as often as necessary) a clear goal — everyone should leave the workshop having successfully deployed a web application. They provided the tools necessary to achieve that, but did not dictate how those tools should be used. Teachers were given a framework curriculum for instruction, but not a step by step training manual. The same materials were used by all the instructors but the details of how they were used varied per group and per experience level.
• Just-in-time roles. By nature, attendance of both volunteers and participants is unpredictable. This forces class assignments to happen at the last possible moment. While this was somewhat stressful at the time, ultimately it made for a better experience.  Total novices got a more structured, lecture-oriented morning session that suited the larger group size, people with minimal programming experience were broken into 8 person teams and the remaining participants were divided into 3-4 person groups; a structure that  worked very well for the different levels of experience. Because we were unable to create groups in advance,  the groups that were created were the right ones for the situation… and because they understood the fluid nature of group assignments, our volunteer instructors did a fantastic job of assigning themselves to groups as needed and coordinating the training amongst themselves, with 3 groups merging and separating as needed. This is not something that would have worked nearly as well had we tried to assign everything in advance.
• Resource abundance. Thanks to the overwhelming response from the SFRuby Meetup group, the student to volunteer ratio was 2:1 — in addition to providing attendees with a lot of personal attention, this meant that volunteers could shift roles fluidly from searching for extension cords (lesson learned for next time) to helping with the door to helping teach. I think this is the hardest lesson to translate to the corporate environment. It is critical that there be enough people for priorities to shift without impacting outcomes. I contrast this with the last so-called “tiger team” I worked on, where due to pressure to be “lean” there was only one developer until very late in the project–at the retrospective, we identified that the team was not efficient until the development team was expanded so that the developer could do more than code.  Many hands make light work… they also make better work.

There’s much more that went into the planning and execution of the workshop than I have detailed here, but what binds it all together is trust. Trust is a bountiful commodity in this all-volunteer environment, and perhaps that, most of all, is what allowed the rapid evolution of a large, self-organized team… but that’s a post for another day.

It’s taken three tries because I suffer from the knowledge that, in this day and age, anything I might choose to say has already been said, and you, gentle reader, can google it. Nevertheless, I will proceed, daunted but unbowed. Here’s what I want to write about this week:

• The RoR Outreach Workshop for women, where I met the aforementioned Sarah (and the other Sarah)
• The transition our team made from Scrum to Kanban over the past 2 months
• How I search… because I do it better than you. (Well, maybe not *you* if you found this blog. But better than most people.)
• My apple pie recipe.

That seems doable. We shall see, tomorrow.