Wednesday, February 22, 2017

Stop Starting, Start Finishing

In a previous post I told the story of how we reduced our bottlenecks when I was working on two teams last year, and how we achieved to deliver the highest priority items first to our users. How? Both teams agreed to "stop starting, start finishing". To not pull any new story before you could not contribute to in progress stories anymore.

This lean approach worked so well! Unfortunately only until I handed over my second team to another tester. As soon as I returned full-time to my original product, the whole team fell back into old habits, starting work on new tickets while other tickets of higher priority were still in progress. At one point we even had a totally underestimated story which turned out to be an epic of its own; we dragged it from sprint to sprint and heavily struggled to finish it. Not that the team members did not want to support, but support was only provided on demand. With "on demand" meaning that you had to actively ask for it.

Beginning of this year, we faced long feedback cycles again. Too long for our liking. New features waited for input from our Product Owner. Code waited to be reviewed. Topics to test piled up. The situation wasn't too bad, but we felt things could be much faster and we generally should avoid to have half-finished tickets lying around, not providing value to anybody. So what caused this situation again? Sometimes the long waiting times were due to the fact that many of us are also involved in company-wide topics of our FlixTech organization, for instance to support our new chapter structure or recruiting new team members. At other times people just grabbed new topics to work on; not having bad intentions, but just being eager to work on something new.

In our sprint retrospective two weeks ago, we brainstormed ways to shorten our feedback cycle again. And came up with the same well-known approach which had already worked so well for us last year: Stop starting, start finishing. Whenever you finish something and have free capacity, ask the whole team if you can support someone else with their current work. Only if you really cannot support anybody, pull a new ticket. And now actually adhere to it!

The past sprint proved once more that this whole-team approach is highly valuable. The sprint went so smoothly, tickets never waited long for feedback and could be delivered to our users as soon as possible. We completed all of our highest priority topics and even many more smaller items on top. Team collaboration felt great and everybody was really supportive. It just worked; even though I could not cover testing for a whole week due to a lot of other important topics like recruiting interviews and the two workshop days with our users (it almost felt like I've been on vacation). My programmer teammates took over testing thoroughly, asking me for advice whenever needed, but proving they already learned a lot about testing. Simply awesome. So proud.

Maybe it's too soon to be proud, as we only adhered to this approach (again) for one sprint. What makes me think that this time is different is the following: No one waited for someone else asking for support. Everybody actively asked if they could support anybody and readily provided that support until the related ticket had been finished. We all agreed that the sprint went really well and we want to stick with this approach. I'm full of hope.

Tuesday, February 14, 2017

Meeting Our Users for the First Time

My team is developing an internal custom product for our company. This means, we only have expert users and we know exactly who they are. Well, you should think that at least. Truth is: We don't know them well enough. And although we're all working for the same company, we have never met.

The same applies the other way round: The users of our product don't know who we are, who is actually implementing this new feature or causing that issue they just found. Well, our user base grew a lot. And our development team evolved a lot as well during the last two years, with new team members joining, and others moving to different products or even leaving the company. And now we only have one person in the team left who had met our users once; a longtime ago.

To start growing closer with our users again, we agreed on the following two initiatives:
  1. We want to have our power users and stakeholders again in our sprint reviews to get their instant feedback. Yes, we know it should always be that way - but truth be told, we had separate "team reviews" and "stakeholder reviews" during the last 1.5 years. Our product owner did a great job communicating user feedback to us, but something was missing. Having direct feedback right after each sprint is simply awesome for both sides.
  2. We agreed to have pairs of developers go to Berlin and visit our users for two days, round robin style. So every developer has a chance to meet them, and they have a chance to meet each developer on the team.
Last week Thursday and Friday it was time for our very first visit! One of my teammates and I took the first round. We were excited to get to know the persons behind "the users", their everyday challenges and how our product might (or might not) support them to solve those.

Although our visit was quite exhausting considering the trip and all the pieces of new information, it was worth every minute. Our product owner did an awesome job preparing our stay and striving for maximum outcome for both us and our users.
  • Big picture presentation. Our visit started off with two power users presenting what their job is about, what their work looks like throughout the year, the challenges they face, and which tools they currently use. It was a great roundhouse kick to show us the big picture, have first questions answered, and get us started in understanding what they actually need.
  • Sitting with the users. Throughout the two days we used our multiple opportunities to sit next to our users while they were actually trying to solve a task at hand; some with our product, some additionally using other products, some not being able to use our product due to certain constraints. This learning time was invaluable for both of us. We directly saw which problems they faced. We saw which of our product features they used to solve it. We saw which of those features they knew about, which of them not at all, where they stumbled, what they liked, what they cried for.
  • Power user meetup. Our product owner invites the power users every other week. This time we could join them and listen to the presentation of newly released features, to questions and answers regarding future implementations, the presentation of a user survey's results. Besides the big epics we're currently working on, the power users also have the chance to vote on their "user favorite" for our next sprint; a rather small but dear feature which would make their lives easier and which fits in between the stories for the big epics. This way they can not only help guide development by their feedback, but also directly influence prioritization in a small scope.
  • Story mapping workshop. To close our two days' visit, our product owner hosted a story mapping workshop with a few users and us. I read the book "User Story Mapping" by Jeff Patton some time ago but never had the chance to attend one of those workshops, so I was really looking forward to it. And it was great! As proposed in the book, we first completed the simple exercise to map what you did this morning after waking up until you left your apartment. It really conveyed the method pretty well! Then we tried to map a real-life user scenario. And my group stumbled. What was easy during the exercise where we shared the same language, proved as difficult when it came to implicit domain knowledge. When the users told the story using a lot of domain language terms, I had my troubles to translate their meaning to my own world of thought. So I asked a lot of those "dummy" questions until we finally were able to map the required actions in a way that I understood them as well. This revealed a lot of implicit knowledge on both sides and helped us to a better understanding of what is actually needed to solve the scenario.

What about our lessons learned?
  • The well planned schedule worked out really well; it was a lot of new information but not too much, enabling us to learn a lot.
  • Now we know many of our users face-to-face - and they know who's behind that product they use every day. I know from experience that this will make future collaboration so much easier.
  • We learned that we are actually working on the most important topics for those users - how great to hear! And that they loved the things we just released. Simply awesome!
  • The two days in the life of our users provided great insight in how we could develop our product further to support their challenges even better.
  • We shared a lot of implicit knowledge; not only the users with us, but also the other way round. For instance that our team does not consist of the 15 developers they thought of, and what technical debt is all about.
In the end, we shortened the feedback cycles with our users. Both my teammate and I are pretty curious what our other colleagues will tell when they return from their visit. And we're already looking forward to our next turn! :)

Thursday, February 9, 2017

It's Hacking Time!

Last week FlixBus hosted the first hackrday for the whole FlixTech organization. Although learning on the job and during working hours is appreciated and encouraged in our company, our teams used their so called "innovation time" quite differently. Some attending online courses, some reading blog posts, some learning new tools, some implementing a new feature they thought of. Many of them on their own. And many more just skipping the time in favor of getting things done. You know, the "real work".

So it was time to start an initiative to:
  1. Actively and transparently value learning.
  2. Give a dedicated environment and the explicit permission to invest time for learning.
  3. Collaborate across teams and locations to get everybody closer.
  4. Spark innovative new product ideas or try new development approaches.
  5. Have fun together and celebrate us as a company!
The idea: Every first Friday of the month is now officially hackrday! The motto of our first one: "Build something fun connected to FlixBus". Follow me on my journey of our very first hackrday - when none of us really knew what was going to happen.
hackrday preparation

In the Morning

Looking forward to our first hackrday for days, some of my team members came up with a great idea what to build and I was eager to join. But when I came to the office that Friday, I learned that exactly those team members were not able to join the hackrday due to different reasons. That hit me quite unexpectedly and my "cannot wait for it" emotions suddenly turned into bad mood. And I started thinking about not joining hackrday as well to show support for my colleagues; but knowing I would regret not to experience the very first hackrday. Instead I convinced myself to at least listen to the other ideas being pitched and see if I like one of those.

As I entered the event location, another team I accompanied last year invited me to sit with them. And instantly improved my mood by providing some sweets - they know me too well! ;)). That team wanted to do what I had been looking forward to do with my own team: have a team project to work on, as a team. They kindly had me on their hackrday team as well. So I stayed; and did not regret it.

The Hacking Phase

When you consider the time required for introduction, pitches and demo sessions, having only one day did not leave much time for actual "hacking". So we had to use the time as efficiently as possible to have a maximum of valuable outcome at the end of the day.
  • We got everybody on the team on board what the idea was about. We actually planned a minimum viable product which could serve as standalone solution or be integrated within some of our current products.
  • We brainstormed what would be minimally required to implement for that product.
  • After having a first common vision, we decided to split up and have sub-teams focus on different areas to develop that very first prototype.
  • Then...
Well, and then one of our agile coaches approached us, asking the very essential question:
"Why do you assume that there is a problem for the solution you want to build?"
Oh yeah. Well said. We were so keen on realizing our idea - we forgot about the basics. So we adapted the plan.
  • The team's product owner and me set out to validate our hypothesis that the problem we thought of actually exists and that our tool would be able to solve it. We identified a set of questions which we assumed our potential users would answer positively; if so, our hypothesis would be validated.
    1. Have you been in the situation that you had to do X?
    2. How did you solve it?
    3. How happy have you been with your solution?
    4. What would you wish for?
    5. Do you know of any tool which would make things easier?
    6. Would you give us your email so we could inform you about a new solution?
    7. Any further remarks?
  • We went through our office, asked several colleagues of several departments those questions - and quickly learned many of them had been in the defined situation but they did not have had a problem at all. They were really happy with their solutions!
Acknowledging defeat, we returned to the rest of the team and told the news. We knew that the number of persons we asked were not sufficiently representative. But it was clear enough that if we thought about a productive solution, we would definitely need to get real data from our actual target group to find out if they really didn't show any interest as well. Well, as this was hackrday and about learning and fun, we decided to continue with our idea anyways.
  • Next up we created some very simple UI sketches on paper, depicting a simple workflow through our envisaged product. Cut them apart. And again set out to get early usability feedback from our targeted users.
    1. We told them a scenario they should solve.
    2. We asked them to think out load.
    3. We gave them the paper landing page.
    4. And observing eagerly how they interacted with the paper product, trying not to give any hints, collecting their feedback.
  • After doing this with only two persons where one heavily stumbled and the other even broke out, we had so much invaluable feedback already that we decided to stop and and re-design our product.
  • So we draw more sketches, adapted things our users stumbled upon, added missing navigation which got them lost, and solved other unexpected issues.
  • And while redrawing, without showing our next versions to any other users, we suddenly started to ask further questions ourselves. Is that feature really needed? If I enter this here, I should see it there... Hm, how to get back? So we instantly minimized our paper product even further.
  • Back to another round of usability testing! And again, our users asked many valid questions and had a bunch of awesome feedback to improve our product.
  • Then the other tester on the team came up with a stroke of a genius: While we were still focusing on paper, we forgot about all those tools for prototype testing and mockups which are out there! She used Marvel's mobile app to take photos of our paper prototype and linked them together to make it come alive and show the workflow. As time flew by we unfortunately could not have another iteration with users giving them this digital prototype. Would have loved to see their faces!
During the whole day we checked in with the team at least every half an hour, sharing our latest insights about the next best minimal solution. The team took them as input to build a very first backend prototype plus some UI parts. Hacking time quickly came to an end and we hurried to prepare a short presentation of our results so far - flying high on an adrenaline rush!
hackrday demo title hackrday demo hypothesis hackrday demo paper prototype hackrday demo mockup hackrday demo implementation

Lessons Learned

When each team demonstrated their prototypes, we found that many of them thought not only about fun stuff but about delivering business value with their ideas. Sharing our team's story how we identified our hypothesis as invalid caused laughter, but also taught some invaluable lessons for product development.
  1. Always test your hypothesis first. (We should have know better; we heard a talk about hypothesis-driven development only some weeks ago...)
  2. Assume your assumptions are wrong!
  3. Cut your product down to the absolut minimum. And then minimize it even further.
  4. Prototype quickly, test quickly, get fast feedback.
But we learned even more from this first hackrday.
  1. Personally I learned to validate my expectations as well. It's not about me or my team; the day was about learning and collaboration across the whole FlixTech organization. Glad I realized that in time.
  2. A low-effort presentation with handwritten slides supported the key messages of our 5min timeboxed demonstration really well. And it was worth shortly practicing it before doing it on stage.
  3. Due to the given time constraints, we felt the pressure to deliver in short time. We learned that we actually don't have as much pressure in our everyday work, even though it might feel like it at times. Despite the short time frame of the hackrday, we kept experimenting and learned so much valuable lessons by doing so. There are simply no excuses to not integrate experiments in our everyday work.
  4. We split our team to focus on different activities; but in the end it would have been worth to try mobbing for all tasks at hand. To not run in the wrong direction and waste time, but to avoid feedback cycles overall.
Oh and we have a lot of new ideas we would love to try. We're already looking forward to our next hackrday!

Wednesday, February 1, 2017

Great Place to Work

Remember my colleague asking me to include more images in my blog? Said colleague also asked me why I never mentioned my current company. Nothing would speak against it - we really enjoy working here!

So far, I shied away from publicly naming any companies I worked for (though of course you could look them up in my professional profiles). Maybe it's due to the fact that I rather follow humans than corporations. Or that I prefer to read stories about humans. Or that I quickly pull away when it feels like someone's trying to sell me something.

But he is right. We really enjoy working at our company, with so many awesome people, building great products for our users. And it's a shame we're currently having problems to find more of those awesome people fitting to our mindset and culture. To be honest we really could need some shameless advertising to attract more people and let everyone know we're a great tech company!
Finally, to make it public: I am an agile tester at FlixBus! Our vision is smart and green mobility for everyone to experience the world. Have you seen green buses lately on Europe's roads? If not yet, expect to see them soon! ;)

Before you say "Wait, buses...?" - although it might seem the most obvious, we are not a bus company. We do not own any buses, we have no bus drivers employed. The whole bus part of the business is done by our bus partners. However, we bring people and buses together! We are taking care of the logistics and technology part of of the business. And to do so, we're developing several products.
What do I love about my workplace?
  • Freedom. Within our product teams, we are free to chose whatever we consider most appropriate for our product. We go for new technologies and development approaches, sparking innovation wherever we find it!
  • Openness. This may be taken for granted sometimes, but for me it's crucial. And it's only possible by having trust! Speaking of which:
  • Trust. One of my most favorite lines of our CIO Daniel Krauss is that you don't have to earn his trust; you have it from the beginning. And he really lives up to it.
  • Responsibilities. Take over any tasks you want. Bring yourself in and contribute wherever you can provide value.
  • Opportunities and focus on learning. You can change to other teams, positions, grow in any direction you would love to grow. You just need the urge to learn and develop yourself.
  • Team collaboration. The whole-team spirit! We encourage full-stack developers, including spreading DevOps, UX and testing knowledge. Remember the bus factor?
  • Deliver high value to our users. We focus on solving our user's problems and making them happy to work with our products. We strive to get their feedback fast and frequently to guide development. 
  • Flat hierarchies. Our teams are truly self-organizing. Did I mention we don't have team leads anymore? We're focusing on lateral leadership. Step up and lead by example!
  • Multi-cultural. Our people are coming from all over the world! My department of 28 persons alone lists 13 nationalities. Not to speak of the different cultures we all belong to or varying backgrounds we have. Bringing different perspectives together creates awesomeness!
  • Fun. Hello table soccer, hello mini-basketball, hello whatever the next of us brings on! We code hard, but we play harder. ;-)
  • Community. Share your story, spread knowledge, inspire other teams! But also get feedback and support when you're facing challenges.
  • People. Well, in the end everything is about the people. We're enabling people to experience the world. We have awesome people to do so. And we need more of those to tackle the challenges ahead.

Speaking of challenges, we're facing some where we need help on:
  • Agile transition. Some teams embrace agile at their core since the beginning, others are just starting on their agile journey. It's fascinating being part of this change and being able to contribute to the bigger vision and creating our very own company culture!
  • Close collaboration across locations. We're located at many large European cities: Berlin, Munich, Paris, Milan, Zagreb, Amsterdam, and still spreading. But this also means we have to find innovative ways to stay close to each other.
  • Scaling our products. We are working on several products, some bigger, some smaller; but all shall gain strength.
  • Growth. We want to grow: our teams, our products, our business! But still keep the agile startup spirit alive. To do so, we need your support!
We are searching for all kind of people to strengthen our development teams.
  • Join! Are you eager to join an awesome team & develop great products together? Then check out our career page and current job offers! I'll be happy to answer any questions in advance.
  • Feedback? Do you have any feedback for us how we could improve our recruiting? Please leave a comment or send me a direct message on Twitter.
  • Tell :) If you know anyone else in your network who's ready for a new challenge, please spread the word!