Archive for the ‘Agile’ Category

@tsharon #agileuxnyc talk on user research – raw notes reflections later @google http://itsourresear.ch

February 25, 2012

Google’s Tomer Sharon

Einstein looked at a physics form and said “at was ok for then, but today answers are different.”

How do you get out of the building in an Agile environment.

Now, Usability testing needs to be about right now.

Keep it small. Should be small thing, not a big thing. How? Like clockwork, every week.

Recruit in advance.

Plan really fast. For instance he is deciding on Monday what testing Tuesday. See Smashing Maf article.

If usability test falls in woods and no one hears, it did not happen. Team needs to decide what, who, etc. Testing AND what you do with results.

NO reports. Using Google spreadsheet.

Takes 45 minutes between each session. What they are doing is focusing on what happened, NOT possible solutions. Do this live, so.

Meander took 3 minutes for Eric Ries’ name to pop up in conference. Sr eve Brandt calls getting out of building.

In Hong Kong, smart thing is they have a signon sidewalk reminding walkers to look right, because drive English style on left.

Three things to do to get out of building:

Not going to, but at least bring users along.

Coders can write code for years and never see user use coded product. So Google schedules call with user of product and Dev or prod owner to chat. Not and test, necessarily. Ask user to talk about themselves, ask basic questions, and he steps back and let’s engineers, etc., talk, even ask leading questions. If patterns repeat, may do a product change. But more to humaniz e user for engineers.

Do an outside event. Go and visit a client. No agenda, no goals. Just go, maybe to their home, with goal to let engineers to interact with actual people who use their product. Extremely useful.

Collaging is third technique. Thoughts or feelings around a topic. Why? Sometimes people don’t know what they need. This is based on science. What people think they want or need is pretty much not what they need. He does not ask future state questions. Asks about most recent past, and teases out actual recent past problems.

Ask people to create a collage for a product. From magazines. Like a talking dumpster.

Tips for getting buy-in for user research. You become One Team who worksnon creating something.

Achieve Failure and Success Theater. In his mind, work on research in a way people care about it, by involving them. Collect research questions. Finding out stuff interesting but not helpful.

To get buy-in listen to what people say, identify assumptions and hypothesis and prioritize with everybody on team.

Dealing with introverts. Shows making a morning route talking with everyone on your team. About relationship of being in same company and caring about same things.

Book title: It’s Our Research (itsourresear.ch) out in two weeks. Videos on site.

Elsevierdirect.com

@jseiden #leanux #leanstartup @proof_nyc @agileuxnyc raw notes

February 25, 2012

Josh talking about requirements.

(this conference is incredible)

Internet Mouse

– dealing with a visionary unicorn who had them create an Internet mouse – the product guy framed as a requirement

Hypotheses are a more effective way to manage your work than requirements.

Eric Ries quote on products created in extreme uncertainty.

(Eric mentioned in every talk so far. He should be here.)

Business does thinking. Comes in and places order with product team. Problem is team has no visibility into business problem.

(This is #1 complaint I hear from the most senior creatives in advertising!!! We have briefs which hide the problem behind an order for a TV Ad).

How do you contain a creative?

If you are certain, need requirements. If output / outcome uncertain, you need hypotheses.

Validated learning is primary measure of progress. Not just working software (from Scrum).

Janice Fraser diagram of why every thing you out in market is a hypothesis.

(This is going to be big!………….No one clicked)

Less risk when you release more often.

An hypothesis is a proposed explanation of the way things work.

In order to be a hypothesis must be testable.

In case of Internet mouse: ” we believe people will pay for a Device to easily use Internet”

Slides will be posted, but has a list of process for hypothesis. (when I type less notes is because more words available in deck. Some folks all image.)

Find the riskiest hypothesis:

* To deal with people with requirements laid out in a story map mentioned @Jeffpatton ( go Jeff!). 😉

*Then identified risk spots on story map

All risks fell in one bucket: do customers value our offering enough to pay for it?

So from their developed hypothesis. One hypothesis about why people would pay (data!! In this case)

There are free widgets of similar function.

Tested against a persona (“Debbie”)

One-click install vs copy code. So in this case is a way to get people to install. Question should not be can people install it is there is enough value to install– so about the value.

Hypotheses are a way to reframe requirements. See his deck – I will post link when I get.

Question: story mapping – how to do non- collated teams – cardmapping.com.

“Jeff’s work is awesome, I encourage you to reach out to him via email. He’s going to love me for that.”

I am so lucky we were able to have Jeff come twice to my company.

“People want to work on stuff that is meaningful. When you see AgileUX starting to take hold, you see this efficient relationship. Teams feel surprised about the nonsensical requirements thrown over the fence at them.”

@phineasb. Sneakerheadvc.com @agileuxnyc

February 25, 2012

RPMs > Horsepower.

An investor

Talked about prototyping shoes, trying out sneakers on real kids. When the focus shifted to process, Nike started paying attention and bought them.

Learning a specific thing about a specific element. Like shoes w no laces. Iterated way to something that works.

[this feels like a gold rush. Lean is the new gold]

Web has returned to basics of customer development. Define a problem and iterate and push it out. Keep trying. Through that you create something customers love.

We all are responsible to work on changing mindset over skill set.

To max RPMs, mind set > skill set

1) unicorns / *: don’t care about users, what they know will work. Some one with vision drives at that. (Steve Jobs? For later pondering). They don’t listen to users. What happens instead is iterate on bad products. (Ha! Mentions Steve Jobs as exception).

[btw all slides]

Feedback that isn’t actionable (“can we make it pop”). Then time bomb(” not gonnna work”)

When we look at portfolio companies that do well is about understanding. Questions aren’t why doesn’t it pop, it’s what were you trying to achieve. It is -why- what did you expect user to do. You don’t prescribe answers you try to draw out thinking.

Getting feedback from people actually using the product. What’s first, prioritize in an office, then go out and watch people use and get frustrated. Totally re-prioritized features.

Hopefully at your company the visionary unicorn isn’t what moves the crowd but attest orbs he has invested in, data moves the behavior at the company. What are we measuring at the company?

Are or dashboards something that causes us tobask questions about the fundamentals og your business. [aha re: my secret product!!]

Everyone in company has to understand the goal of the company, all must be on board with removing friction in the organization and moving it faster.

Proactively push out in the organization and celebrate great product, celebrate other company’s wins. Make it tangible.

“turn this way to go faster”.

This is what this VC sees when things are going well, what they look for in new companies. Demand it gets done, o

#agileday2011 Andrew Kazarinoff on Agile Metrics: beyond the burndown

September 27, 2011

As usual, these are my raw notes

Paper to read: Jeff Sutherland and Scott Downey “Scrum metrics for Hyper-Productive Teams” July 2010

Qualytic Consulting is Andrew’s company; works as a coach

Metrics and anti-patterns:
– Root causes
– Coaching goals
– Behavior change

Anti-patterns > root causes > coaching
Visibility. Inspection. Adaptation.

Talked about an example of being with a group that had all stakeholders present.

Looking at turndown charts. When there are exceptions – what does it say?

To improve estimates, make sure whole team is part of estimating process.

“Found Work” affects estimation accuracy.

Commitment ratio – affects road map reliability and pace. Teams become over-cautious. Reminds me of when Jeff Patton did the ball exercise. Our teams were hyper-cautious.

Also, important that the work is done-done. Not “done.” Technical debt is a nasty creditor. Causes a clean-up Sprint.

Make sure stories are closed in sprint.

Effort focus:
– team at beginning estimates capacity
– can live with this providing does not change
– team members not continuously pulled off for problem fixes

Minimize context switching, enable capacity commitments to be met, make capacity commitments realistic.

What does management relate to? Does not relate to burn-down charts.

They relate to how much usable work have we done? Completed usable features or running tested features.