Category Archives: session notes

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

April 24th, 2013

Posted on by

IMG_4418

Topics that made the cut

  1. Product Owner Faux Pas
    • Product Owner, the most reviled role in Scrum
    • Part of the problem is that the PO role was designed by people who did not perform the role
    • At what point does an on-site customer lose their relevance?
    • Sometimes an organization fails to make PO duties a priority
  2. Mixing development and customer support
    • New Relic teams rotate “PS hero” duty. Incorporate it into planning. While on hero duty, the hero’s primary responsibility is to resolve PS work that is escalated.
    • Dev teams need to see PS problems and deal with them in order to learn more about their product, their customers, etc.
  3. Software “Soft” Skills
    • How do devs develop soft skills, such as
      • Looking to see if the problem they are facing has already been solved
      • Talking about software or development in non-technical language
      • Working in a team environment
    • Listening skills drive soft skill development
    • Would like to see academia teach team skills and TDD. Curriculums provide a major impediment to seeing this widely adopted in college/university.
    • So you’re a shy introvert who needs to learn to listen. Try staring at their shoes.
  4. Future of Education
    • How does self education fit into job prep?
    • How are sites like coursera, Kahn academy, etc changing education?
    • Some employers are dropping degree requirements
  5. Getting uninterrupted time to work
    • Most importantly, when you interact with people, you are training them on how to treat you. If you are responsive to interruption, you are training people to interrupt you.
    • Pomodoro Technique (http://en.wikipedia.org/wiki/Pomodoro_Technique) can be used to set boundries. Teach people to look at the timer and come back when you are done.
    • Pairing can be used to focus people and scare off interrupters, especially if you pair with someone who intimidates people.
    • Often, if you ask someone to wait even ten minutes, they won’t need work from you later
  6. Opportunities for Part Time Coaching/Mentoring in Portland
  7. What have you put on the wall that improved work?
    • Saved the world today counter to recognize individuals who respond to unforeseen problems
    • Rumor Control Board. The work environment was suffering from too many rumors. The Rumor Control Board was for posting rumors and official information and responses to them. A very significant benefit was that placing a rumor on the RCB labeled it as a “rumor” and lead people to take it less seriously.
    • Big Visible displays have a half-life. After a while, they lose their effectiveness or relevance and need to be reconsidered, less they become waste.
  8. Tell us about Product Camp
    • Disappointment with the structure.
      • Sessions were centered around presenters wanting to share a specific topic. (As opposed to facilitators who want to learn about a specific topic)
      • Participants reacted negatively to people choosing to leave a session
    • Some participants had seen an anti-product owner bias from developers at Agile Open Northwest. At Product Camp, they saw an anti-developer bias. “Well, we just have to fix the engineers.” Perhaps we shouldn’t solve our problems by getting someone else to change.

April 10th, 2013 (Trial Run)

Posted on by

photo

Topics that made the cut

  1. Other uses for Lean Coffee

    • Scott tried it for family meetings, but struggled to get participation from adolescents. Hypothetical suggestions included staff-meetings (which put a burden on managers to sell topics, instead of just announce them; but carried a risk of political power derailing the topics)

    • Talked about using Lean Coffee in other industries, which lead to talk about agile in other industries.

    • Dan has shared LC with his sister, who works in aviation. But she has yet to apply it.

  2. Being on a software team in a non-software company

    • Group talked about communicate gaps with stakeholders and sponsors. Most often, about unrealistic expectations that software be simple, easy and quick. Some stories were shared about the opposite, when stakeholders expected long, complicated cycles for what was a very small task.

    • Three Potato Day!

  3. The Phoenix Project

    • Talked about “The Phoenix Project” by Gene Kim, Kevin Behr and George Spafford. Only one of us had read it yet. Focused conversation about aligning development and IT work with business objectives. Talked about how this requires talking about the core business. Tech folks have to face a risk of talking outside of their domain (tech).

  4. Conway’s Law

    • Paraphrased as “organizations will build structures that conform to the communication patterns of the organization”.

    • Talked about aligning organizational structure and desired technical architecture.

  5. Remote work/collaboration

    • Talked about Marissa Mayer and Yahoo!

    • Patrick shared success stories about teams with remote devs and remote clients. Main obstacles were retrospectives.

    • Talked about using skype and shared desktops for remote pairing. Many had found that remote pairing resulted in more engaged pairs than on-site pairing.

    • Justin realized he’s against remote work because of the low levels of collaboration he sees in on-site work.

  6. Interviewing for a senior dev/Hiring, what to look for on both sides of the table

    • Talked about interview techniques, including “stress to applicant” and see how they perform. Rich impersonates angry, irrational customers.

    • Companies hire to fill gaps. Seek candidates that satisfy that gap.

    • Some candidates look for a gap between themselves and the job. Find the right thing to grow into.

    • Do we expect senior developers to have time for github, etc? Maybe they are too busy having a life.

    • Agreed that we’d expect senior folks to have figured out how to work forty hour weeks and go home.

  7. Suggestions for QA tools/QA in an agile environment/What could you test (automated) that you don’t yet test?

  8. Backlog Grooming: How often/Regather Requirements

    • Found a general need to have someone represent the customer on a day-to-day basis, as most customers don’t take on daily backlog maintenance.

    • Big backlogs need to be thrown out.

    • The relationships for a team/project determine who can add to the backlog. With high-trust and daily attention to the backlog from the PO, anyone can modify the backlog. In low-trust, restrict write access.