Monthly Archives: May 2013

May 22, 2013 (Scott’s table)

Posted on by

What’s the best way to immerse dev teams in customer experience

      – Common difficulty
      – Watch usability testing
      – Voice of the Customer Project at Yahoo with VCs
      – Answer support calls
How to handle content localization when it takes longer than dev cycles
      – Paid crowdsourcing: Mechanical Turk, Task Rabbit
      – Placeholder content
      – Include content readiness in release discussions
      – Cascade translation releases
      – Use metrics to decide highest priority translations
Servant Leadership/Becoming a manager
      – Find ways to learn with the family
      – 2 1/2 years to get good at it
      – Mentorship opportunities
      – Goal oriented learning
      – Empathy, trust and monitor output
Is Agile advocacy more effective top down or bottom up?
      – Seems easier top down
      – Without team buy in, doomed to fail
      – Cultural factors crucial
      – Both are necessary for success
Incorporating testing earlier in dev cycle
      – Who owns the problem, QA or Dev?
      – Behavioral Driven Development
Effective learning in your personal time
      – Figure out what type of learner you are
      – Achieving goals leads to momentum
      – Integration with family rhythms
Reassuring management when velocity drops
      – Highlight other metrics
      – Anticipate velocity drops and broadcast them
      – Show impact of decisions on velocity
Wrap up: More equal group split, more topics, 6 minute initial discussion period

May 22, 2013 (Dan’s Table)

Posted on by

Preserving culture during company growth

– You can’t preserve culture. It is made every day.
– If you want a certain culture, do those things.
– Choose people when hiring
– Office can set the tone
– Management can set priorities but they need to do them.
– Do you want the same culture after growth? Cultures don’t necessarily scale. Culture of 30 doesn’t work with 80.
– New people will change the culture. You can’t avoid it; you can try to steer it.
– Politics

Help desk knowledge base / beta software
– Multiple products
– new refs on different schedules
– how to support beta customers
– beta customers may not know that they are beta customers. (more of an A/B sort of testing)
– who gets the beta?
– stop doing beta. Deliver faster, do fewer changes in each release.
– Dogfood

Managing customer-visible help pages
– Standard pages vs custom pages written by a rep
– Can customer tell what they are looking at?
– How would you find errors?
– Variation by itself isn’t a problem; incorrectness is.
– customer-facing sites may become stale
– CSRs need to be accountable for accuracy
– Do pages get audited?
– What about when CSRs move on>

Bringing standup back to focus
– Gamify it
– Time people
– encourage brevity: measure it.
– try it for a week and people will start to recalibrate to what a short statement sounds like
– What is the point of the standup? (varies by team)
– Limit who is in the meeting. Only pigs get to talk; chickens get to watch. (In consulting, being a pig or a chicken depends on if you are billable to that project)
– Stay on target
– If what you want to say doesn’t add value, don’t say it.
– Learning questions: Instead of talking about what you did, talk about what you learned.
– Be aggressive about the rathole call: if the discussion is wandering, call people on it.
– For special cases: you can talk as long as you hold the electric ball: http://www.thinkgeek.com/product/91b8/
– Don’t have the standup in a comfortable place where people relax. Stand up; make people want to finish and get back to work.
– Save the staff meeting stuff for a staff meeting

How to companies manage customer experience across different channels (blog, ads, help desk, youtube videos, etc)
– Who owns each channel?
– Does old content get pruned?
– Analyze what works
– Who originates content? (NR has engineers write blog postings about new features)
– Solutions can get out of date

Presenting to developers
– Know your audience
– Know your material
– Know your message
– Right amount of emotion in your talk. Engineers can smell a sales pitch and will tune you out
– More interactive/less interactive
– Tell a story. Don’t just recite facts.
– Talk about the “why”
– Get devs talking to customers, out of their comfort zone
– Presentation Zen/Tufte
– Interactivity
– are you trying to influence behavior or just convey information?

Lean Roadmaps
– Once you get past a few months out it gets fuzzy
– Quarterly roadmaps
– features vs maintenance
– Release often and change direction as needed
– All about communication
– still need a vision, even though the specifics may be fuzzy
– 3 months is a long time in technology
– Always question priorities. Are we doing the most important thing?

May 8th, 2013 (Scott’s Table)

Posted on by

photo (1)

1. How do you describe Agile?

– Fail fast
– Start with stories- humans like stories
– Lean – get results in front of people as fast as possible
– Customer driven
—who are the customers in your context?
– Lightweight
– Try Lean Coffee
– An interesting problem, and the generalization makes a lot of sense
– Do civil engineers do a lot of projects that are information based or are adaptable?
– Buildings iterate less well, where is the iteration?
– Examples: A map, a budget
– Iterate: the plan WILL change
– As a ___ I want___so that ___
-structure for stories includes protagonist and goal
– Provide value

2. McDonald’s Theory/Social Hacks

– The McDonalds hack see https://medium.com/what-i-learned-building/9216e1c9da7d
– Useful if discussion is deadlocked, or team needs to get unstuck
– Propose something bad then you can get a response, get people to commit
– Posting bad information (to draw out good information)
– Devious trait
– Name Tags with trivia to jumpstart conversations/team building idea
– Adjusting expectations
– Lean coffee
—the structure of lean coffee is a form of social hack
– Personality trait? Learned skill?
– “I’m just a dumb XYZ but…”
– Parenting
—-lots of tricks parents learn
– Names and memory tricks
– Icebreakers, conversation starters (a lot of facilitation/teaching tricks are social hacks)
– Breaking an impasse
– Listening

3. How do you get your creative flow going?

– Pomodora technique
– Should I be doing something? Yes or No? No? Don’t lie, just do it.
– Find your sweet spot (early morning, quiet times)
– Have to feel safe to create
– Self-shaming works to get going
– the “Cone of Silence” (a traffic cone outside the door means don’t interrupt)
– just getting started is the hardest part, momentum matters a lot
– other people – interacting with others, socializing and discussing to get creative flow going
– making opportunity (you have to create your own opportunities for creative work, this is the hard part!)
– get enough sleep (manage your needs and stress)
– long term investment in creative collaborative space

4. How do you work with other groups to determine backlog priority?

– User requirements gathering
– In Scrum, needs to be one person
– Use Lean to get stories up to customer

5. Writing stories for multiple audiences

– Have customer draw out what they want
– EPIC- can be broken into smaller stories
– Scott uses Pivotal Tracker to track
– stories change when the user is presented with a prototype (e.g. screen mockups)
– manage expectations
– the cost of coding is high (iterate the ideas first)
– customers tend to be unengaged at the ‘coding’ phase
story -> picture -> functionality

6. Getting kids interested in STEM
– Coder dojo
– Lego robotics
– Mind storms- Lego Robotics “building a robot”
– Make it fun and relevant
– Chemistry teacher makes it a little dangerous (teens like that)
– dangerous experiments (encourage their inner pyromaniac)
– Must be learner driven (if they don’t control their own engagement they won’t be interested)
– “We lack a ‘moonshot'”
—disagree, our moonshots aren’t as well known, and are less ‘personal’ than e.g. an astronaut
– unstructured?
– exciting
– visibility of the job?

7. What makes a good LeanCoffee topic?
– Relevant to participants
– Something someone is curious about
– How do I (??) so that I can (???)
– collecting topics (during the week note when you have good lean coffee topic thoughts)
– Ice Breakers
– Engagement
– Something people have a stake in
– “How do you…” (asking good journalism questions) Perhaps these tips apply: http://www.fastcompany.com/3003945/one-conversational-tool-will-make-you-better-absolutely-everything
– Good questions lead to good stories
– catharsis (but be careful of too much dumping)
– some good questions are based on relationships (asking for help with a problem, sharing thoughts, story telling)
– genuine (artificial topics don’t do well, contribute based on your own true interest in discussion)
– multiple P.O.V.s
– Sharing
– diversity
– a wide variety of styles, focuses, topic range,
– specific question vs broad prompt,
– opinion with commentary vs asking for help.

8. Best LinkedIn groups for Agile resources?

– LinkedIn is a little business-y (not that agile)

– Alicia is moderating this group: Agile Project Management (non-software)
– She is finding this question popping up across LinkedIn groups- Agile Alliance, Agile Project Management; will try to direct to Agile Project Management (non-software).
– Agile open NW
– Agile is a ‘toolkit’
– Variety
– “Scrumbut” (i.e. “we do Scrum, but….”)
– Lean Coffee!

 

May 8, 2013 (Justin’s table)

Posted on by

20130508

Topics that made the cut:

  1. Clipboard, Habit Maker, & Retro follow-through
    • Shared tools for helping changes from retrospectives stick
      1. A very large picture is put on the wall. Then covered with post-its that represent behavior changes to make (e.g., pair on a task). As team members complete the behavior change tasks, they remove the post-its. The first team member to guess what the image underneath is gets a prize.
      2. Behavior changes are put on a clipboard. A team member caries the clipboard and visits team members reminding them of the change. This is not a governance activity, but a reminder.
    • Justin points out that a group has to get to planning actions before they can follow through on them. Considered using a technique from above as “bait” to get a team to form actionable changes from a retrospective.
  2. Accelerated Learning
    • Framework for learning from Willem Larsen. Featured in the book-in-progress Name This Book.
    • 5 Items: Alive, Fluency, Signal, Focus & Setting.
    • If you take only one thing from the model, create learning environments that recognize people’s humanity.
    • Noted that the “environment” and setting for retrospectives can greatly affect their effectiveness.
  3. Water-SCRUM-fall, is it worth the pain?
    • When a program is structured very large and slow, with a staged release plan (e.g. in the first year, we’ll build the db…) but is to be run “agile” this causes pain for teams. What do to?
    • Team members tend to see activities such as iteration planning, backlog management, retrospectives, demos, etc. as “stupid” and “a waste of time”.
    • If you don’t have a purpose, it’s hard to know if you’re making
      progress toward a goal. Team may need to set its own sub-goals, if the business isn’t providing them.
    • Need to get the big program focussed on results. Outcomes, not output.
    • May come from fear of actually releasing. Business may not want the
      changes that would come from producing a result.
  4. Agile/Kanban as Organiz. Design
  5. Tricks for breaking out of ruts
    • I’m in a rut. How do you break out of ruts?
    • The Plateau Effect may help.
    • What about the 5 rules of Accelerated Learning?
    • Try getting others to see the same problem you see. Then you are not alone in working on the problem and not alone in the rut.
    • Ruts represent a conflict of desires. Boredom comes from prevention from doing what you want to do.
  6. How do you use Lean for your extra-work creative projects?
    • Talked a lot about Personal Kanban
      • Books: Personal Kanban, Factory of One, David Starr has written a book about it, featured in WSJ.
      • Tools: LeanKit, trello
      • Beware the tyranny of the list. Kanban does not remove this.
      • Differentiate between “holding” and “blocked” items.
      • Can try to sort tasks by size. Then when presenting with time to take on a task, grab one that fits the available time.
      • How about Family Kanban?
    • Briefly touched on family retrospectives.
  7. Merging two overlapping products and technology stacks
    • Merging (through acquisition) two products that overlap in both audience and functionality.
    • Anti-recommendation: bigwigs decide how people will work, ignoring realities. Instead, try to bring people doing the work together early and give them a chance to solve the problem from the engineering perspective. Create value teams.
    • What does success look like? What will failure look like?
    • Is there common understanding of the overlap? Figure out how to make the people excited about doing the work – technical challenges? how will it build their careers?
    • Recognize what’s been learned so far.
    • Focus on merging people over merging technology
    • What do the people stand to gain?

LeanCoffee through the lens of a single topic

Posted on by

LeanCoffee is off to a great start. We’ve moved to the amazing New Relic offices on the 28th floor downtown and the conversations have become as soaring as the view. Often New Relic employees showing up bleary eyed to work encounter a passionate discussion raging in their lunch room and wander near to see what’s got everyone so charged up before 8 in the morning.

LeanCoffee is great for sharing and learning. Its agenda-less nature lets the group determine the most interesting topic and spend the most time discussing them via democratic voting. Looking at a single topic from the last session, here’s what I leaned in just the first 10 minutes.

Fresh from ProductCamp this weekend, I was turning over the role of Product Owner in my head. At AgileOpen NW, I was surprised to hear knowing jabs at the role. In such an inclusive and supportive environment, it seemed out of place. Or perhaps I was just sensitive as that job is what I do for a living? Why are people so disappointed with their POs? I came across this attitude again while getting my Scrum Master certification. In the small class, the teacher was surprised to have a PO interested in taking it and over the course of the two days I heard many more snarky digs at the role. What gives?

So in an attempt to use the LeanCoffee format to tease out an answer, I suggested the topic “Product Owner faux pas”. It got the most votes and was the first topic of conversation. We ran through the first 6 minutes then two additional 2 minute sessions (10 minutes total). People were all too happy to share where they’ve seen POs fall down and I learned a lot.

After I briefly introduced the topic…
Diana suggested that while the role seemed like a good idea during the creation of Scrum, none of the architects had actually held the role.
I offered that the Scrum coach mentioned the PO is often not treated as part of the team.
And then around the table it went…
PO is the most reviled role in Scrum
POs often have many projects and aren’t available to the team as they should be
As engineers think ‘we just have to fix this PO’, ProductCamp showed that POs think they should fix engineers
Companies don’t make the PO role a priority
At what point does an ‘on-site customer’ lose their relevance
Upon mention of proactive backlog grooming and story estimation: Oh, I wish my PO would do that!
In just a few minutes I learned pain points from the perspective of teams and POs which can immediately help me be better in my job. That’s the beauty of LeanCoffee: lightning rounds and rapid idea exchange around highly interesting and relevant topics.

There was a lot more territory covered and in each an opportunity for learning and reflection. Some of my favorites:
New Relic’s customer service model of having their engineers rotate into a Support Hero role
Using the Pomodoro timer as a way to set expectations for office mates to allow for uninterrupted work flow
Creating a Rumor Control Board on the wall to allow for not only the validation and squashing of rumors, but also the frame that until validated by someone, a rumor is only a rumor.
Above all the session is infused with laughs and mutual support. It’s a great way to wake up: getting caffeinated with smart people and sharing unexpected ideas and war stories. I’ve always left richer than when I arrived.

 

Free Tickets for the next LeanCoffee are at Eventbrite