Boy, was I refreshingly naive! Not yet naive enough to actually start something just like that, but get informed and involved before. Yet, it was perfect to dig the whole start-up topic. Later, see a starter-pack of my personal recommendations to this topic. But first, let’s get to business…

What’s the situation?

Soon, he will finish his dissertation in medical engineering. A really smart, friendly and quick-witted guy. A friend of his asked him what he wants to do after he’s done with the diss. After they talked, he ended up with an offer. He can get involved in the startup his friend founded. He’d get paid way under his market value, but owns company shares. Wow! What a tricky situation. Tough call, I’d say. This led to him asking me how much such a startup can be worth, unfortunately without any further context.

Obviously, there is no clear number I could tell him, no yes-or-no, do-or-don’ts. Instead, I tried to convert my current state of mind into a dense checklist. He could use my thoughts for checking if it could be a proper invest.

My advice

I tried to roughly differentiate between four main criteria-categories. All can be crucial for taking this decision:

1. The Problem
2. Strategy and Methodology
3. Figures
4. You

Just remember: The answers and gotta fit to your liking. There’s no “good vs. bad”. In most of the cases, there is no right or wrong – it is entirely up to your thoughts, preferences and personal plans.

Point 1 – The Problem

Meaning the problem the startup should be called to solve.

• Do you yourself believe that enough people have this problem AND want to solve it AND don’t want to solve it well enough in another way?
• How much work has been invested into the startup already?
• Is the founder already too much in love with his solution? This is like a pre-programmed deathblow for a startup. Founder and their team should be in love with the problem instead!
• Can a solution to the problem be sold/presented well and possibly monetized in the long run?

Point 2 – Strategy and Methodology

• Does the founder want to achieve a good exit, that is, sell the solution at a great value to a big fish?
• Are there plans to scale the company asap, or put in a HEALTHY growth?
• Is the Founder (or someone else in the team) a good salesman/ speaker? Because this is one of the most important activities of a founder: selling!
• How methodically does the startup proceed? It is important that the management team is really literate and enthusiastic about lean startup/ design thinking/ design sprint/ human-centered design! Like this, a startup increases the probability to alleviate the main problem of startups in the best possible way: too little time for much too much to do. Read about my info starter-pack recommendations below.

Point 3 – Figures

To come back to his exact question. Of course, there are these and such cases.

• How is the financial plan and current situation?
• It is quite possible that in the first 3 – 7 years business will not be in profit. Still, it can increase in value if it proves itself to be growing strongly (not necessarily by headcount).
• In Germany, startups with a hardware product are usually much more likely to go into prepayment. This is followed by lower margin promises and scalability, as opposed to digital goods.
• German investors are not very fond of high investments (in comparison to other countries). That’s (also) why digital products (and especially platforms) are more of a trend. As a team of five you can already solve a huge problem at scale. Not necessarily the first solution has to be scalable, though. A pearl of start-up wisdom says: Do unscalable experiments first. Find out what you need to do without too much pre-investing.

Point 4 – You

• Is the vision suitable for you? Can you feel being a missionary for what the company wants to stand for? Does it catch you, and you feel the fire burning inside of you?
• Are you ready to join the company full-time? Maybe you don’t need to invest much more than 40/ 50 hours per week to be successful. Still, usually, the bottom line is that it’s more like two full-time jobs. Especially if you have shares in such a company. Your motivation might be pretty strong to get it profitable.
• Statistically, your chances are about 10% that you can make a profit with your shares. By the points above you can decide whether it is rather less or rather more than a 10% chance.
• Determine the possible effect on your CV. E.g. in my friends’ case working in a startup is actually doing good to his vitae. As a postgraduate, he’d prove his interest in the market and the creation of good products, as opposed to being brain-bound (as postgraduates are said to be).
• So your main investment would be your work performance and the opportunity costs (salary you could otherwise get).

Info Starter-Pack

Here is my personal list for getting informed. Listen to podcasts like Masters of Scale by Reid Hoffman and Wireframe from Gimlet Creative. Check out TEDxTalks, and start with the one that’s really sticking in my head Start With The Why by Simon Sinek. Figuratively eat books like Lean Startup by Eric Ries, Inspired by Marty Cagan, User Story Mapping by Jeff Patton, Sprint by Jake Knapp, John Zeratsky and Braden Kowitz, Actionable Gamification by Yu-Kai Chou, Even Ninja Monkeys Like To Play by Marczewski, Hit Refresh by Satya Nadella and the Autobiography of Goetz Werner. Don’t just read them, but work them through! Make notes, summarize chapters and make notes for your later self (even if you might never read them again). Go on Founding-enthusiasts-meetups, participate at Hackathons (like us), talk about your ideas and concepts and explore the unexplored.

Now, around 1.5 years after I started digging the topic, I ended up becoming a product owner in a solid startup called sofatutor, and this brought me to a realization. If you wanna make the world a better place, solve real problems of the people and create something special, you don’t necessarily have to be a founder of a startup yourself. Every (small) company can win by people like you. You can bring all your enthusiasm into place and make it to your project!

So what do you think? What would you tell him? What’re your favorite reads about Startups and how to create a product your customers love? Let me know in the comments below, write me a message, link this post in your own blog. I’m very eager to hear other and additive opinions.

Keep up the challenge!

Yours

Sören

She is a strong personality, an overachiever, a hero, a secret leader – even if not all of the above apply to your teammate, she still can be one. In this blog post, I will try to make you understand, why those (hereafter called) overachievers carry a huge risk for an agile team (and company) inside. It is easy to ignore, tolerate or just accept, but if you and no one does anything about a team-substance like this, it can react poisonous when combined with wrong elements. Dare to let it be as is, and you will suffer the consequences, just like the rest of your team. The way of least resistance is not always a good choice.

But what is so bad about it?

Depending on the overachiever and the team, the following things are possible to happen to some extent:

• Skill development, success, and outcome should be team achievements. If only one person gets all the credit or is the go-to-person for everything, the rest of the team starts feeling discouraged. Why try harder, when you can only do your job, hide behind her and work off the 9to5-duties? Falling into this behavior, makes your work ultimately seem meaningless. Friendly colleagues, a more or less appropriate salary or a nice environment will not motivate on a long run. If you lose the mission, why stand up in the early Monday mornings at all?
• You wonder how she does it? She might never let you know. Overachievers tend to take over the tasks, with the mentality of “If you don’t do it yourself, it won’t be done (properly)”. Like this, she thinks (or says): “By the time she explains it to you or someone else, she has it done by herself”. The latest, when you hear one of those two phrases, your alarm should go off! She eagerly maintains her knowledge island and makes it grow. So the team success depends on her, sometimes only on her. This puts the team and the organization into a bad place when she feels like she wants “more”, is on vacation, simply not there, or even leaves. In Agile Teams, this is worst case in action! Because…
• It is easy and seems intuitive to mismanage: teams and even companies die in the long run due to encouraging overachiever to save the day over and over again. This is what I saw going down at Goodgame Studios back in the days: They get the feeling that they must be held within the team, or it will fail. Bad/ inexperienced managers tend to think they need to give everything to keep them in the company. Suddenly, that overachiever finds herself as people-manager, not able to perform like in her original profession. As a result, the company traded a highly professional developer (or whatsoever) for a “bad”-leader. That’s a lose-lose-resolution. For a manager, it is easy to overlook the short-sightedness of the success of such an overachiever. Therefore, it is important that everyone understands: A mismanagement of such overachievers is a threat to sustainable success.
• Overachiever have their specific characteristics. Your teams’ approaches and results will lose it’s exploratory diversity when she is always “in the lead”. Remember: the Product Owner brings the “why”, the Scrum Master the “how” and the team the “what” (see https://www.boost.co.nz/blog/2018/04/successful-scrum-team-product-owner).  By having the same approaches and doing the same type of work, you will lose the important ability of scrum teams: solving unknown and complex problems. Work starts to feel highly repetitive and – again – meaningless. The rest of the team starts mirroring her, by also over-/underthinking stories or spending too much/not enough time on general discussions. Moreover, the personal development of each team member will suffer, when no one breaks this pattern.
• Team member feel like they cannot contribute, so they start letting the overachiever make all the talk-work. This ultimately leads to letting her also do all the thought-work (because it’s convenient)… And even though it’s an overachiever in the lead, she might not be aware of the specifics of her “power” and influence. The team ends up with getting poorly directed. “People [working for an overachiever often] do not understand where they are going. They’re just following the walk of this turbocharged leader, who doesn’t direct the team but focuses on output. They get annoyed, exhausted, and feel that they need to second-guess what the leader wants because they’re not being told.”, Goleman, D. “Leadership That Gets Results,” Harvard Business Review, March-April 2000.

What to do?

The main objectives are:

• Let the overachiever share his knowledge (to reduce knowledge island risk),
• Give every person equal opportunities to provide their input (to live collaboration and achieve diverse approaches to master complex problems).

Be sure: The overachiever in your team is not a bad person! She aims for only the best for the company and product. Of course, to her, it seems that she does it very well! Remember, you are not enemies or opponents, but teammates who need to figure out how to work best together and achieve sustainable success (and fun)!

Step 1 – Out of your comfort zone!

Well… not (only) the overachiever is the reason why change needs to happen. What does Michael Jackson say again? Start with the man in the mirror! “If you wanna make the world a better place, take a look at yourself and then make a change!”

Speak up, take action, demand change, to improve communication and vary methodologies, and don’t fall into the dangerous pit of self-pity and couchpotato-convenience. See this paragraph as a start for your journey, for letting your team grow together, a bunch of equals. The team needs someone like you. You will be the one who must be demanding change, if your Scrum Master, Product Owner or Lead doesn’t do it! It means, if not you, no one will. The fact that you feel/ realize that this might be or become an issue in your team, you are the chosen one.

But how, you ask? Expect and demand baby steps! There will not be a “big bang”-change and everything is “good”: One step after another. Even small changes can have a big impact.

Step 2 – The (Scrum Master) Talk

I know, the Scrum Master is not holding any leadership position and yet, she is the one who should facilitate and host team gatherings and meetings. She is supposed to take care that exactly this does not happen. Her influence is limited by the willingness of the team, so give her reason and solid ground to work on equalization within the team. Maybe she is not very experienced yet, or she also just accepted things how they are (aware or unaware of what it means). You should find the talk with her about what she thinks about the situation, and what you can do to lift up the team spirit and sustainability! There are many things she can do, to give everyone the change to commit their ideas, opinions, and qualities.

Ah… and by the way: Even if it is only you, who feels a bit outside of the system (and everyone else is kind-of ok), you still should make your point to her. A Scrum Master should also be the go-to-person, for a team members issues, and help to get all the potential on the street!

Step 3 – Remind and demand Agile Principles

Do I really have to say this? Agile teamwork is about dialogues and collaboration. Embrace every individual in your team as equally important and qualified, as a potential if not experienced (yet). Collaborate, interact, and get the best out of every single member! See the first freaking line of the goddamn Agile Manifesto: “Individuals and interactions over processes and tools” ( http://agilemanifesto.org/ ). Such simple and undiluted wisdom… It makes me cry every time I have to remind people to think about it. It should be burned in your and everyone’s (developer) brain. It is not negotiable or relocatable. This should be surer than day follows night. Before you try to enable the potential of your team with methods or tricks, consider talking about the issue openly with the whole team. Make them understand why embracing and supporting overachiever-ness means to risks sustainable success. A retrospective meeting is a very proper time to place your concerns! Agile teamwork is based on trust. Give your team (including the overachiever) the benefit of trust and honesty.

Step 4 – Bring in opportunities for good behavior

Train your instinct and get a sense for the right moments to embrace collaboration. In discussions and talks, notice who is silent and doesn’t commit to active collaboration. Encourage them to speak (up), i.e. by actively asking them about their opinion. If you know your team members well, another more sneaky way is, to bring up a topic they are passionate about, make a connection and/or take an opposition-position, so you tease them out of their lethargy (you can also (later) be honest about your evil-genuine plan to get them into the conversation). Continuously place suggestions to collaborate or to do pair programming, because sometimes a little push in the right direction is all that’s needed. Yes, also you as a teammate can do this – no need for a Teamlead, Scrum Master or Product Owner to make those moves.

Step 5 – Remove opportunities for bad behavior

There are several methodologies to give everyone the opportunity to provide their own input and to also let them talk without being interrupted, discouraged, or subdued. Usually, your Scrum Master comes up with those ideas, yet sometimes they also need a little inspiration. Don’t worry. It doesn’t always need to be a big thing. Actually, mostly it can already be enough to request a democratic vote, to let everyone think about something themselves and/ or add their thoughts. But for some bigger topics, you might think of the following two approaches: A neat little allrounder method is the silent brainstorming, with a followed presentation-time. Everyone has around 5 to 10 minutes to make up their mind and write it on sticky notes. Afterward, when everyone is ready and done, each participant gets a limited time to present the sticky notes, and do something with them, according to whatever purpose the brainstorming was about. Like this, everything is limited to a specific timeframe and as you can see everyone provides in the same manner. You will find your team in situations where brainstorming can be of value. Instead of just throwing in ideas (and get overwhelmed by the overachiever), you can suggest silent brainstorming. Something that helped me a lot to manage bigger teams, with a multi-dimensional problem, was the following: Split the team into two- or three-people-groups. Each group targets one part of the topic and presents it to the rest of the team members. If you want more people to provide input to each aspect do the following: Instead of only dividing the team into smaller groups, you also divide the room/ location into different subject-islands. Each island has one subject-host (preferably the overachiever is also a subject-host). Every person/ group spends around 5 to 15 minutes on each island, while the host notes the important parts of the talks/ discussions. After every group talked about every subject, the hosts present the results of the island. This was most helpful at retrospective meetings or to get solutions for highly complex features or goals.

Always remember: You are not enemies, but teammates!

I hope I could give you a little sense of how you can handle the overachiever in your team. Of course, there is no such thing as a clear path to teamwork-city, but if you take my words as a starting point for orientation, you maybe find the right way. Don’t hesitate to comment or write a direct mail to me, when you have any further questions or feedback.

Enjoy, collaborate and succeed!

Soeren

P.S.: Yes, I did misspell “playfulness” in the video. Let’s just all move on and pretend it didn’t happen.

Let’s learn from each other. In a fun way.
Dannynator.

Whilst working on tech stuff, often a talk with a friend comes to my mind. When he asked in a deeply sarcastic tone whether I’ve got time to meet up or if I’m into my “private projects” again. Yeah, exploring the tech world can be pretty time consuming but doing so is great fun too. The result of that time was an Android note app which I use until today regularly. With that project, I learned a lot about clean architecture, object-orientation, Android, UX, and even project management.

How to approach it

Basically, the message is: Engage with a tech field you are new to. This is not a new idea. Despite, a lot of professional and experienced developers have a limited mindset when it comes to usage of appropriate technologies because they don’t know the objective advantages and disadvantages of choosing one technology over another.

So, the question is not whether you should broaden your horizons or not. It is when and how you should do it and how to keep on. Here are two approaches which both have their own up- and downsides:

• Private Projects: You can work on your own small projects about a topic you personally find interesting. As it is something you chose yourself chances are that you are super motivated to start the task. The problem is that you might choose the project scope too big and lose interest before finishing the project. Another problem might be that you don’t have an idea what to code. Therefore I prepared the second point.
• 7 Languages in 7 Weeks: This is a book written by an inspiring author called Bruce Tate. Within his book, you can find seven introductions to programming languages (what a surprise). They all have different emphasis just like different private projects. If you are a more structured kind of person this might be the choice for you because Mr. Tate guides you through advantages and disadvantages of technologies systematically.

Hacking to the Gate

My current project is part of our future gadget lab, so put your cup of hot tea aside and take a fresh cool Dr.Pepper instead!  We gave our project the name Divergence Meter (modernized) Ver.2.31 and it will help us to finally leave the alpha attractor field and reach the Steins;Gate worldline. I can’t tell you too much as the organization is chasing after us. ~el psy kongroo

For the boring normies out there: A divergence meter is a fictional device from the anime Steins;Gate, but you can use it as a multifunctional clock. A friend of mine built the thing and I’m currently programming it. We created a modernized version using lixies instead of the original nixie tubes because for our poor lab they were more affordable. The lixies work with a rotary encoder called Cronios-1. Put simply, with the rotary encoder you can program your device using a dialect of BASIC namely LED-BASIC. Here is an impression of the beautiful code you can write with it:

' VAR: g: Month from data, q: Day from data
8020:
for i = 1 to 10 step 3
g = read 50, i
q = read 50, (i+1)
if g = (IO.getrtc(4)) and q >= (IO.getrtc(3)) and i <> (IO.eeread(18)) then IO.eewrite(18, i)
next i
return

I never programmed that close to the actual hardware and it feels quite hacky in the beginning. You can spend hours trying to display a 6-digit number. The code for our clock has a length of more than 1800 lines in a single file with jump marks all over the place.

Benefits

But I could learn a lot about imperative programming especially when it comes to separation of concerns. With such a long file and a maximum of 26 variables which are all global ones, you have to think about where to put what code snippet to avoid side effects and maintain the structure. Generally speaking, by engaging with projects like this one or the previously mentioned Android app you can think of problems in new ways and use your knowledge from one technology in another. This is also what Mr. Tate states as you will see in the next section.

7 Languages in 7 Weeks

Let’s assume that you’ve actually managed the difficult task of downloading and installing the interpreter or compiler for the language you are interested in. What should you do next? What will be your first program? – Joe Armstrong, creator of Erlang

This is an excerpt of the  books preface. If you also have these questions in mind whenever you think about starting a project, then the book will be just right for you. It is stated that new programming models emerge roughly every 20 years. Some emerging new languages are covered and some well-known languages, too. By doing so you can see how different paradigms can overlap or make clean breaks. Concurrency, for example, is a topic which is treated very differently in different languages.

Covered languages

Here is quick overview of the languages and some of the aspects you can learn from them:

• Ruby: Object orientation, dynamic typing
• Io: Prototype programming, dynamic typing, concurrent programming
• Prolog: constraint-logic programming, declarative
• Scala: Functional programming, Object orientation, addresses critic about Java
• Erlang: Functional programming, concurrent programming, immutability
• Clojure: Functional programming, treat code as data, lisp near
• Haskell: Functional programming, strong static typing, lazy evaluation

How to proceed

As soon as you have worked through the book and you are still eager to learn you can search the web for code katas or object calisthenics. These little exercises will help you build more confidence in programming especially if you choose unfamiliar technologies.

As always thanks for reading! One rumors that you can find a pdf version of the book if you search the web. Maybe you should take the chance and start right away using it 😉

Greets,
Hououin Kyouma

As a Product Owner and Games Producer myself,  I hope, with the following insights, to bring some value to you and your team members. You will learn why sometimes us Product Owners act how we do, and what you can do to improve your teamwork.

I gotta say: there are always two sides to a coin. Success is a team result – work together and you can make great things happen! If you don’t, it’s very likely that you fail on some level – first a bit – later drastically. In this post it may seem a little one-sided, but of course: the Product Owner should also learn how his team works and why developer and designer act how they do, and what he/she can change to improve your teamwork. But that’s content for futur blog posts 😉 So have fun with probably some unconventional, yet pretty honest insights into the world of a Product Owner.

Table of content

1. What a PO does
2. Why a PO needs you
3. Why a PO disturbs you
4. Why a PO forgets you
5. Why a PO relies on agile ceremonies
6. Sum Up

What a Product Owner does

In my career, I’ve seen a lot of teamwork bloopers. Mostly it all comes down to understanding each other and communicating accordingly. Especially junior-level teams first need to understand how the product world works. Sometimes it may seem like the Product Owner is not valuing your opinion, effort and time, yet I can assure you: we maybe are the ones who are most concerned about exactly just that!

“Would you tell me, please, which way I ought to go from here?”
“That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where—” said Alice.
“Then it doesn’t matter which way you go,” said the Cat.
“—so long as I get somewhere,” Alice added as an explanation.
“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”
Alice in Wonderland, Chapter 6, Pig and Pepper

The main goal of Product Owners is to make sure that your work and effort is well-placed, not wasted, not spilled or lost on a wrong path, but creates the maximum value for the user, and ultimately you. To show the way and make sure you are not wandering around like Alice in Wonderland, we try to find the right thing, convincing and powerful. Therefore the Vision Statement isn’t just a buzzword-bingo or brainwash-methodology, but the direction the team is supposed to walk, the common understanding. Sometimes it seems like Product Owner came up with the vision just like that, nevertheless you gotta understand that he’s only trying to put into words, what your organization, society, market and most of all the user needs.

Next to this, probably the most obvious tasks of a Product Owner is to keep stakeholders away from the team and to channel all requests as a single point of contact (SPOC). Because again – We only want you to work on what matters. Mostly stakeholders don’t really know what they want (even though they think differently about that), which makes it even more important to find out, what the actual problem is, to then decide what to do, and what not. That’s why “No” is one of the most important words of a Product Owner. To stay strong and resilient towards everything coming his way, he needs you.

Why a Product Owner needs you

First of all: because you read this blog-post, came till here, and obviously are eager to develop a common ground. Secondly, he really needs your input to work best. In my work I am always trying to make the team understand: I’m not better at programming than a developer, I’m not better at designing than a designer, I’m not better at analysing data than the data analyst, so I need my specialists to give me everything they got, so that I can take right decisions with you.

A perfect example of this is the design sprint. The key objective is to solve a user problem. It technically means to find proof for hypotheses proposed by an idea and then frame a Minimal Viable Product (MVP). Within a week or two, you discover, define, develop and deliver something completely new and finally create value for the user. When the Product Owner puts together the team, it’s crucial to have the right people on board. You got to learn to understand what stakeholders want. This is the right time to show your strategic foresight. Take the technical lead for the creative process and your input can make the deciding difference to achieve success. Bring in your creativity and technical ideas to solve a user problem. You have access to tools and ideas that the others don’t have. Do this and receive standing ovation. The result will be your baby – you will be the go-to-guy, you will suffer when it’s not done well, and you will rise and shine when it’s successful.

But not only in design sprints, we need professional input. Within backlog grooming, refinement or sprint planning give your Product Owner as much feedback as possible, even when he/she doesn’t actively ask for it. Use those meetings as a health insurance for your team unity: mention expense drivers and offer options – be constructive! Within your team, you should consider writing acceptance criteria and user stories yourself, at least when you spot gaps. By putting yourself into the user’s shoes while writing the stories, you raise awareness of the vision and the target persona, additionally, you drastically support your Product Owner. Maybe you even initiate having an Acceptance Criteria-checklist for the team, to encourage and enable everyone to collaborate in this way.

And last but not least: When we ask you for an estimation for a vague story, we mostly need some type of horizon of what can be expected, and we don’t expect an exact calculation – sometimes a guts-feeling is all we want. So it is best to make us understand a tendency rather than letting us stand alone in the rain. Also, explain why it seems unclear, and then we can fill the gaps together.

Why a Product Owner disturbs you

Now you know, the Product Owner values your time but also needs your input. So when you are coming to work in the morning, looking into your schedule and an additional meeting pops up in your calendar – what’s your reaction? Very often I hear something like “Oh, damn meetings, preventing me from working”. If you are not saying this: good! If you do, maybe it’s time to reconsider. When your Product Owner invites to a meeting, he/ she painfully prioritized already, very clearly against his/ her own preferences, because he really wants you to get your stuff done! But your role, as a member of an agile team, is not only to sit behind the keyboard and develop stuff like a coding monkey but to also provide important information and deliver your points of view. Programmers should not encourage the organization to bypass them. If you don’t like specific things in your meetings, talk to your Scrum Master or team, and change it. Maybe others have the same pain points but didn’t come forward yet.

In fact, I meet a lot of Product Owners being “afraid” to distract his team and take them out of their working-tunnel. We know, when you get distracted it takes you time to think on the topic again. Still, when we need important information and technical expertise to determine an issue, we need you. Next time you catch yourself reacting annoyed, show empathy. Another way to handle this and turn it into a win-win, is to agree on how to approach each other: e.g. with Sticky notes, or a sign to set to “need consultancy”, so someone who has a free mind can reach out to him/ her.

Why a Product Owner forgets you

This sounds a bit weird, I know. Yet, there may come the time when you get the feeling your Product Owner forgets that you and the team are also key-stakeholders for the product. Mostly it’s the moments when the technical debt or lack of quality is raising the risk, or you are generally concerned about the decisions. It is important for you to learn how to approach your Product Owner then! The key is to speak in the same language. Write your technical issues as user stories and make clear what’s the value for users if you do it, or the effect if you don’t. The things you care about will be user relevant. Maybe not in the next sprint, but in the mid to long-run. Technical user stories are a thing! They must be split, handled and prioritized the same way as functional stories too. If you don’t speak up in grooming/ refinement meetings, I guarantee, other stakeholders are always shouting louder. Being a Product Owner means people are constantly approaching you, inquiring about new features or bugs. Usually, the team doesn’t do that as frequently as they should. It’s only human to listen most carefully to the loudest screaming person. You don’t have to shout at him permanently, but be verbal and tell him why your idea is good for the user. Technical tasks often address release time, stability or maintainability. You should argument to ship user value faster and have fewer complaints in the App-Store. Lastly, maybe you don’t want to bother your Product Owner too much since you see him/her struggling enough already and you feel sympathy – you need to learn, to still address your concerns!

Why a Product Owner relies on agile ceremonies

Working in an agile environment is pretty convenient, and by applying the best fitting framework, a team gets powerful tools and techniques to develop an amazing product with maximum user value. There are also very important ceremonies no team should miss or stop active participation. I’m talking about retrospectives, sprint reviews, and daily stand-ups. Use them!

It can happen that a Product Owner decides against participating, which is not good in the mid or long term. Every issue has its place and for the Product Owner, it is crucial to rely on some constants within his schedule and to not lose the grip. They are just as important to Product Owners as for developers and designer. So sometimes you need to actively demand the participation of your Product Owner and remind him, that he is part of your team! You can compare it to meditation: You know it actually is doing good to your mental balance, you probably should do it every now and then. Yet, even though it only takes 10 – 15 minutes, it somehow doesn’t fit into your day. You might be happy and thankful when you have someone who reminds you of simply doing it.

Sum Up

So what did we learn today?

• We actually do stuff that is good for you,
• we need you,
• we value your time and opinion,
• and if we seemingly don’t, we need to learn to speak the same language,
• and we need to maintain a common and constructive base, using agile techniques.

All in all, we need to keep in mind, that, even though Product Owners are mostly the only one of their kind in a team, they still are team members and not Englishmen in New York. And yes, sometimes we can be a pain in the ass, but maybe now, after reading this blog post, it is easier for you to understand.

And, dear Product Owner colleagues, if we can’t excite our team to believe in what we do, if we don’t fight for their interests, and not make them understand the “why” behind the “what”, but instead build up walls of miscommunication and distrust – we won’t stand against the competition. We need the team and we need to be strong together.

Rise and shine!

Best regards

…Hey, guys! It’s time for another blog post from me. This time I want to write about my experiences with Flutter and Dart. Every software developer is regularly confronted with new concepts, frameworks or languages, so am I. I learned to program with Android 2.0. Yes, I’m getting old… Meanwhile, I am not so active in the Android world anymore. But since we code Android apps on hackathons every now and then, I don’t get out of practice. Nevertheless, I am a little spoiled by the development of UWP apps. Also, the time on hackathons is very limited, which is why one does not like to deal with boilerplate code. Let’s be honest… Android (Java) is full of it! Therefore, alternatives are needed. Okay, so it would be obvious to try Xamarin now, but where would be the fun? I have no plans this weekend and Google seems to have created a real alternative with Flutter and Dart! Sounds like a hot date ? I’ve never worked with Dart or Flutter before, but at some point, you have to start. So this post will be about my experiences and not a tutorial.

So what are the advantages of Flutter?

Google promises not only that you can develop apps very fast, but also that they run on iOS like Android. In addition, Dart and Flutter are focused on developing reactive apps. I’ve never written apps in a reactive manner before, but at least the theoretical foundations were covered at our university. *Yes, Dannymausi I’m talking about the hipster teacher 😉 *

And what do I want to program?

I’ve been thinking for a long time what I can achieve in less than two days (hitting the gym and watching Netflix is still important!). I don’t know the language or the framework…. But yolo , after all, Google promises that you are significantly faster in developing. So here’s the idea: We’ve finished the first rotation of our blog posts. We came up with the idea that once every member of us has written a blog post we select the best and the winner gets a little something. Basically, this means we have to make a voting every 5 to 6 weeks. There is one catch: Since Danny is from Russia we have to very be very cautious about our voting system. We had so many different voting systems… I can’t even count them! We even voted about how to vote… Time to time we vote with two or three voting shares. Sometimes we have several voting rounds. Since we always discuss and try to optimize our voting systems, it’s time for an App. The app should allow you to vote for one of the five possible authors (including yourself). After you have voted, the application navigates to a second page where you can see the election results. You can not vote again. However, a new election can be started, this must be propagated to all clients.

Getting Started

So now I have two days to try out a new language and a new framework….. What the hell am I doing to myself ?? So that it won’t be too unpleasant, I decided to chill on YouTube first. Fortunately, the Google IO 18 wasn’t so long ago and there are interesting talks about Flutter. Here are the ones I looked at:

1. Build reactive mobile apps with Flutter
2. Total mobile development made fun with Flutter and Firebase

So what should you take out of these videos? On the one hand Flutter is about widgets – everything is a widget. A screen is a widget tree. One distinguishes between Stateless and Statefull widgets. But we will use the BLOC pattern from “Build reactive mobile apps with Flutter” for our app.
On the other hand, Firebase seems to offer itself perfectly as a backend. As this blog post is not a tutorial, I recommend to watch the videos. Our task is to create a Firebase database. And to create a client according to the BLOC pattern.

Implementation

The Backend alias Firebase

So this is the easy Part. Since I have already written such a long motivation, how about a gif?

How to create the Backend 😉

The Voting Screen

To keep the code manageable I decided to write all widgets in the main.dart file. In a real project you would surely divide them into different files but for experimenting, I think it’s better to keep everything at one place. Since time is limited, I thought we’d keep the layout simple. Here is my design:

Lets Check:

• We have a ListView
• We have an AppBar with Title

That’s what I call minimalistic 🙂
After I haven’t committed to any tutorial here, I don’t want to go into the exact structure of the code. Much more interesting is how we build our UI based on the authors in Firebase. First, we have to connect Firebase to our app. Just follow the instructions on Firebase or watch this video.

From Firebase to Voting

But what is the right place to read from the database? If we follow Google’s BLOC patterns, we need a stream. Using this stream, information from our database will flow straight into our UI. So we don’t have to hold a state. But what if we need information from the database? So not the information from the database flows into the UI but rather the UI pulls information from the database? To solve this elegantly, we would need a short-term memory. Therefore we will let the stream from the Firebase database flow into a so-called BehaviorSubject. This BehaviorSubject can always return the last element seen on request. So it holds our state.

Finally, we need a so-called StreamBuilder in our view. The StreamBuilder builds itself on the latest snapshot interaction with the specified stream an whose build strategy is given by a builder. So lets look at the code:

    class Bloc {
            final BehaviorSubject<QuerySnapshot> _firebaseSubject =
                    BehaviorSubject<QuerySnapshot>(seedValue: null);

            Bloc() {
                _firebaseSubject.addStream(Firestore.instance.collection("AuthorVotes").snapshots());
            }

            Stream<QuerySnapshot> get firebaseStream => _firebaseStream.stream;
    }

Here we connect the BlocClass with the Firebase Database alias Firestore

    class AuthorGrid extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final bloc = BlocProvider.of(context);
    return new StreamBuilder(
      stream: bloc.firebaseStream,
      builder: (context, snapshot) {
        if (snapshot != null && !snapshot.hasData) return const Text('Loading...');
        return ListView.builder(
          itemCount: snapshot.data.documents.length,
          itemBuilder: (context, index) => 
            _buildItem(context, snapshot.data.documents[index]), 
        );
      },
    );
  }

Here we build a widget based on the stream comming from our blocclass
But wait?! Where comes the BlocClass from? You’re right, the BlocClass itself is also a kind of state we need to have manage. Although the UI of this app is manageable and I could have passed the bloc object through the tree as a parameter, there are better alternatives. With the help of an inheriting widget we are able to reach the object from the entire subtree.

From Voting to Firebase

But How do we get updates to the Firebase? Actually, it’s pretty easy. We just have to let a stream flow in the opposite direction. For this purpose we create a stream controller in our BlocClass. The StreamController controls our stream. It allows to feed events into the stream via a sink as well as to consume the stream by calling the stream methode. All we have to do is: (1) A Click on the list submits an event to the stream. (2) Consume this stream and start a Firebase transaction at the appearance of a event.

class Bloc {
  final StreamController<Vote> _voteController = StreamController<Vote>();

  Bloc() {
    _voteController.stream.listen((data) => commitToFireBase(data));
  }

  Sink<Vote> get voteSink => _voteController.sink;

  void commitToFireBase(Vote vote) {
    Firestore.instance.runTransaction((transaction) async {
      DocumentSnapshot freshSnap = await transaction.get(vote.votedAuthor.reference);
      await transaction.update(freshSnap.reference, {'Votes': freshSnap['Votes'] + 1});
    });
  }
}

This is all we need in our BlocClass. As you can see the voteSink is the place to commit new Events to our Stream. In the Constructor of this Class, we say that the stream is consumed by a function, which is also defined within the Blocclass. In this function, we start a transaction to safely increment the votes for the author by one. Notice how the actual Author is provided by the vote event itself.

Widget _buildItem(
    BuildContext context, DocumentSnapshot document, AuthorBloc authorBloc) {
  return new AuthorSquare(
    author: document['Author'],
    imageUrl: document['Image'],
    onTab: () {
      bloc.voteSink.add(Vote(document));
    },
  );
}

As you can see we just add a new vote event. There is no logic in the UI – all is done by in the BlocClass.

Navigation

I know the blog post is getting long and I said it won’t be a tutorial. But there’s another detail I want to work out. This has given me the most stuggle and I’m sure there are more elegant ways to solve it. Nevertheless, I would like to share and discuss my solution with you. The challenge I encountered was navigation. Yeah, Flutter’s got a pretty well-designed system for navigation. But what I want is more than the standard requirements. So here a some requirements which I had set for myself:

1. As a voter, after making my choice, I don’t want to be able to re-vote.
2. As a voter, when I open the application I want to see the election results directly, if I have already voted.
3. As a voter, I want to be brought directly to the polls from the election results if there is a new election.
4. As a noob in reactive programming, I don’t want the navigation logic to be located in the view.

Well, as you can see, I didn’t make my life easy. One difficulty was to get the BuilderContext from the widget into the blocClass. However, you need the BuilderContext to create a new route. In Flutter Navigation is based on so called “Routes”. A Route is a mapping from a name to a widget. The Navigator managed this routes by adding or removing them from the navigation stack. So first we needed to get the BuildContext to the blocClass. For this we can use a BehavoirSubject again. When we create a widget, we pass the BuildContext as an event. Since a BehavoirSubject always remembers the last element seen, we are always able to navigate. Furthermore we can pass the widget we wish to navigate to into another stream. If we combine both streams, we have everything we need to navigate.

It is important that we do not use BehaviorSubject for the widget stream. We can’t remember the last widget we saw. Otherwise we would end up in an endless navigation. Therefore we use a StreamController for the wigetstream. The BuildContextStream and the WidgetStream are fed into a zipper. The zipper then packs the elements from the two streams into a tuple and the cool thing is: Since we use a BehaviorSubject for the BuildContext, we always get a context here. But since the widget comes via aStreamController, a tuple is only generated if we actually have passed a widget somewhere in our code into the stream.

class Bloc {
  final StreamController<Widget> _widgetController = StreamController<Widget>();

  final BehaviorSubject<BuildContext> _contextStream =
      BehaviorSubject<BuildContext>(seedValue: null);

  AuthorBloc() {
    Observable
        .zip2(_widgetController.stream, _contextStream.stream,
            (a, b) => new Tuple2<Widget, BuildContext>(a, b))
        .listen((data) => _navigate(data));
  }

  Sink<BuildContext> get contextSink => _contextStream.sink;
  Sink<Widget> get wigetSink => _widgetController.sink;

  void _navigate(Tuple2<Widget, BuildContext> tuple) {
    Navigator.pushReplacement(tuple.item2,
        new MaterialPageRoute(builder: (BuildContext context) => tuple.item1));
  }
}

If you look at the picture from above, the code is quite straightforward. If you want to navigate simply pass the widget to navigate to. For example, when we realize that the voting results have been thrown away:

void _checkForEmptyVotes(QuerySnapshot data) {
  int votes =
      data.documents.map((snap) => snap.data['Votes']).fold(0, (a, b) => a + b);

  if (votes <= 0) wigetSink.add(new MyHomePage());
}

You’re wondering where this code is coming from again? Easy, actually. Since we already have a stream from the database, we just have to let it flow into this function. With each database update, the system checks whether navigation is required.
The other requirements are now also easy to implement. We simply write in the local settings whether we have already selected. If so, we pass the corresponding widget the stream and already we navigate.

The Result

Time for a gif!

1. You can only vote once ?
2. If someone votes, all devices are getting the update ?
3. When a new election is started, all devices navigate to the election.?

Reflection

That’s been a great two days! Even though I had to fight with a lot of initial pain, I am glad to have chosen this topic. By initial pain, I mean trivial things like spending a lot of time for googling the basics of Dart, being depressed from simple compile errors or even setting up Flutter and Dart on my Computer. Despite still pending refactoring I am also relatively satisfied with the code. Even if I will hate myself for this code in a month 🙂 The concept behind Flutter is simply great so far! Personally, I find the development experience much more satisfying than vanilla Android with Java/Kotlin. I also liked Dart as a programming language very much. I liked the tooling around Flutter, too. By the way, I used Visual Studio code.
Well I will surely change some code and build some model classes. Also I didn’t care about the design yet. But there seems to be still a lot to discover here. After all, Flutter is there to build beautiful apps! I am not yet satisfied with the navigation either. For example, I don’t like my solution, which is waiting for an update of Firebase (also for the device that requested a new voting). But you will certainly read more of me and Flutter ❤

Feel free to check out the GitHub repo

So as we sat down to brainstorm about possible projects we came up with one that solves one main issue in the charity-ecosystem, connecting the concept of blockchain with charity – two worlds connected – we called it “Chario” and registered for EXXETAs challenge.

We developed an app for middlemen (Agents) and a web page for benefactors, both connected through a backend that facilitates the data between them. With our system, we enable benefactors to choose where exactly to donate to, then chose one out of several possible donation-types (material or money) to finally trace the donation throughout the process, till it finally reaches the beneficiary (proven by a photograph). After 24hours of creative teamwork, coding, struggling and getting-shit-done, a huge amount of coffee and a 15 minutes pitch to the EXXETA team we were done, and yet we somehow managed to hold on till the very end. Don’t underestimate the pressure you’re feeling and the effect of sleeplessness on your nerves when you didn’t sleep for around 36 hours, facing a pitch in front of 200 people. Somehow, we gathered all our inner forces and simply just performed. The rest still seems blurry somehow: We didn’t expect to win anything, so we were surprised, yet very very happy and thankful as Matt was standing on the stage, shouting out our name, saying we won the Category-Price “Connect the Worlds”:

Not knowing what huge effect this prize will have on our team experience and future plans… in this blogpost, I will try to give you a small insight of what we learned. Be aware though, this is just one brick on the wall. There were side-stories and a lot going on between us, the other participants, the amazing EXXETA team, Berlin, clubbing, cocktails, accommodation issues, and so much more… all in all, this was a trip we’ll hopefully never forget.

What happened so far?

Obviously, our EXXETA-Go-To-Guy Matt couldn’t wait to get the workshop started, so he directly added Danny and me on LinkedIn. Quickly we exchanged email addresses and phone numbers. We agreed to make a call with all Billige Plätze on Skype which turned out to be casual and welcoming, our excitement grew. In the aftermath I can only assume how much energy went into planning and organizing the workshop, in the background Matt and his colleagues must have started right away – impressive – what an eager team! Soon they sent us successively more and more info about what’s about to come. The last notice was, that we should re-prepare our pitch from the hackathon. Like most of the projects born at hackathons, there has no further work been done for Chario, even though it was, like all the times, also a project we’d like to keep working on… Since only Dominik, Leon, Danny and I attended the hackathon and won the price, it was more than just nice that they also invited the rest of our real Team “Billige Plätze”. Hence, all of us are on the way to Berlin right now, looking forward to the next days and experiences.

And as we are on our way to Berlin now, I’m getting started with this field report, my diary of our experience of the workshop with EXXETA…

Who is EXXETA?

With more than 750 employees EXXETA AG is a big international player in Technology Consulting for the Energy-, Automotive- and Finance sectors. They have several offices all around Europe, most of them in Germany. The team that invited us is known for innovative and unconventional, yet successful methods and measures to get things done. They are situated in the WeWork Coworking office in Berlin – next to the Sony Center. During the workshop, we got to know a few colleagues of Matt and were amazed by the casual, young spirited, yet professional style.

Day 1

The Factory

We were a group of 12 plus the EXXETA coaches. First stop was the Factory. The Factory is an amazing Coworking space for innovators and startups that grow a community by carefully choosing who joins the network. Not only are the offices well designed and furnished, but also it scores with features like a ball pool, foosball, huge kitchen with coffee for free, space for networking and getting to know like-minded people. There we met the IoT and Blockchain company builder Next Big Thing.

Meet&Greets

Next Big Thing – What does a Company Builder do?

Next Big Thing (NBT) specializes in IoT and Blockchain startups to give them a quick and smooth start. This is especially helpful when it comes to startups with hardware-based innovations. NBT supports a startup not only with access to a big network of startups and investors, but also pays you a fair monthly salary and helps you to deal with topics like IT-security, technical certification and standards, legal regulations, bureaucracy, HR administration, accounting, marketing, pitch-coaching, recruiting, office infrastructure, workshops and much more. Also, they have a highly-specialized senior developer team, supporting you with additional operative workforce to get your product onto the market. They developed a program called “Venture Design”, where NBT leads you through all the necessary steps for building your own company. My key learning of this visit was, that all of their startups ended up with another product as they actually began with. Therefore, they rather decide on a team or person, than the idea that got pitched in the first place.

Entrepreneur Alexander Barge

Next station was lunch, where we met Alexander Barge. Alex is a highly experienced Entrepreneur and deeply integrated into the Berlin startup scene. There we had the opportunity to place our questions in a personal atmosphere and get first-hand advice. So after we got introduced to the complexity of founding, Alex managed to motivate and encourage to start something new, thanks to his enthusiasm and up-beat. As a CTO and Co-Founder himself, he made it clear, that you can “just start”… of course it is a lot of work, and you will never lose that bad conscience of “actually I should be doing something” whenever you’re not working, and eventually you’ll fail at the beginning – but there will be progress, excitement, a lot to learn and eventually a chance for success. It seemed a bit like what I told you in my previous blog post (“How to start and learn coding”) – all you need to do is get your a$s up, start and stick with it as much as possible. So next to the delicious food we dined that fantastic enthusiasm.

Blockchain Lab at GIZ

Since the Chario-Concept was driven by a non-commercial idea and we mentioned the idea should be realized with blockchain-technology, the next stop was the Blockchain Lab at the GIZ (German Corporation for International Cooperation GmbH). Franz von Weizsäcker and his team are trying to find sustainable use-cases for blockchain technology. With the technology of Blockchain, it generally feels a bit like there is a solution without knowing the problem it can solve yet – so it needs specialists like Franz(s team) to find out where to place this technology without risking an alienating effect.
We asked what they think about our idea and if it seems realizable. The answer made clear, that in the charity-ecosystem there is a big resistance towards change, especially when it means that i.e. middlemen might earn less than before – yet, the use-case of connecting blockchain-powered traceability with donations is very promising and powerful.

After a short break and retrospective come-together, Matt introduced the first canvas to get a business model sharpened.

Working with the Value Proposition Canvas

We started with a canvas which is supposed to help to focus on the user’s needs and then find possible solutions. Here you can find a nice and simple explanation of the canvas:

How we did it: Field by field, we were timeboxing silent brainstorming-phases of around 3-5 minutes, where everyone wrote the ideas on Post-Its. Followed by putting those on the canvas, one by one. Each session continued with a short discussion about discrepancies and different opinions until we go to the next field.
We were working through the canvas in this order: Jobs => Pains => Gains => Pain Relievers => Gain Creators => Forming the products and services. The moment you are done with the canvas it is useful to go over it again, cluster it by topics, and at the end prioritize the features to decide whether it is an essential part of the Minimal Viable Product (short MVP) or not. Here is our result – a bit messy, and yet we all like it:

Our First Little Pivot

Within this process, we figured out that we got to change something about the product-idea since there are two main issues

• Issue one – Transparency: Why would non-governmental organizations (short NGO) and their middlemen cooperate with us to make the effort and implement transparency features in their processes?
• Issue two – Proof of good work: How can we know who needs the donations?
  We learned that a service/ system or product that solves all the issues would be too big as a start, so we wanted to pin down possible features for an MVP.

And even though we found possible solutions for those two issues, we realized that none of us are somehow eager to dig deeper into any of them. Motivation is key! So based on our first result we decided on developing a system that motivates future benefactors and helps NGOs to raise more money. The idea went a bit into the direction of something like payback for NGOs, but better… of course 🙂

After an exciting first workshop day, the team ordered pizza which got accompanied by insights of EXXETA from the development team leader Sébastien Jelsch. He was stating that, if you don’t want the insecurity of a startup, yet work alike, in a team of people who want to make a change, you may check out what’s in the job listings on their page 😉

Day 2

The second day was all about getting our first business model-draft done. After a short tour through the amazing Coworking office WeWork, we got to work, more focused than ever, quickly filling up the Value Proposition Canvas and sharpening the concept.

Business Model Canvas

The Business Model Canvas is a lean method to nail your business model down to its core. Find out more about the canvas here:

We easily went through this canvas. The product and the organization around it was clear to us, so there was hardly any reason for discussion. The Value Proposition Canvas was a perfect preparation for this one. Here is our result:

The next step would be to go over it and distill the core out of our brainstormed-content.

What is the LVLX Summercamp?

During our lunch break, Matts boss came around, wanted to know how we like the workshop and told us about the LVLX Summercamp. It is a paid six-weeks-program for (mostly) students who want to focus on their idea or product and get supported by EXXETA and their “high-society”-partners. If it wouldn’t be so entirely impossible for us to take part, we had not hesitated one millisecond. I’ll be following the outcome of that workshop, knowingly that all the potential they gather and own, there got to be some pretty impressive results.

One Metric That Matters (OMTM)

To get back to work Christian Grimm from EXXETA gave us an important side note: Focus on the right thing is essential for the success of all the phases a startup goes through. And the argumentation is simple: You don’t have a lot of resources and time, so the only way you can get more of each is by using the bit you have for the right things. Defining one metric / KPI can drastically help to consequently align the work and focus of a team. In the beginning, it’s the key to look for “softer” or money-unrelated KPIs, like positive/ negative-feedback-quota or percentage of MVP-features, developed, rather than sales or ARPU. If you are interested in reading more about this, I can really recommend this blog: Lean Analytics Book.

The Timeline

With this at hand we managed to finish our first self-developed Business Model Canvas, and so we moved on to the last part of the conceptual day: the timeline. Nearly as easy as it sounds, you define three time-intervals and decide for each of those phases your goal, invest, team size, OMTM, hypothesis, important tasks, open questions and possible obstacles.

Intrapreneurship

The following talk of Philipp Stork was about a question that big companies started asking: “Why can’t we be as quick as a startup?” The phrase “Intrapreneurship” indicates that those companies should develop an entrepreneurial mindset within its employees and empower them to pursue their demand for creating something new, in the name of the employer. This sounds like a pure win-win situation, you maybe think? Research shows that there are companies that fail to implement a startup character within a motivated team, or sadly still don’t want to see this “unconventional” method as a valid solution. Yet when a company goes that way and really empowers their Intrapreneurs, there is a chance of success.

Entrepreneurship

Since most of the meet&greets, talks and tasks of the workshop were about sharpening our concept for a possible startup, in his keynote, Matt managed to find the right words about what it takes to be an entrepreneur. He broke it down into three main-skills:
1. Think outside the box: Because there will be moments you couldn’t foresee, and you have to react, there will be problems you have to solve creatively and pragmatically, you got to be able to improvise and surprise!
2. Be focused: Just as mentioned before – use your resources effectively. As an entrepreneur you can only set small accents, yet if you place those correctly, you can make a change, because you have the freedom from all the internal politics, bureaucracies, hierarchies and everything else that slows down bigger companies, but a big chunk of motivation, team-feeling, including the responsibility to quickly launch your product with the available resources, and beat incumbents to market.
3. Don’t get discouraged: Especially after the first few days / weeks it comes again: The daily business – just like in a relationship, you will have to make the transition from “having a crush” to “being in love”. On a journey as a founder, you meet a lot of naysayers just as sure as failure will happen. This should never be a reason to think about stopping, but to stand up, learn from mistakes, filter between good and bad advice and have the courage to learn and maybe change a plan quickly.

There is plenty of literature about how to get started with your startup. Here is a Must-Read for anyone who is actually thinking about it: Startup Playbook by Sam Altman.

Afterward, we sat down and enjoyed a wonderful cold beer in the Coworking space WeWork, where we stayed a bit longer, till we finally had to leave, and the evening celebration got started.

The Sum Up

So what do we take away from this two wonderful workshop-days?
First of all, we gathered a lot of insights when it comes to founding, depending on what product you work on. Secondly, we developed an idea that we might pursue in the close future. Thirdly the EXXETA team managed to pack our bags with the right tools to work on further ideas, what we’re going to try out at the next hackathon or other future projects. Last but not least, we got a glimpse of the Berlin startup ecosystem and found a lot of new friends – all of us were purely amazed! We, the team Billige Plätze, had a very fruitful, intense and important time with each other, bringing us together more and more. Who knows what maybe getting started thanks to this experience…

I ended up making a huge move to break out, relocated and started my second undergraduate studies in the fields of mechatronics and computer science. Retrospectively, this was not the best solution, but at least, it was one. One reason why this had to be so radical was that I occurred to not be aware of sufficient other possibilities to extend my knowledge and skillset adequately. My actual inner vision and motivation were to build up a skillset and to be able to create my own products, i.e. apps or smart-solutions. Thus, a whole second study-program was a bit too much. Programming though was highly interesting because it promises to empower you to reach this goal!

So in this blog-post, I want to address two main learnings of mine, in the hope that you don’t need to make the same mistakes, but get a great head start to learn a specific hard skill, like programming:

• How to get into it?
• Why you should consider E-Learning

To learn programming turned out to be much easier than you maybe think. No need to start over again, no need to stop what you’re doing and you don’t need to start second studies either – but of course, nothing comes from nothing!

How to get into it?

Don’t be delusional

Learning to code is comparable to learning a new language. It will be complicated sometimes, it requires effort, endurance, and continuity. There are parts you won’t like, and parts you’ll love to do. I experienced moments where I simply didn’t want to go further, even though I knew, it’s just one rung of my latter to live my dream. As long as you don’t stop there, those moments pass and so are those tasks. But of course, nothing is perfect, so you can expect that even your dream isn’t as romantic as you want it to be.
When you expect results quickly, you should plan a lot of time and nerves. The more frequently you “speak the language” the more familiar it feels to you. Roughly estimated the latest after 6 focusing months you can code on a pretty satisfactory level!

Set a goal

There are several motivational factors when it comes to learning, of course. Something that extremely helped me was (and still is) my goal, to get my own ideas into life, as apps. I have clear products in my head and they are waiting for me to get them done. During my learning process, I quickly reached the moment when it got crystal clear why I should learn what I learn, what I can do with the new knowledge and how I could use it in my personal project.
So set yourself a goal: An app, website, portal, game or program you always wanted! If you don’t have any clue what your product idea could be: Talk to people, really anybody, and ask what kind of product they always wanted. Once you found something, keep talking about it!
The more you discuss it with people, the more present it is in your head and the higher the motivational-effect will be!

Hands-on!

Before you go all-in, you better get yourself informed. With “informed” I don’t suggest to talk to people, read magazines, blog-posts or flyers. Instead put your hands on code asap! If you have a goal and decided on a platform (android/ios/windows app, webpage, or so) you have several options to choose from:

• Udacity,
• Codeacademy,
• SoloLearn,
• Khan Academy,
• The Odin Project,
• Free Code Camp,
• edX,
• Udemy,
• Video2Brain,
• Video tutorials on youtube or
• simply search for “my first …”.

Learning to code never have been as easy as it is now! So just start anywhere. You might switch from one to another platform after a few lessons, but that’s part of the process, don’t worry! I decided to learn Java and write my own app, so I ended up with Udacity for now, which is simply amazing! The best part about E-Learning-Platforms is, that most of them are for free and the moment you’d have to pay for something you already know if it’d be worth it, but more of “why I happily ended up with E-Learning” in the second part of this post.
In my opinion: You don’t need to learn the theory before starting, just work towards your goal!

Get involved

Better sooner than later! There are hardly any reasons why you shouldn’t participate in a hackathon right now already. Even though the name says otherwise, hackathons are not about delivering code or hacking a technical system. It’s rather creating ideas, designs and creative solutions for whatever topic. Anyone can participate: Presentation- or design-skills are just as wanted as programmers or creative folks. It’s mostly for free: food, drinks, contacts and a lot of experience are provided. I found this amazing group (Billige Plätze) and we managed to take away two rewards out of three hackathons so far, in which I hardly committed any code! And then: the moment that you notice that you actually can participate coding will be epic – believe me!

If you don’t happen to have the time or stamina for hackathons, you will be surprised how many Meetups take place around you. Plenty of “Python from zero to hero”-like courses might take place somewhere around you. Check out this app, as a starting point to get involved:

• for Android: link
• for iOS: link
• for Computer: https://www.meetup.com/

Why you should consider E-Learning

Studies and other “classic” possibilities, like apprenticeships, retraining courses or workshop-series’, mostly come along with a bunch of problems which can turn your motivation into desperation. Of course: (under-)graduate studies and/or apprenticeships are very important stages of one’s career. But you simply shouldn’t expect to get out of there and automatically learned programming. You’ll hardly learn hard-skills, like coding. And yes, …E-Learning is (so far) not a proper official equivalent for your first educational path, yet it may helps you to add that little special something to you CV and empowers you to prove your worth.

On my journey, during the second studies, I faced four main problems:

Money

To start over and/or start learning in a classical way is very expensive. Whether you end up with debt, no sufficient or fewer earnings, or unjustifiable costs. On the one hand this may be a good motivation to get it finished quickly and efficiently, but on the other hand it’s not always so easy to “get through” with either (…also, your goal shouldn’t be to “get through with it” as fast as possible, but to make it as effective as possible!). A lot of E-Learning-Offers are for free, have only some premium-features or are pretty affordable.

Tests

Nearly all the classic learning systems contain tests of some classic sort. There will be exams, working papers, (if you’re lucky) projects and at the end, there is this one person telling you if you managed. The result is nearly always the same: Within a (relatively) short period of time, you got to learn or do a lot of stuff. While most of this stuff potentially is crap, you probably stumble upon a few interesting topics, but you’ll lack the time to dig deeper into it. In my own humble opinion, the main problem is, that this system requires you to prove your learning-curve in the blink of an eye, metaphorical speaking. You will never have to do that when you’re actually coding, for example. With programming, it’s mostly the other way around. A lot of E-Learning-Solutions, if they have some sort of test, find proper solutions. That’s where concepts like gamification come into play! Mostly E-Learning-Platforms manage to guide and go with you on the journey and notice your development along the way.

Stuff you don’t need

The main goal of studies and other classic-learning-options are not to make you a specialist or practitioner of some profession. You end up with a lot of broad knowledge (if you don’t forget it again) and somehow not having reached your goal to be able to get something done. Studies, let alone, are not making a programmer out of you, it’s rather the activities along with your studies that can make this transformation happen. I’m sorry to say this, but if you want to learn to code, you don’t need Laplace-transformation, Fourier theory or partial integration. The moment you’d need stuff like this, you are already in spheres where you will and can learn it. If all this broadening-your-horizon would be a small part of the studies – ok! Unfortunately, it’s consuming a huge amount of your time and energy. With E-Learning-Programs you can choose the content yourself. For a profession, like programming, there’s a huge portfolio available. It’s quite likely that there is at least one platform that’s using the right methodology and practices for you.

Sacrifices

When you build up your life, you gather more and more materialistic, emotional and social attachments. Putting effort and willpower into learning something new can require a lot of your (current) life. And at some point, I ended up feeling like having to say “no” to everything I’d actually like to do. I sacrificed a lot, due to a guilty conscience or simply learning pressure and stress. E-Learning-Portals mostly let you choose your own pace, give you soft or achievable due dates, and, if well made, still help you to easily stay on track.

Believe me, going all-in, like I did, may sound romantic, enthusiastic and brave… but those are no actual arguments. I’m not saying second studies or classic educational paths are always the wrong way, just don’t consider them the only or best one to learn something new, that seems big now.

So as you may have noticed, the main part that’s holding you back from achieving your goal is you. This border of “not knowing how to get started” is only in your head. Go through my advise, step by step, and you won’t even notice the moment, when you pass the line, that first seemed so far away. Grab that keyboard and let your own show begin. Hopefully, I managed to be the drop on the seed, and you will let the plant grow!

If so, see you at the next hackathon 🙂

Sören Hemken