Engineering/Team Development Workshops/Day 1 notes

August 28-30, 2013

Day 1 Notes

Present: Tomasz Finc, Arthur Richards, Andrew Garrett, Benny Situ, Brandon Harris, Erik Bernhardson, Maryana Pinchuk, Matthias Mullie, May Tee-Galloway, Vibha Bamba, S Page, Toby Negrin, Gayle Young, Anna Stillwell (guest)

Partial attendance: Erik Moeller, Terry Chay, Howie Fung, Oliver Keyes, Jared Zimmerman, Praveena Maharaj

Welcome - Tomasz

Introductions: Erik B, Tomasz, Arthur, Maryana, Erik M, Jared, Matthias, Terry, May, Benny, S Page, Andrew Garret, Brandon Harris, Gayle, Praveena, Ana, Vibha, Toby (Howie, Oliver) Anna Stillwell - Works with Gayle

Ground Rules:

Bulleted list item
no laptops
no cell phones
work as teams
be timely
be open - open minding and open with each other
bring energy
emotions
on conversation at a time, feel free to ask questions as they arise (will move stuff to the parking lot if no time)
be mindful of chickens and pigs

The story of the chicken and the pig: (Arhtur and Tomasz). Committed vs. involved “Ham and eggs”

Pigs that are fully committed (directly working on project), vs, chickens who are only involved (stake holders).

Exercise: Goals, hopes, and concerns.

List on post-it the goals, hopes, and concerns and put them up:

Goals:

Launch
Get MVP definition: Minimum Viable Product. Achieves the minimum amount of value that has value to users.
Well defined roles, including community engagement: “We don’t have anyone whose job it is to engage the community”, there is a role and there is a team
Roadmap to first release (similar to MVP definition)
We all feel like one team as opposed to echo, flow
Understand cultural sticky-bits: Relevant from cultural lens to other parts of the organization
Viable schedule for release
Radical change in user behavior (Jared): The goal is to affect radical change in users
Develop a tool community likes: “What community?”

Hopes:

Launch
What we learn helps us organize how we work (Andrew): We’ve been very productive but sometimes don’t know what we do next.
Achieve really high velocity (Brandon): Same as Andrew. Lots of planning, design up front which jump starts things, but we’re getting to the point of what to do next
Improve visibility and co-ordination across teams
Spread of good practices (Gayle)
Jesus takes me home
Fired up team
Workflows provide framework for contracts between wiki and engineering
Love and teaminess

Concerns:

Launch
Waste of time (Brandon): this is my third time through this
Quiet people will be quiet, loud people will take over (Maryana): When quiet, get disengaged from process. People feel surly at the end. For people are quiet to get more comfortable talking.
Community acceptance (Maryana): Accept Flow, the team, etc. A group ha quit.
How to be community-informed (Terry):
Too complex (Jared): The project is complex. Not just talk pages
paralyzed by complexity (Jared): Our reaction to that project, get stuck into “the problem is so hard”
Jesus takes me home: both a hope and concern
part-time scrum master (S Page): First 6 months need full time. In new job, only 3 days a week (acceptance testing on features, documentation, QA on VE)
Torpedoed by community (S Page); Same as community acceptance

Schedule

Objective: Set expectations, underhand potential value of agile, understand scrum mechanics

Introduction
Agile review and deeper overview
Lunch
Intro to Scrum
Roles and personas
Daily retrospective

Understand Scrum artifacts and rituals

User stories
Lunch
Prioritization
Estimation
Scrum rituals
Daily retrospective

Define goals for release 1 and be prepared to start sprint 1

Agile planning overview
Mingle introduction
…

Success and Failure exercise

Success:

Structure for better group dynamics (Gayle): How to work out difference, how to move forward
We are on board with the plan (Jared)
2nd sprint is clear (S Page): Plausible that we get 1st sprint but real test is 2nd sprint
No one gets fired or quits (Gayle)
Increased practices for effectiveness (Gayle)
90% of MVP1 defined
I feel like the practices are helpful rather than tedious
Have a plan for the next 3 weeks and know who is doing what
Finishing a half day early
Getting into a well-understood rhythm (Erik): This is a beginning workshop and you’re not going to be fully understood. It’s going to take adaptation and learning.
Lose sleep tonight do overexcited brain
We lose ?? with what we learned during the training in product development

Failures:

Not learning (Gayle): Everything is a learning opportunity. Uptaking information
People check out mentally and physically: “Should we lock the door”
Being more confused about this project than when we started: e.g.
Being bored and checked out
second sprint is a message
chicken pox, ?? , strum and drang (storm and thunder): E3 training before
Someone gets fired
Continued lack of clarity about key processes
When I drag my feet into this room next morning

Agile review and deeper overview

Summarize workshop.

Difference between big A agile and little agile.

Agile manifesto: it’s an ethos: http://en.wikipedia.org/wiki/Agile_software_development

Discussion on co-location (#7 of 12 principles). Arthur is the scrum master and is not co-located.

Chinese character “Kaizen”: “Improvement” Make change. Constant continuous improvement (Toyota’s principle). With the intention of making life better. We can and should be continuously improving.

Agile is easy to get going yet hard to do well. Many reasons collude to make this so. Chief among them is that agile exposes the dirt people have been sweeping under the rug for years. Who wants to look at that? Yet we must. – Lyssa Adkins, Coaching Agile Teams

It highlights where teams are deficient, particularly in terms of ??

Turbulence is OK

Scrum Deep Dive (Arthur)

Some story on Mobile

It’s about the team. At the end of the day…

Agile teams … know that a well-funciton team of great individuals with mediocre tools will always outperform a dysfunctional team of mediocre individuals with great tools and processes – Mike Cohn, Agile Estimating and Planning

Roots of high performance team

commitment
focus
openness
respect
courage
humility

High performance characters

self-orgnaizing
empowered to make decisions
can solve any problem (if embrace roots of the tree)
Team success vs. success at any cost
Team owns its decisison and commitments
motivated by trust rather than fear
Consensus driven
Constant constructive disagreement

Fruits of a high performing team (tree analogy)

Faster results
Sustainable pace

…

Limiting the bus factor

There is no single wringable neck (simpsons photo). No blame game for team failure.

Final random thoughts

two pizzas (feed entire team with 2 extra large pizzas)
one team at a time (devote 100% to one team at a time, context switch between two teams, there is overhead to context switching)
skill share on team (like to see do this more on Mobile Web, limits bus factor)
Experimentation time (not old 20% time, unstructured self-directed approach to focus on stuff outside project, new features, scratch an itch. Give people 1 day every iteration (two weeks) to do it).

So, if we’re self-organizing… What about managers/directors?

Bigger picture issue. Instead of doing the day-to-day with engineers at the quarterly and annual level. What’s the long term horizon here.

Goal setting relative to that: annual, quarterly goals, etc.
Resourcing
Dance floor and balcony: Look from the balcony. See where the process may be breaking down from the balcony and offer suggestions. (beta site and stable site, dispute between PMs and engineers over perception of beta site)

Roles: Who’s who on the flow team

Comment: Topic of complexity has come very often. We should go through each roles and their role in managing complexity. Parking Lot

Product owner (Maryana): As explained at Wikimania. People fight on talk page and Product owner is the closer admin. In addition, get to a place where you all condense on decision, inform you guys based on community feedback, research, etc. Make sure all decisions we make as a team are as well informed as possible. When everyone says they’re done, confirm that they’re done. Challenge: Managing conflict between different visions
Scrummaster (S Page): Facilitate meetings, daily standup? and retrospective?, sprint-planning, using tools to establish of teams, working on un-blocking things (look to tech lead), establish how group can make progress. Leading to Maryana getting happy. Challenge: newness at job and time available. Comment: Sharing out externally outside group the philosophy, status
Developer (Andrew): To write code. To turn what’s been decided into an implementation. Consultation and discussion on architectures, directions, things we need to leave open, sometimes the code needs to reflect that.
Developer (Benny): Goal is to specification into the code. Work with the PM on how to do product. Sometime to get feedback and see.
Developer (Matthias): Just make everything work… well (enough). Consists of coding and communicating ideas and concerns
Developer (Erik B): Take what they want into what they get.
Developer (Vacancy): new hire. Challenge: Growing complexity and hacks that won’t make it. A lot of functionality that is complexity. To start on something a few weeks ago, in 6 months how many things will we do that are expedient not because they fit in the overall architecture. Global customizations/Workflow sounds great but difficult to get right. Concern not that it won’t work, but won’t work the way everyone envisions and be a bunch of hacks, and grow out of hand. Comments: distinction between developer and what maryana says. Everyone participates
Tech Lead (Erik B): Take an extra day or two to figure what we move forward with. Final software architectural decisions? I suppose but don’t like to tell you how to do it. In a self-organizing team no one person, but takes responsibility in shaping and guiding. What is your role to product and UX? Co-ordination and the concepts involved, and be a liaisons to developers and those. Where they are trying to goal. Challenges: Same as development, complex thing, it’s really scary. Comments: Being an arbitrary for any given development issue, and deciding continuum form one-off to architectural solution, and tech lead has to decide who does an unpopular piece. Our tech lead Jon is responsible for liaising between our team and operations (goes to biweekly ops meetings and brings back information). Have started with mobile and VE, had him added to biweekly ops but hasn’t started
UX/UI designer (Brandon): Challenges: It’s a freaking complex problem and there is so much give-take between needs of different customers, the people we are designing it for. If look at one part, it will create failure. There are many moving parts. There are many dials and they have far-reaching impact.
Visual designer (May): Challenge: we think it’s easy for other people, but it’s hard for other kinds of humans to take it easy. To translate what we want to what users understand. Comment: Our understanding vs. the community’s understand
UX/UI designer (Vibha): Challenges: Sometimes being inspired as a team (as a Features team). Hard to come something that is optimal and is isn’t tradition, we go with the expected too much. Our work speaks to small amounts of innovation and creativity.
Design (Jared): Initially Brandon and Vibha are main points of contact, as we go through each sprint, May will be more involved. Work across the design team across every project. No one designer on flow solely. There is not necessary the need for full-time design. Brandon will be the single point of contact. Comment (Maryana): In the roots or the fruit the 50/50 split between projects is a challenge, one of the things we can’t sweep under the rug is design is committed to multiple projects: how do we make designers feel part of the team and have a stake in the thing they’re building?
Data analyst: Comment (Toby): End support should be considered and work a lot in the design team. Data analysts should be considered even if it a shared resource
QA analyst: Who is the team. QA process will have to split among several people (Maryana and Brandon) also (S) among his many responsibilities along with (Erik). Comments (Erik): we have a shallow product right now with Chris and Zelko, and support has been spotty, mobile has had it, VE needs it (it’s in production and being used), Flow is in early development where it doesn't need dedicated QA support, may have contract resources for automated process etc. Comment (tomasz): Important isn't to assign people, but know who it is coming to it so it doesn't get ignored. Comment (Erik): ex. Michelle’s role in the team is not transferable, a lot of domain expertise. Comment (Tomasz): Agile does well surfacing that this is a problem.
Business analysts (Howie): What the BA role is, compare to the Community liaison role, and then Oliver jumps in. The BA role is the role with the primary responsibility to help team understand of community processes and complexities around things, ex. here are the 50 gazillion templates community manages the deletion process, help the team understand what those processes are, so that when developing features so they can take these things into account on how community does things. Ex for flow: will Bot support. Support Maryana to understand the universe of bots and prioritize which bots need to support. Ex: one big spreadsheet with all bots how they interact with talk page, who maintains them, contact person, API documentation for them. Comment (Arthur): Missing the inward team focus. Acting as a translator for different points of cross-functional team. IN FR-tech we had a dedicated person (James Alexander). Taking the product vision as defined by Zach and turning it into user-stories that were understandable by product, QA, and engineers. Comments (Toby): Nuance with platforms to interact with a number of people in Data. Comments (Maryana): challenge is who gets to speak for the community? and which community? Glad we’re operating on consensus basis.
Business analyst (Oliver): Can’t think of anything specifically. Sort of the role of the “Lord of the Gaps” Is there a question we don’t know the answer to, the BA needs to find the answer. Also, help when PRoduct Manager is busy. The line of declinations is likely to be “who has the hours?” There is a blurry line between PM and BA that has an overlapping sets of activities. Challenges: Off the top of my head, defining it. It’s a very new role and kind of weird role, and much like with community liaison we say what we like to see in advance and 6 months later we see it’s very different. We don’t know what the main difficulties are yet.
Community liaison (Quidity/Nick Wilson): (Howie): The community liaison role is primarily related to interfacing with community. Makes sure mail gets passed between development team and editor community. IN bots example would be to work with the community. Ex. What bots are causing you problems or what the community thinks is important bots to support? This gets funneled into the BA’s list of 100 bots. Not necessary concerned with universe of things that we need to cover. Thinking is to have Nick Wilson. Defining role (oliver): summarize what Foundation is using and translate it to community and take the community and translate it to what the foundation roles. Foundation babelfish. Challenge: 1) not going crazy (need to look at the pressures and how it works so they aren’t covered in blood and screaming), 2) Avoid someone that has all the responsibility and no voice. Identified after echo, we need to invite liaison into conversation, not because they have useful perspective, but also because they carry the can and explain how this is made.

Scrum Cycle (Arthur)

Scrum cycle At its base the idea in a scrum cycle is to make it possible for team to continue at sustained pace indefinitely. But to spread it out over the course of a long term (not work weekends) Components: 1. Iteration or Sprint 2. Release Product Backlog → Sprint Backlog -(iterate back 2 weeks, forward daily standup) → potentially shippable product increment Time box: When you have a fixed start and end time and don’t change end time. Used as a way to prioritize, so you don’t end burning out (endless meeting). Sprint: aka iteration. It is a time box’d iteration. Set period of time where team completes a pre-defined body of work, that snakes a potentially shippable product increment and is unified by a sprint goal. Set period of time: It’s a time box 1–4 weeks, factor in release duration, consistency is crucial (stick with the same sprint length). pre-defined body of work:

team commits to completing a set of user stories
story definitions and acceptance criteria are fixed (once the sprint has begun). If those things change then commitment has changed. You can concentrate on getting shit done and don’t have to worry about the rug being pulled underneath you.
Sprint scope is fixed:
Once a sprint has begun, no work is added
Changes in priority are ok as long as the work itself does not change.

Caveat: these are rules, not laws. Losing 2 weeks to a changing thing is not a big deal. There is a concept called: “abnormal sprint termination” add it [a parking lot] potentially shippable product increment

A set of good-enough quality work that is potentially shippable to end-users
A state of confidence

sprint goal

describe the purpose and value of a sprint (e.g. enable talk pages in the mobile inter ace’
defines the selected work for a sprint
is defined by the product owner
is agreed to by the team

Use a pithy statement: Introduced by Vibha to explain to her mom. Planning and development overlap requirements, design, code, test (overlap) Rather that dining all one thing at a time,… scrum teams do a little of everything all the time. Release 1. A combination of features that when packaged together make for a coherent deliverable to end users 2. A version of product that is promoted for use or ??. Release represent the ?? of value delivery 3. adapted from Essential Scrum by Ken Rubin. Release frequency

can be consistent or variable
establishing rhythm is valuable
regularity of releases should impact decisions about sprint length

It is less important to be consistent with than sprint length, this depends on goals of team. It is nice for rhythm. Duration of releases should have impact on duration of sprints. Mobile web does it different

“Release” software 2x per iteration
(puts a box around period of time): Use the word ‘release’ to refer to a fixed period of time - one quarter. ex. 6000 contriver goals
Define a set of goals for the quarter to guide our iterations

It is a great way to give your work a clear direction. And unifies concept to know if you are doing the right thing. Scrum helps us cope with… (Tomasz) Share why we do SCRUM.

difficult of predicting the future: GANTT, “Accept…”, do it iteratively
inevitability of change: traditional cost, learn and adapt quickly,
risks involved with any project: haiton??, deal with failure early,
difficulty of delivery: Releases, build in quality
getting lost in the details: avoid perfectionism
sustainability: sustainable pace, the team, low startup cost for new team

GANTT. It’s very rigid: It structures your work to block on other work; Doesn't allows course correction; takes a lot of effort to create this.

“Accept that you won’t get it right up-front” We’ve seen this in Mobile Web and Fundraising. We start at this point and we want to raise this money. But Fundraiser responds to user-habits which change as quickly as possible and success was geared around ability to change.

Do it iteratively: it’s easy to predict things that are trivial but impossible to predict far in advance, so you want to do small iterations to do accurate estimation and reset estimates at the end of each interval.

Traditional Cost over time: Cost over time increases. To introduce thing you haven’t thought about. So scrum introduces sprints to reset to reduce the cost over time. So it rights the bottom of the cost curve multiple times and reduces the overall cost.

Learn and adapt quickly: At the end of each release/sprint, feedback is critical. Build → Feedback → Inspect → Adapt → (repeat). Mobile web releases every week so gets a ton of feedback.

HaiTon??: “Remember: Just enough, just in time!” Save work to the last possible moment. Craft work to the environment.

Deal with risk and failure early: tackle risky items sooner, keep cost of failure low, learn from failure quickly, failure is measurable. (If we find out that we missed the mark, that’s okay.). Story about selfless in Wikimedia commons. They didn’t polish it too much so they were able to roll back without much cost. We want to measure failure so that it is a bounded cost: know how much time. Bot literally really but figurative. the key point it to know what success looks like and what failure looks like

Releases: Release go out every week for mobile web. At the end of the day an iteration should have a releasable work unit that the customer can test. The longer you wait, the higher the cost of the failure.

Build in Quality: QA every step of the way, and don’t test only at the end. When stories are drafted, QA is at the table, when development, and when setting acceptance criteria. Keep thinking how the team will grapple with it. This relates to keeping the cost of change really low. Imagine if you can capture that bug before the software is even written, when you are defining things.

avoid perfectionism: The tough thing about 100% is it differs to different thing. Is something done and have we gone far enough. To deal with this: 1) Acceptance criteria (later) get this out help define done without having to talk to someone else. 2) There are timeboxes. This puts a cost on the team. We do this on mobile web: add concepts of slights?? where you don’t know how long it’ll take so you just work on it for X hours.

sustainable pace: consistent velocity, iterations, remove context switching. Iteration allows resetting everything every 2 weeks to allow radical course correction and renews energy every time. Where context switching is expensive is where work they do ends up affecting velocity. Scrum time boxing allows that to be deferred to the backlog for a future sprint (allow channel where they can introduce new work but without affect current sprint backlog).

the team: The team’s health is important and distribute skills aggressively as possible for those thing. If person decides to read, the team should not fall apart, just a matter of figuring out how the roles are redistributed.

Low startup cost for new team members: predictable rituals (estimation meetings, stand ups, etc.), documented roles (where course correction occurs, its important to write those down and not assume that this comes, put it on wiki and be honest with self and team, and know what people are not responsible for), actionable work (make sure stories that are introduce that developers can take action on). Ex. Ryan Kaldari joining mobile team. The cycle is already there and they can plug in easily.

User roles & Personas … out … Retrospective day 1: What worked well?

writing on cards as a team
talking about specific use cases
got some shit done
naming things (people, etc. ex. in roles and responsibility). Putting names to roles.
good distribution of sitting down time and break time
…

What didn't?

no laptop/cellphone
agile review wasn't as useful for everyone
not everyone is engaged
too much inside baseball (ANI, overnighters, etc.)
the post-its

What still puzzles you?

a lot of let’s hold off until later, without confidence that later can happen (Jared, Brandon)
demystifying the inside baseball stuff (ANI, etc) that is important to the project that demands a lot more expertise (S)
in game design, you have different users. It’s designed for beginners and expert uses. Got to have something for everyone. The scope of the MVP and duration of the MVP is puzzling people. What does it mean to be thinking about new users (pages for new users? features for new users?) we use power users because they use all the features. The thing that ew users have that power users don’t are ease-of-use.
scarcity mentality needs to be there (Terry)

Parking Lot stuff

how do different roles manage complexity (Howie)
QA?!: (Big discussion to have. Outside scope of 3 day session. If split roles, then context switching. Maybe assign an owner to this: S Page, put names next to bulletpoints and see if it’s too big)
Product owner & Business Analyst: (need oliver for conversation. Maryana is committed to make sure the conversation happens)
How to stop a sprint (Need a giant red button. That should happen when it is obvious things are going very wrong. Something is going totally sideways. Product Owner has the authority.)
Motorola Razer trolling
Bringing inside baseball outside (sustainability on team, can bring on someone new to the team. The specialized roles or Single point of failure is a dangerous thing for the team. Key: Figure how to code with this. Maryana will own: need more inspiration. Need a sprint-by-sprint that is understandable by everyone on the team. There are other places where they have people talk and they have to suppress comments.)

These three are the same: discuss later (Friday).

where to roll out? exclusion of new users
“customer” before release of MVP
release

Team discussion: “Formal Fridays” This Friday.