Engineering/Team Development Workshops/Day 3 notes

August 28-30, 2013

Day 3 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, Gayle Young, Anna Stillwell (guest) Partial attendance: Erik Moeller, Terry Chay, Jared Zimmerman

Flow Team Agile Workshop Third course ground rules for no laptops will be slightly changed later today Objective: Define goals for release 1 and be prepared to start sprint 1

Release planning:
Define MVP
? the cards for MVP
? Estimate stories
Lunch
?

Release Planning

Set goals for grouping of iterations that make up the release. For the first release you have to define the MVP. Experience from mobile planning: Everyone has a voice!

1. Product: set goals for release (Story from mobile, about annual goal and quarterly goal about up loaders)

2. Whole team: brainstorm story ideas (PM usually add stuff heard about)

3. Whole team: assign high-level priority / moscow (then do what we do yesterday as a team)

4. Engineers: Estimate engineering effort

5. Engineers: Identify risks & inter-dependencies (sometimes have to co-ordinate of team members from other depts.)

6. Product: refine story ideas into user stories (dump it into mingle into backlog, add acceptance criteria, etc)

7. Product: Priorities

Stress the whole team is involved. First release is the MVP Mobile has 3 tracks for features in any given release:

alpha: free-for-all: developer & community sandbox (ex. community member added categories to alpha) some come from experimentation time, stuff dies in alpha
beta: more mature features, may soon be ready for primetime. (there were a lot of users in beta so they added alpha and decided beta had to be more stable) (things never die in alpha) (200k)
stable: full production site, live for all users.

Flow is starting for 2 tracks (for now):

alpha: release to test environment (Labs)
beta: release to subset of Wikipedia (select WikiProject discussion pages) [this is subset, but it’s a microcosm of it, it’s a little micro wikipedia like the early days, they have real names attached to them: project coordinators, and looking for new tools to use.]

Other example: VisualEditor has experimental features. Have those features selectable to beta mode. Maybe Flow, this will happen. It is true the challenge is you are replacing stuff, but you can replace it gradually.

Inspiration

Every release planning, say things that are inspirational. (Discussion of Beta Features (on Desktop) mode.)

Struggling with something Vibha said the first day, How do I feel inspired to do this thing when people don’t seem real people? “IT feels like we’re writing enterprise software.” I am really excited on working on Flow because I love Wikipedia and want more Wikipedians. The tension is between openness vs. health. What our jobs are at the Foundation we've been responding to a call for board openness (board resolution), since 2006 we've been closing up, being harder to use, workflows people can’t participating. Our job is to start correcting that through any means necessary. But, there are costs to openness. We know this because we've tried to it (ex. Mobile web - upload button and found a lot of uploads are not good; AFT - we wanted to encourage readers to participate, what we saw we got a lot of people but a lot wasn't useful, the readers were talking but they didn't understand how Wikipedia worked, they weren't there; ). In addition to that someone had to do something about the stuff being created, and the community is really tiny and not paid staff members. When we flood them with crap, they get mad at us. If we don’t give them tools to deal with it (their tools right now are brittle, self-created), don’t have resources to create stuff that solves problems for them…

6–7 years that comments becomes a thing on Internet. Remember the first day that I did that on NYT. Thought we’d see some brilliant minds. "FIRST POST!" "Jake is queer, Kylre rules", and truthers, etc. Remember amazing potential that fizzled. They dealt with it by locking everything down, or they paid staff to deal with stuff. What you’re seeing is a meticulously curated discussion: karma points, paid, etc. It’s a lot of software and money being spent to solve that problem. We don’t have the luxury to do that. We also have a community that has formed in 10+ years that is incredibly passionate about the project. You can’t roll out a karma point system, and don’t have the resources to extract that data. What we can do, we can take this existing set of users, and empower them with actual software that does those things. For me, that is going to be how this project lives or dies. We are creating the balance between openness (a giant reply button everywhere). But we don’t know what’s going to happen (10,000 penis drug commercials?). We have to build it, and the tools to make it a healthy system. Does that get you excited about building tools for suppressing inappropriate content? (There are already many things that don’t resemble discussions on the web: concrete outcomes, workflows, no “flag” button–nothing where you can just remove things.) (What this does for new users? Initially, it’s a discussion system that’s usable by human beings. Which is a start. Most of the work is not that because that’s a solved problem. The rest is all the paperwork to do that and also succeed. The draw for new users will be the interface stuff; but we have to add these other features.) (Does it make sense to say the second release: adding to teahouse? A big world for a billion users and we are building a blog that reaches down to them. The answer is the second one is for the ones.… Teahouse is not for –1 or 0–10, it’s for people who made some edits.) If the reason we are doing agile is to keep the cost of change low. The most likely source of change is from the existing community. they’re the biggest risk is they reject software. Unfortunately this means the group are the people that post the biggest risk.… It’s also a great opportunity because they will demand it… and then we just sit back and let the money role in. The most interesting cultural problem is the fact that people can do something. If someone says, “you’re a huge idiot bitch, but …” I’m supposed to remove the first, but keep the second. Define MVP Go to Mingle - Flow > Team favorites (right) > Release Planning https://mingle.corp.wikimedia.org/projects/flow/cards?favorite_id=1077&view=Release+Planning Concentrate on framework for having discussion: #79, #113 MVP Release Goal: Public-facing release where users will interact on a production site (enwiki projects most likely) Erik: to go out to enwiki, there are multiple ways to do this. Are we targeting all users on enwiki or a tester population? Brandon: Argue for larger MVP, because it can’t be sold as viable unless it’s obviates and exceeds from the beginning, it won’t sell. Maryana: It needs to do the basic thing. There is a chunk of work necessary to make it work; and a chunk of work to making it work awesome. Regardless, the first have to do. ? ?

Summary

list of links
list of books

Retrospective What worked well?

today worked well because less abstract. We got our teeth into things. And you can actually see how the stuff you learned in the past two days (a bit abstract) was useful
compared to Thoughtworks this is head and shoulders above (Brandon). clapping. It was better: was focused, on an agenda, you know us and we know you (we know our shared culture and have shared context), we know what we want to get out of this and you helped us get there. Ex. With Page Curation they said this is all going to thrown away. [the original idea with Erik coming to us and saying we want to support other teams. We could do Thoughtworks but we want people who know the practical application of it].
we seem to be doing Okay on some of these processes. I have the feeling we can do some of the stuff on our own and fumble to doing all our own. We have an improvement in the process. The trajectory is upwards. We’ll fake it from now
Estimation went way better today. And yesterday we got 10–15 minutes in and we said no it’s not working out. Good pivot.
It’s clever when you are agile training in an agile way.
Actually have an MVP.
We did unearth of actionable work: e.g. edit conflict treatments, etc. that we otherwise may have been months until we took action

What didn't?

Release planning. Things got a little derailed. Lost focused, got derailed on implementation detail
It would be better to have improve the cards a bit before. It felt a number of people were waiting around for other people to do things.
There is an engineering-centric atmosphere. I don’t know how we can do this, but felt design was disconnected, esp. today. Agile as a process is geared toward engineers. It’s not a process that’s made for designers. And we have to think of ways to make it more designer friendly. Mingle while it’s useful tool, people who like interfaces hate Mingle.

What still puzzles you?

Still felt when we went to estimation, we came up with stories that were brainstormed… part of the problem is this has to be done synchronously. We didn’t have the time for the BA, etc. to hammer out the proper acceptance criteria. There was a lot of pre-work if we weren’t doing this synchronously to prepare for it. [Arthur: one of the purposes was to surface that; Tomasz: Mobile web ran into it a lot, and worked out so a triangle of 3 did it before the engineers: tech lead, PM, UX designer]
I am still puzzled how to interact with the designers with part time. Will they put a flag on it “needs design”??

Parking Lot

How do different roles managing complexity? (Maryana: we’ve solved it through the course of this training. AndrewG: the answer to that in engineering is discipline)
Beta Experiments (Erik Bernhardson). That conversation was talking past one another. You can use beta experiments to hide thing. And Discussion system that’s on or off. And most people eventually figured that on/off is binary but different aspects (visual editor) can be experiments.
Where to roll out? Exclusion of new users/customer before release MVP/Release. This is all stuff we did today. The goal has answered the question of where (open question on additional places). This doesn’t need an owner, part of conversation.
“needs design” (Jared)? Jared and Brandon are saying difference. On mobile web sometimes we work together: grab a designer and an engineer. In the past we had big meetings. We can try out different thing. Or do an ad hoc rule of 3, etc.
data involvement? We didn’t write any user stories for data. Flow is tricky to measure. We can do qualitative instead of raw numbers. We can run statistics before and after flow? Rate of thanks/rate of conversation? After MVP there may be a lot of analytics to do a lot of stuff: do they use VE more/less, do people get blocked, do conversations go long, how long suppress topics visible. Dario as the senior researcher in the foundation. (Maryana will own to data)
community involvement? blah.