2016-02-10 Catch-up and workflow meeting

Owned by Janina Abels
Last updated: Feb 11, 2016 by Tilmann
16 min read

Minutes

Present: Matthias L, Tilmann B, Martin S, Manuele C, Kirstin S, Raphael F, Janina A, Philipp E
Location: Manueles Flat, Nürnberg
[Meeting begins: scheduled 18:30 (real 19:05)]
[Meeting ends: scheduled 20:00 (real 22:10)]

Outcomes

  • The existence of a team handling the specification was deemed useful. → There should be a product team!
  • The present members of the product team handling the specs are: TB, KS, RF, MC, MS, ML
  • It is no problem if there are big overlaps when it comes to the members of the product-related teams dev, design and product. Only the specific tasks need to be located in one specific team's line of action respectively.
  • One person (some kind of 'product officer') that is intended to keep the overview over all questions, decisions and progresses related to the product is going to be named. This person is supposed to facilitate and quicken the communication between the different teams. KS said she'd post a decision task on the trello board after the meeting.
  • Timeframe for upcoming tasks is reduced drastically: About two weeks per period.
  • The current roadmap was deemed not useful as the time periods are much to long. KS proposed a new roadmap for shorter periods of time.
  • Regular meetings and communication via all possible channels und among all three teams members was deemed nessecary and possible.
  • Specifications on the wiki will be reviewed, contradictions will be eliminate and the wiki will be made fit to serve as the base for the work of all three product related teams.
  • The comment function in the wiki was reactivated to facilitate the workflow regarding specs (but also everything else).
  • The next meeting is scheduled on 2016-02-12. It's going to be a big workshop to get the teams to start working together while they are still in one place.

 



Expectations of this meeting:

(Martin) Find a good way / process on how Product decisions are made (Product Team, Dev, Design). Maybe: Pick one or two goals (small features) that we make ready for being implemented by 2 new contributors working together with Matthias and Nick??

(Matthias) Clarify how specification decisions are made and how the design & dev team can then work mostly independent & how to bring divided work back together :)
Put down a list of questions and answers, that we think have already been decided on

(Raphael) Find out what is missing so that new developers are able to contribute
How to find a stady and passioned TPM with time to enable others to contribute
Define a MVP launch date (maybe august at the end of the WuppDays in Kirchheim)

(Janina) Get a better understanding of the workflow of the product team and where the product is at right now. Also getting better at taking minutes...^^

(Manuele?) understanding the funcionalities (witch and why) of the software we are creating
understranding roles we need and the state of the art

(Manuel): Find out more about the next steps in the design phase of the project & brainstorm with the team to also share some of the ideas that have come up for me. MVP - Early Traction? in an area? how does that look like?

(Kirstin) Finding out where I can help with the roadmap and the specification

(Philip) Getting a better understanding of what team product is up to. What is the status today. Is the roadmap still good or does it have to be adjusted.

(Tilmann):
- Define Product team
   (what are its tasks? what is the input and output of the team?)
- Interaction with Development and Design teams
   (product team creates high-level specification, dev/design work out details)
- Define a workflow how we vote about modifications to the specification
   (maybe like textual "diffs" with comments for each diff?)
- Define a place where everybody can access the specification
   (wiki and mockups)
- Evaluate existing specification drafts and roadmap steps

Questions:

Questions from previous meeting (answers formulated in this one):
  • Should we have a product team?
  • Yes!
  • Who is the product team and what is the workflow of this team?
  • Who? Everybody writes down what (s)he wants to do after meeting. 
  • What is the workflow? Propose a workflow in small discussion - almost everybody in the room is in
  • Who is the design team and how do they work, what do they do?
  • Who?
  • How? Invision-Mockups, small groups. Interaction with Development Team
  • What? Brand identity, colors, fonts etc.
  • How can product and design team work together?
  • Regular meetings, heads of teams discuss
  • How can development and product team be distinguished?
  • Product says what is done, Dev says how its done. 
  • more discussion on workflow: 
  • How detailed can design and development expect the specification from the product team to be?
  • How do design, development and product interact?
  • What is the short definition of product?
  • How do people work together to create the yunity product?
Came up during meeting:
  • What is the launch date?
  • We can't estimate our progress, but we can set milestones which can be achieved in a reasonable amount of time
  • What are the next steps for Design team?

Minutes

First: catch-up on the different expectations and summary of the last smaller product/structure meeting on 16-02-08.
Most important questions include: a clear way of decision making, getting on the same page, finding tasks for new programmers and ways to include them productively, define the launch date, getting a clearer image of what the product should look like and which features the MVP should include, differentiation of design dev and product team and getting more clear on their common workflow
--> LOTS of topics
--> Priorization is needed

RF: Let's focus on the MVP for now, since the product in general is a much bigger thing.
MS: Workflow is also really important, so that we can clarify how we're gonna work together in the future.
RF: General idea for MVP is foodsharing plus. Meaning: easier to use and ready for being expanded, but atm primarily for the foodsharing community.
TB: Where do we take our ideas for the product from? Is it only foodsharing and should it be? It needs to be documented somewhere, so that user needs can be formulated and specifications can be defined based on them.
TB: These infos need to be organized transparently, so that everybody can access them and can work with them. Which tools are we gonna use? Wiki-files amd graphical mock-up from Manuele don't match up. We need to clarify our means of communication on product ideas and work on it, so that we don't walk into different directions and waste time doing so.
TB: The purpose of the product team is to ask the question 'How can we fulfill the user's needs?' So... what should our specifications look like?
MS: We should prioritize, e.g. focus on the food basket for the next weeks and distribute related tasks.

MW: Do we have a person that connects all the relevant teams and keeps the teams working on the most important tasks, since (s)he has the overview?
KS: No right now we don't, but i think we should. You could see this as a kind of hierarchy, but it really facilitates the workflow. Are you okay with this?
ML: I don't see this as a problem of hierarchy, it's more about workflow and distribution of information
TB: It would be like the head of the product team, but until now, nobody volunteered...
KS: We should have a vote on this kind of 'product officer' later on.
RF: When later..?
KS: There will be a decision post on the trello after this meeting.

Above-mentioned questions are adressed one by one and answered directly if possible.

TB: Defining the workflow is really complicated, we shouldn't discuss it right now, since we can also address this in smaller groups and discuss all the possibilities. I'm definitely in for the workflow definition. Who else is?
RF, MC, MS, KS, ML, TB (Did i miss someone..? Sry, if yes...^^)

Design team tasks discussed right now are only the directly product related ones.
TB: Even the logo is actually not directly product related.
MC: Design team should work independently on clear tasks for a short period of time, maybe one or two weeks, and then present it to the dev team to see how it works for them. Then define new clear tasks and do the same cycle over again.
TB: Ok, but is this how design works, or how you wish to work?
MC: The second. But it would be great if we worked like this!
MW: Agree.
TB: Should the UX also be a part of the design?
MC/MW: Definitely!
MC: First we need to understand the userflow, evaluate it and then try to make it better based on the data we collected.
KS: It is part of the work that design does right now.
TB: But should it be that way?
MC: Yes. And also i still don't really know how you understand the product team.
KS: I thought that, too. Do you see product as only responsible for writing the specs?
TB: Yes. That's how i see it. Of course all three teams need to work together really close, but it should always be clear in which team's sphere a task is located. I for example am dev and product and also have experience from foodsharing. But this experience shouldn't influence my work as a dev. That's why i'd like to clearly seperate the tasks, but not nessecarily keep people from participating in more than one of said teams. 
MS: Yes, but there definitely needs to be a lot of communication. E.g. the seperate teams come up with proposals and then the teams meet up and have a kind of feedback round to see if everybody agrees on them. And then the cycle would start over gain, but this time with clear tasks.
TB: So, the question was 'How can product and design work together?'
RF: Regular meetings, as well online as in real life. And we'll also not only gonna communicate during these meetings but also in smaller groups on maybe even a daily basis.
MS: Yes, the meetings are important. The product team should also write down their proposals in an accessible document for everybody to see. I propose the wiki.

TB: Ok, to the launch date...
KS: It was initially set in a quite arbitrary way, now that we have more information we could maybe come to a more reasonable launch date based on what already exists?
ML: I still don't think that we could come up with a launch date that's based on facts. Actually, the way it is now i don't think we'll be able to launch an MVP during this year... But i'd like to have smaller tasks that can be achieved in smaller periods of time.
TB: Yes, smaller tasks would definitely be helpful. Right now we only have these big chunks of work in the roadmap called 'MVP Pilot' and then straight afterwards 'MVP Final'. It needs to be broken down way more for us to even pinpoint where we're at right now. 
TB: It would be better to have smaller sets of features that can already be tried out by people.
MC: Yes, to make people help with bugfixing and stuff.
TB: For communication it would be useful to not only have a head of the product team, but also heads of dev and design.
MC: To get quick answers I want to have a person who has the overview, so that i don't have to read through all of the wiki all the time

[BREAK]

Meta-Discussion during breaktime about culture of discussion and conservative solutions.
Input from JT from structure about focus, inclusion and speech patterns. Look at feedback for more on that.

[END OF BREAK]

ML: Seperation of dev and product is important because i'm not always sure for which team i am working at what time. I don't feel comfortable just deciding on matters, only because i am part of both teams.
KS: Seperation between product and dev is probably the blurriest atm. But for clarification you could always come back to the head that will be named soon.
RF: It's not that product just says 'this is how we do it' but they can give input on unclear issues. We still need to figure out the process of how this feedback loop will work, though.
MC: If a person has a question (s)he goes to their respective head, if it still can't be answered, they go to the head of product and that person then HAS to know the answer. But this is hierarchy.
ML: Well, it still depends on how we make use of this system and if it doesn't happen lots of times it should be okay..?
TB: It's less about hierarchy than it is about having all the relevant information created by the whole team ready and sorted at all times and being able to communicate that.
Obviously there are problems and concerns regarding this approach, but it seems to be convenient for now.

TB: How does our gold standard look like? We have these wiki pages on different features. Is it detailed enough to be used by dev and design?
ML: I actually like the structure and thoughts behind these files, but sometimes they are still contradictory. The quality of the existing docs is not yet good enough. We have to resolve the confusing parts, so that we can really work with it.
MS: If it was google docs we could comment on them, can we on the wiki?
TB: I think we can, we need to figure it out.
MC: Or we just need to wupp it. Meaning: if i don't know something, then i look for the answer and as soon as i found out what i need to know i publish the info
KS: The general problem with the files on the wiki is that they were never officially agreed on by the group, that they are not prioritized and that they are still somehow contradictory, is that right?
RF: Well they were agreed on at the time, by smaller groups like me and martin, or martin and matthias, or me, martin and manuele. We also did prioritizing, but now we have these bugs which we need to get rid of.
KS: So the general opinion is still in favor of the wiki docs, right? Then we have to check them out again, to fix the bugs and make them workable again. 
MC: Total agreement.
KS: So for this wuppdays, how about we try to go through the first two phases of all the features and fix the bugs?
RF: Yes, and i really think we should set some kind of deadline. For me personally it was always helpful to have a set date when i wanted to get work done. I mean, the dates could be changed afterwards of course, but just to get it started, wouldn't it be good to set a timeframe?
TB: Actually there are already dates. We set them in Mainz to measure our progress. If we don't get it done it's also okay, then we know we've been slower than expected. But these chunks of time are like half a year it's just much too long.
MW: I suggest chunks of one or two weeks. These work best according to my experience.
KS: Oh wow, this is really short, isn't it?
MC: Maybe, but like this you cannot say 'i'll do it tomorrow' again and again and if you really think you cannot or don't want to do a certain task, then you say so directly in the beginning.
MW: Also, you can actually effectively plan in a one or two week frame because you can find out who is actually available at that time and work closely with them.

Back to the wiki...
TB: Maybe we should make clear that there is a difference between original articles and dependent articles. A dependent article is like a summary of original articles and therefore needs to be changed accordingly, when changes on the original articles are made.
MS: Exactly, it's really difficult to work on things, since everything is inertwined. If i change something on a feature it could have unwanted consequences on other features.
RF: Maybe we should reintroduce the open discussion method on google docs and only migrate information when the discussion on the google doc is finished.
TB: We can try it, but then someone really needs to take care of the file, like accepting suggestions and the like, because if not it really gets messy very soon.
RF: Yes, but isn't that doable? For example with the newsletter i felt in charge of getting the work done, that's why i went through it in the end accepting everything, just to get it finished.
PE: Or we could have some kind of a consent in the end? Meaning: Asking if everyone is fine with the version as it is, like if it's really finished?
JT: Or we could copy what wikipedia does: They have a discussion page for every page, and there comments can be posted and discussions can be led in a non-messy manner that also is fully transparent.
MS: There should be a comment function at atlassian,too, but i don't really know how it works, also because we never really used it. But if you click the three dots on any page there is something mentioned about comments...
TB: I'm not sure since i'm not space admin, doug is, but i think he may have disabled the comments.

[SHORT BREAK TO REACH DOUG VIA MASSIVE SPAMMING ON SLACK]

MS: *watching a tut video* Ah this is amazing! Seems to be exactly what we need! It is even addressed directly at people who want to implement feedback loops!

*group watched it together on tv*
RF: YES! That's it! We need that!
KS: This seems like the answer to all our problems!

TB: Ok, but we'd still need to take into account that changes need to be decided on since they might have an impact on other features or modules.
MS: Yes, that's really important because everything is connected.
KS: Proposal for how to move forward: Sort out and review all the tasks, prioritize, define dependencies, group tasks and form timeplan.
MW: I think it's to extensive for now. We could spend this energy otherwise in the next days.
KS: So for now maybe only stage one? And then reevaluate how it worked for us and how far we got?
MW: Yes that sounds better. Because right now we couldn't come up with a timeplan anyways.
ML: ...at least not a reasonable one...
KS: Ok but one or two months down the road we maybe could, so let's just see then and focus only on stage one right now. So do you still have one file with all the stage one features, so that we can review it and sort it out?
MS: Yes, it should still exist somewhere...

MW: Is there a possibility to have tickets for ticked boxes on the wiki, like an automated information extraction, that helps keep the overview? (sorry, didn't quite get this question and the following discussion about these so-called 'tickets'... But it was about some kind of integration with another platform like trello)
KS: Maybe we should open a new trello board for product, since it's a collaboration between different teams...? It's at least something to think about.
ML: Breaking down these wiki pages into dev tasks, which we can actually work on still takes a lot of thought, though. When i sit together with Nick for example, we just figure it out and do it, we wouldn't formulate tasks, put them on trello and at the end of the day move the cards. It would just not be practical or nessecary.
RF: But we still need to enable new devs to take part. The knowledge in the heads of ML, TB and NS is so valuable, that it needs to be accessible. If it's not made public, nobody else can contribute.
TB: Yes, we know that, that's why we already document so much and take the slow way. In the product wiki i also put down the task of 'controlling the complexity' which is precisely about this issue.

KS: What's the plan for tomorrow now, based on this discussion?
MC: Make more feedback rounds as long as we have the possibility to be here together.
RF: Really staying focused now, to formulate tasks.
MW: To think about what's right in front of us, that's it.
RF: That will also definitely speed up the work and shorten the time until the launch.
MC: We could also write all the specs and formulate tasks and then create an event like devwuppdays where all of it would be implmented.
KS: Sounds like a solid plan.
TB: Actually it doesn't, because when you code there are always things coming up, where you have to take a step back and rethink your approach and you might end up change things you may have thought were already decided.
RF: Ok, but still. If you're an architect and want to build a house you can also come across difficulties. But these will not make you demolish the whole house, right? Maybe you end up adding the balcony on another side of the house, but it's still very useful to have a very detailed plan in the beginning.
MW: There are many people out there who love fixing bugs, and they probably don't mind spending an evening. Only the specifications need to be accurate, so if you implement a feature and come across a bug, somebody will find it and point it out to you.
RF: Well yeah... there are bugs here and there, but they're all gonna be fixed! *grins*
MV: More infos and mockup about an integration of tickets. (Sry, didn't get it fully...)
TB: This wouldn't work on our wiki though, because we wouldn't know if it was a design or dev or product task... Can be figures out, though. We need to see.

KS: Ok, when are we gonna have the next product meeting in the next days? :) I also created an updated roadmap, just broken down into feature sets 1-3. I also think we should definitely hold some kind of a workshop meeting, where we really get to wok together. To go through the features and prioritize them, so that we know what to work on first.
MC: I agree. Now we understand each other better, so that we can actually formulate tasks.
TB: Yes, it would also help when more people see the wiki pages. I know all of them, but more people should.
KS: So maybe on saturday in the morning?
MW: Maybe at 9am for breakfast?

Feedback

TB: I really liked it, i think all my questions were answered. We have a workflow now, Doug already enabled the comments on the wiki, you can now simply mark text and then comment on it.
MC: I also think it was nessecaryd and very productive, I'm confident we're on a good way, because we made some important decisions and more progress is to come.
KS: I'd like to keep working with the product team, it was really good.
RF: It helped for me, and i hope for everyone. I think we're on the right track and hopefully through this will be able to set a date for a laucnh soon.
JA: Found it really cool to observe this meeting, the group took a bit of time to get started with a concrete topic. But soon it worked out almost perfectly. Also got faster at typing.
MW: Is really thankful to be here and is looking forward to cooking with pranav and doing acroyoga with kirstin.
ML: I'm very happy with how the process went although no formal decisions were made.
JT: "we want to..." can be misleading in a discussion, instead ask "do we want to...?" and take a decision.

Later feedback from JT, put into words by JA:
JT: People still seem to be afraid of making decisions.
JT: If you really want to make decisions you need to seperate the decision making from the creative process that is a discussion. Concrete example of how you could proceed:
JT: You come across contradictory modules in the specs, you write the problem down in the most clear way possible. You put it up to an online systemic consensus, let proposals be made and make some yourself, let the people who self-elected themselves concerned with this question (following the three questions "Will the the outcome affect me? Will i be accountable for it? Will i actually do the work?") decide and continue to work according to the decision, that was made.
JT: If this decision has impacts on other features/modules and new questions arise, just do the same thing with a new question again.
JT: Because questions which are not addressed and solved in meetings or consensus will be decided on absolutely intransparently when time starts to press at some point, and then no trust nor confidence can be generated regarding this decision


To the extent possible under law, the yunity wiki contributors have waived all copyright and related or neighboring rights to the content of the yunity wiki. More information...

You have an account but can't edit or create pages? Write us in the open chatroom or in our yunity Slack!