Author Archives: Justin Redd

June 5th, 2013

Posted on by
photo
I’d like to extend a giant “thank you” to Colin for writing up notes this time!
Topics that Made the cut:
  1. Elitism
    • Hiring great people, focuses on ‘top performers’ creates a community of elitism
    • Creates a “Don’t embarrass us” culture
    • Seems unhealthy
    • Concerns
      • Long term not a good strategy
      • Not a healthy culture
    • if you have a culture of learning in addition to having really bright people
    • what keeps people aligned? pulling in the same direction? vs ego competition
    • keeping the focus on having to produce something. It’s not how smart you are, it’s what you produce
  2. Building good communication between dev (product) people and sales people
    • Challenges we face between biz dev and product people
    • In an agency you are courting many clients. Sales team had different goals and focuses and desired outcomes. because of that sales and biz dev had to address different clients based on those wants. if they don’t communicate the promises made are much larger than the product people can produce
    • its easy to make promises for other people
    • product company vs agency
      • product management main problem is how to communicate effectively with sales
    • Has to come from a strong vision, pushing hard on exec team to hone vision and buy-in, if not, every request will pull you in a different direction
    • Taking sales managers out to lunch all the time
    • We’re all people! let them know you’re a person too.
    • Engage early and often. Constant communication (not ‘cliche’ communicating)
    • Sometimes issues with sales incentives. The incentives don’t align with the vision, product. Sales compensation is sometimes kept way too secret.
  3. Play
    • Structured play – e.g. lean coffee feels like play
    • Live in a culture to teach them “play time, and that’s not serious time” – Never stop playing!
    • Play is engaging
    • Language does matter, (corporate culture) meetings and rules, here is a process – “I hate the word process”
    • Time spent playing with kids is amazing for me too, ideas, flow
    • Certain amount of play that you encourage. Culture of environment, casual environment, room to play
    • Play is learning
    • Anyone been in an environment where play is explicitly part of the culture
      • Youtube example, playground in mid building (slide etc), Google office similar (slide)
      • One of the things we did, shuffleboard table, just decided to do a tournament. When I participated it was easy, relaxing, didn’t think about relationship building, it just happened
    • Work play into structure of what you do, but also just take a break. Be careful, don’t make this an obligation, a ‘play program’ doesn’t work. It’s not play if you are forced.
    • I really like intertwining the two, happier when they flow together. The work is play, the play is work.
    • Really important method of non formal communication. Finding where people are, supporting what they do, and communicating.’breaking break’ I tried playing cards and pingpong, it was the best way to discuss challenges, connecting with people
    • Play in a corporate culture is important, focused group activities, but also individual play, creating a culture that makes it ok to take an hour break to be more productive, or coming in late etc.
  4. “My team overcommits!”
    • My dept is on a new program, trying to learn scrum. I’m a team member, watching every iteration committing to about 150% too much, repeated every iteration. Other teams working overtime to ‘fix it’. Why aren’t we communicating clearly about what we can do?
    • As a PM I would rather have you under commit, and hit that so I know what you can do.
    • For us we went through the same thing, most important thing was driving home commitment isn’t “lets try to do a whole bunch” it’s about committing to what you can do. It’s ok to building extra QA, or unknowns, add buffer.
    • I started at a new company about 8 months ago. Trying to get people to commit to less. Trying to let go a bit. If you have the same velocity for a while maybe you aren’t pushing yourself enough.
    • Estimating is an important part of the process, comes with failure early on. You use the history to figure out what you can do. Actually rewarding committing correctly.
    • Business being able to plan for sure.
    • A place I worked at in the past. Struggled with this, velocity, key meeting “We don’t care that you do a lot, we care that you do what you say will do.” team eval on making commitments. After a few months it became a cultural team.
    • The way I was taught was to learn to estimate better. Track metrics.
    • Story points are set by the product owner. (Key scrum violation). Product owner likes to set stretch goals, gets in the way.
  5. Safe space
    • What makes a space safe? how do you do that?
    • All I look at is people. Other people care about space explicitly.
    • Is it a place where people can voice concerns? e.g. gender balance in tech. Lots of interesting men I could invite, I just didn’t.
    • If this is the culture you want, go after it. Commit.
    • Safe space, on the onus of the leadership to establish communication. How transparent can you get?
    • If you don’t feel like the environment has the tools to make meaningful change. How far can I go as a leader if I can’t even voice my opinion? How democratic can we get?
    • Both interpersonal or being able to raise your hand.
    • How do leaders respond to things they don’t like?
      • At sprint reviews, CTO gets really upset when things weren’t done, pushing on metrics, really focused people on finding a way to say they were done when they weren’t actually done, affected clarity.
      • Are you encouraging people to say it’s ok when it isn’t.
    • A culture to fail quickly. Failure is ok. You get what you measure.
    • Never seen a place where “all” truths are ok. But maybe “enough” truths are ok.
  6. Shared calendaring
    • How do people deal with? Family, across devices?
    • Google calendar, when my wife is on the computer and using google calendar it was great. Commitments, babysitting, etc. Calendar putting paper on the fridge.
    • Big issue – physical location, vs ‘one true representation’
    • Issues with syncing, work calendar vs personal
    • Getting everyone to agree on how this works.
    • Equality of access, everyone needs similar tools (laptop, smartphones..)
  7. Onboarding new group members
    • New members aren’t productive, they don’t understand the process, they are afraid.
    • Seems like on boarding starts with institutional knowledge.
    • new hire checklist, happens on first day. go to this wiki page, read it
    • In lean startup e.g. culture of teaching people that’s it’s ok to fail early. e.g. first day you are coding something. If it’s bad enough where you can break it, that’s on us, we need a better process.
      • Your first day you do something productive, e.g. check in production code. (usually small, e.g. fix a typo. Scary, exciting)
    • You are hired for a year no matter what you do! (they don’t do that any more, Toyota)
    • Gave you the keys to work with the whole system on the first day. (e.g. could ruin everything)
    • Non software onboardings:
      • coffee shop in bend. Onboarding is 2 week training. Tasting, making, art, etc. Indoctrination.
      • New seasons article, read told for first two weeks, wander around the store and help out. After that they go through disorientation. “explain how this works” teach them how they were wrong. VP level, doing every job to appreciate.
      • Manager at perl REI – does every job in the store frequently.
    • Curious about – What is the real problem? Is it too long to integrate?  – People are afraid when they start, they don’t know, they are afraid to do something wrong, look foolish
    • Connect with culture, BoK (knowledge base)
    • Different schools, school context, different ways of bringing people in. QA, buddies.
    • Buddy system is good, but being buddy has to be important (not just a distraction), software: Pair programming in an XP shop, important. First job is to remind buddy to give back when they are the buddy.
  8. Competition vs Cooperation (and excellence)
    • What does management incentivize? rewarding teams encourages cooperation.
    • Friendly competition – different than ‘have to make the other person lose’
    • Layoffs – hugely competitive
    • beyond cooperation – collaboration – one goal everyone is moving toward
    • Incentives in place drive how people operate
    • Edward Debono – Surpetition (book)
    • Alfie Kohn – In Control (book – education context)
    • “software is a team sport” but my team is competing, the company is competing
    • food cart example, ‘pods’ draw more customers
    • bias at this table? seeking balance, competition is the default

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?

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.