2016-02-13 Product Meeting, Extended Team

Present: Robert F, Philip E, Pranav S., Tilmann B., Matthias L., Bodhi N., Manuel W., Martin S., Beata G., Kirstin S., Manuele C.

Notary/ies: Matthias L.

Location: Nürnberg, Kirstins Flat

Outcomes:

• We work in small teams, 2-3 people, preferably in person.

• We write the spec incrementally. Most important parts first.

• Design can mostly work on complete drafts of the website, not on seperated steps.

• Proposal: have epic cards to see which people are working on which task.

• Core person to identify tasks and meet with people from design and dev

• No decision in heavy vs light weight specification process 
  • Explicit and extensive specification helps bringing people on board (Use case diagrams). Diagrams should reach a high standard in order to be useful.
  • Informal meetings are good to work on certain parts of the product (e.g. coordination between Design and Frontend, as well as Frontend and Backend)

• • Developers might not understand Use Case Diagrams
  • Non-devs need written specification to contribute to the product

• We should take care that we do not copy foodsharing, instead fulfill the needs of most foodsharing users

• Open-source projects consist of few tech founders and they gather a passionate team

[Meeting begins: 16:08]

Expectations:

(Philip) Listen and understand

(Pranav) same as Philip

(Tilmann) Clarify on the workflow and discuss open questions from last meeting

(Matthias)

(Bodhi) Catch-up since Malo, order of tasks

(Manuel) Clarity, how team fits together

(Martin) See how can bring spec to virtual paper and how we can improve

(Beata) To see what the other groups are doing

(Kirstin) See where the group wants to improve, 

(Robert) From PR, getting to know more about the actual product

(Manuele) Continue from last time, how SCRUM/Agile is working for us, see the time plan until Rotterdam

Questions:

Questions that came up during the meeting:

• How can we split the specification to have smaller parts to work on?

• Feature Sets

• Easy for the IT to split into Dev-related tasks

• How can we publish our workflow, in order to integrate newcomers?

• How many people do we want in the product team, how do we integrate new persons?

• How do we keep deadlines and set times? How do we maintain to stay on track of our tasks? 

• How can we make sure that everybody in the Design team stays up-to-date?

• Who do I need to ask for questions about the product?

• Are there clear responsibilities of people for specific things? (Design, Dev, Functions of platform)

Questions from last meeting & wiki

• How can we make sure that everybody in the Product team stays up-to-date? 

• MW: Have key people nominated by the group who then share with the smaller teams in time of need. I strongly believe that not everyone needs to know everything. but only at the time of need gets the information from their key person on their team. 

• Who is working together with Manuele to create mock-ups which are in line with the specification?

• MW: Martin? and Vinicio and me? 

• Where does the product team get its input from?

• MW: Brainstorming, users and research on Foodsharing.de and possibly some user interviews (UX shared on SurveyMonkey) and then shared with the team

• Who is responsible for evaluating the wiki comments? (Who integrates the comments and removes them?)

• Should we use the konsensieren.eu platform for specification decisions? If yes, in which cases?

Minutes

(Expectations given)

(Questions raised)

Manuele: Is the current workflow the best/most efficient? It would be better if someone sits for me for 30 minutes instead of me reading 10 hours the wiki to get the state of the product for design. Same for slack, it's good for immediate communication but not for discussion or information spreading. I would like to rethink this decisions so we can change what not works.

Manuel: It is important to have individuals as responsiblees for some things. Scheduling: People in between other things should publish when they are available so tasks can be better scheduled (e.g. when we are apart, to maintain a continuity).

Meta: Shouldn't we first prioritize questions? Do we want to answer all questions today in the meeting?

Tilmann: Not sure if we can answer all of them. Prioritize to answer the most pressing first. 

(-> Everybody has 5 Xses to put in front of the question, starting column shows priorization. Questions reordered.)

How can we split the specification to have smaller parts to work on?

Tilmann: What are the criteria? Parts should have meaning for the product so they are useful to the user on their own.

Martin: My idea already was that (we started grouping spec in feature sets that are hopefully already in line with implementation tasks) dev and design takes a feature set and try to implement it.

How did you decide what goes together? -> just what felt like

(Who makes the wireframe?)

Tilmann: Requirement for featuresets is dev + design should be able to do something with it. So it needs to include visible or interactable elements to be not too development centric

Matthias: What about features that only change behaviour, not visibility/interaction?

Tilmann: Not sure.

Kirstin: We are still talking about spec, not tasks. Those have to be derived from the spec anyway.

Manuel: We anyway have our own trello board for design

Tilmann: I just wanted to know how the people from the other groups can know if a feature set is relevant for them? Should we mark each feature to whom it applies?

Manuel: I would suggest the involved teams meeting for features that are relevant to all

Pranav: I work in a diversed agile team that is very complex. I know two ways of communication there: a) responsibility of the dev to contact design for every task. (e.g. photo resize: This is visible to the frontend so design needs to care as well) b) epic cards where you can see who is involved into each task

Manuele: For IT this approach works, but design cannot split its work into tasks because you cannot split a page into separate tasks. It's always one thing. I need to have the whole "picture" to design. Cannot work step by step as development (e.g. profile picture cannot be later added, needs to be layouted with the rest). Proposal: Product and design sit together for a definite mockup. Draw image instead of specification. From that, create dev tasks.

Kirstin: Are we already talking about workflow?

Tilmann: Maybe there are parts that cannot be split

Manuel: I think we are close to resolving this. What pranov/manuele said, having a core person to identify the tasks and then come together with all groups and split accordingly.

Matthias: Define Milestones for which we want to have a design so a group of feature sets together are defined for a milestone, then design knows that whole picture, devs can slowly approach that.

Tilmann: Frontend devs depend on design, so keep them in mind

Manuele: Product team does not have to create tasks but should make wire frames in a draft way.

Kirstin: Feels like workflow again, let's have that talk first.

(Presentations with slides from https://yunity.slack.com/files/ksiu/F0M7ZQXDH/roadmap_example.pptx)

(Use case diagram from https://yunity.slack.com/files/ksiu/F0LUG4WNT/use_cases_community_example.pdf involved)

Wouldn't this take too long? -> Use cases are textbook style of defining specification.

It is just a proposal, (Pranav) maybe brainstorming over a few beer could suffice for most of the things.

Tilmann: I like this way of doing it because we need a way to describe features we want (e.g. from foodsharing) for outsiders to know how it should be.

Kirstin: On the topic on bringing new people up to date, the better/more detailed the documentation and spec, the easier to get people on board. So I consider the Use-Case-Diagrams as useful and worth of time.

Manuele: I like this way of working. Are we able to arrive at a good product in this way? I know this from my professional experience and when I compare Use-Case-Diagrams and the final product, this normally does not fit as you need a huge experience to create proper Use-Case-Diagrams. If they are not very well done, we don't take any use out of it. Can we manage that? 

Tilmann: I agree, but this (spec) is the work of the product team and we need to define a way there.

Manuele: But we need to reach a good standard.

Tilmann: We just do it the best we can, we cannot just say we leave it

Manuele: But we need to consider alternatives

Martin: First feeling about this (UCD) is a bit weird and I would need to try. Maybe I would not be the best at it, but for other ways of specification we also miss the experience. What do we want to achieve by having such a diagram? See the whole picture we have in our mind?

Kirstin: Yep, we already did it quite good in some pages (e.g. Communities). Add Business cases, system diagram and spec (Top-Down approach) and it will be fine. We need a good spec to progress.

Tilmann: Some might find this process to heavy but think about Malo: Much lighter approach, just do what devs think, designers to what they think, but that was not working together (instead dreaming in separate groups). Now we try the formal approach because we did not succeed in the first try.

Manuele: So you say if we try again we can be better?

Tilmann: I don't know why we didn't succeed in the first place. This was not a failure, but I don't know another way (than now writing spec) to keep everybody up to date on the same information and show everybody what we are doing. Should we ignore or fulfil those wishes (to publish what/how we work)?

Kirstin: Inside the groups, the work can still be as open as they want, but this specification should be as proper as possible, also to keep future development in line

Pranav: An example why processes start failing (https://blog-nkinder.rhcloud.com/wp-content/uploads/2014/04/openstack-arch-havana-logical-v1.jpg). When a system is very complex and too many people involved, traditional methodologies fail. When a system should be organic and everybody should be possible to contribute, the existing processes are not up to this. We want to enable people joining and leaving the project at everytime. The learning curve is a very big overhead. If we use Use Case Diagrams, we limit our network to engineers although there are other very very good (e.g. developers) available.

Martin: I like your agile approach, how can this work in reality? Tried it somehow but did not work so well. In the end, we still need documentation about what we want, maybe in different ways so everybody can understand that (different backgrounds). Community Page is a good example because we already iterated it 2-3 times. The current page evolved from this process.

Tilmann: If you would just have code & discussions, only ppl who understand code could contribute. We don't want to exclude those from the process of defining the product. In order to extend it, you would always need to see/read all the code.

Pranav: Did not say we should not document, just think about the processes we use because traditionals fail in a community based approach. Have experience for a couple of years on open source projects in a kind of professional environment. We just use (dev doc generated from code; some additional diagrams which describe the system)

Manuel: Agree, additionally to brainstorming sessions (see above) we should focus on solving problems -> first understand a problem before solving it

Beata: When I see ppl workin on (foodsharing parts), I feel a pressure that the product should be similar to foodsharing (not different for the user). Is there an effect on the product because of this? Could be a limitation/problem.

Manuel: There we need to be looking at problems to improve not just copying. Is it working the way it is now? Identify, what works well what not, to also improve. E.g. mobile compatibility

Martin: Foodsharing did not evolve out of nothing. We should still go step by step, cannot do everything at once. Would like to have steps not to write (unuseful) spec just because of having to write spec.

Tilmann: Pranav, u have experience with bootstrapping open source projects? We are in that phase, actually.

Pranav: Yes, start projects and then build a team around it that contributes out of passion. It won't run on itself, we need people to delegate & monitor, make sure that it works (there is no money that shows people the way so it is normally done by rude language -> we don't want that)

Tilmann: We don't have a developer-centric product. Users are not tech-involved (most of them), our team as well not.

Manuele: Proposal: Split: Brainstorming for us to know what we want (short meeting in person with some ppl involved), write spec later for new-comers. If the spec is the same as foodsharing, why not just start working as ppl already know? Consider the time pressure

Martin: Like sittin together but keep in mind that we don't do just foodsharing. refining is necessary, would rather use some time for that instead of creating the wrong product and seeing that afterwards.

Manuel: Agile means always considering and reevaluating. So would not lead to wrong product.

Pranav: Valid point. Short, meaningful steps. Addon to manueles proposal: Adopt system to people, not other way round.

Tilmann: Would like if you meet, but in a small group you may have a different view. See this as a start, not more.

Manuele: Agree, best would be to sit all together. I don't want to take one month until that happens.

Manuel: That team would include the best people on that topic and afterwards they share their results, so others can improve with feedback.

Tilmann: Isn't this how we work?

Beata: Can we setup something before Rotterdam to have a main topic for that? Malo we had focus on dev, but product what not defined. We should conclude our experience to learn. Setup a schedule before? What happens between the Wuppdays? 

Matthias: Isn't this how we work normally? Each team focusses on their work.

Martin: Acutally what we did here in Nuremberg was quite good. We just would need more time :-) I can't imagine to work like this online.

Manuele: Proposal to meet in the mean time for clarification on that?

Bodhi: There would be places available, we have a list. Do mini Wuppdays in between :-)

Tilmann: Although there would not be many people, I think it is enough. For spec we don't need much.

Kirstin: Yep, having more spec before Rotterdam would be great!

Martin: Product is very big, consider that we need to prioritize. We don't need the complete spec to be ready for Rotterdam.

Kirstin: Have a target to have 3-4 Specs finished before so Devs can start.

Beata: Meet in a private place between wuppdays to have less distraction.

Kirstin: Have a look at priorization later/tomorrow? -> Yes!

Beata: Can product delegate things more?

Tilmann: Please write down answers to all the questions here as suggestions! Prefix with Name/Initials.

( See the questions summarized ABOVE )

( Take a break )

( Decide to postpone open questions to next meeting )

[Meeting ends: 17:40]