Showing posts with label product. Show all posts
Showing posts with label product. Show all posts

Monday, September 3, 2018

Testing Tour Stop #18: Mob Exploring with Amitai and codecentric

This stop on my testing tour was really special. Why?
  1. I saw Amitai Schleier again! We had read each other's tweets since longer and first met in real life at the Mob Programming Conference 2018.
  2. Amitai went on a coding tour this summer, joining several companies for one week each to learn together (find more about it on his blog). Most of the tour happened to be in Germany, and the last two days in Munich at codecentric. He knew about my testing tour and imagined us to have a common stop in my home town.
  3. We mobbed. My original hypothesis for my tour was about either pairing or mobbing, however, I only had the chance to pair before.
  4. The people on the mob identified as developers and had no experience with exploratory testing. My tour was about learning from testers, still, this promised to be interesting. I did not join the mob myself but stayed the facilitator. Though my tour was about hands-on testing, with me included, I learned a lot about teaching testing.
  5. My previous stop with Simon Berner was about pairing and mobbing itself. Only a few days later I could put our exchange into practice!
At first I saw this session as guest visit on Amitai's coding tour. Amitai, however, wished for counting it as stop on my testing tour as well. Even though I was not on the mob myself, this indeed felt like a bonus stop on my tour. So be it! :)

Setting the Stage

Amitai and Thorsten Brunzendorf already welcomed me at the entry. We had a nice chat, set up the room intended for our mob and waited for interested people from codecentric to join our session. They came, and even brought a test target we could use where they would value feedback on. Great, I really like to have our sessions to not only have the training effect but also have real-life impact.

After Amitai and I introducing ourselves and sharing some words on our tours, the session started. I decided to have a short introduction round in the mob as well, asking them for their name and core expertise. I knew everybody was identifying as developers, however, it was still very interesting to hear the different backgrounds, interests and specialties. Some people were into DevOps, some preferred backend development, or even tended towards security testing. I was pleasantly surprised to hear most of the group already had mob experience, only two persons didn't. After giving them a short heads-up, I went over to introducing testing, and especially exploratory testing. I presented my preferred definition by Elisabeth Hendrickson, as well as her charter template that I find useful especially for people new to exploration.
"Simultaneously designing and executing tests to learn about the system, using your insights from the last experiment to inform the next."
"Explore (target)
With (resources)
to discover (information)"
(Elisabeth Hendrickson, Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing)
I wanted to keep the basic theory short and have people learn by hands-on testing as soon as possible. I asked the ones who provided the test target to shortly introduce it and afterwards asked the mob to write their charter. They, however, were really unsure what they wanted to focus on as they felt they didn't know the product well enough yet. So I decided to have them do a recon session for the first rotations in the mob, mapping out the system. I also recommended to already jot down notes together as a mob, for example in a mind map. And off they went!

Let the Mob Explore

It was really interesting to observe this mob explore a product most of them saw for the first time. They were unsure about their procedure, trying to align themselves as a group. They jumped all over the place, already finding great issues; not taking notes of them. They started a list of assumptions and wishes they had for the product. And they shared lots of implicit knowledge with each other, just as I have witnessed it in so many mobs before.

After nearly one full round of rotations, I had them stop. I shared some of my observations and provided recommendations. I also asked them whether they now felt ready to write a charter so we could do more focused exploration, using a simple Roman vote for quick decision making: thumbsup - I feel we're ready, thumbsdown - we need more information, thumbs sideways - not sure which way to go. Half of the group voted up, half sideways. I could have used the mostly positive result to have them write a charter now, but decided to have them finish a full round of rotations before asking again. Now all thumbs went up! Chartering didn't come easy to them. I helped them through, trying to not enforce my own suggestions or opinion. They managed to come up with a first charter to start with, providing them the needed focus. Interestingly, they decided to explore user experience with the help of the source code! That promised to be interesting, and it was indeed.
  • They used the code as oracle - great.
  • They looked for existing unit tests - nice.
  • One person shared: "I still don't understand the test, can you shortly walk me through?" - liked that.
  • They fed different values to unit tests, in an attempt to use it for exploration - awesome! Unfortunately, they did not follow up on it, or left a remark for future sessions.
  • They said they should also test the feature from user perspective - exactly! It might be the code they saw was actually never executed, right?
Towards the end of our mob session they started a discussion of whether a certain feature was useful at all. They brainstormed ideas how a different solution might be way more valuable to the user in the end. They questioned the context the product might be used in. Many great points were made.

Retro? Debrief, Discussion, Feedback

On my testing tour sessions, I normally do a short retrospective in the end so we can learn how to improve (I learned their value on my very first stop with Maaret). This time, I did a debrief of the testing session with the mob instead, to have them reflect on certain aspects. It proofed really valuable to get them thinking about what they did. Mental note to myself: I should do that more often for my own testing as well.
  1. What was our mission?
  2. What did we test and what not?
  3. What did we learn?
  4. What feedback can we provide about the product, can we quickly derive it from our notes?
  5. What to focus on as next highest priority with the knowledge we have now? 
The response on the last question was my personal favorite. They wanted to talk with the product owner as next step to see if they were going in the right direction or whether other areas might be more risky.

After a short closing, the mob session was officially over. Still, the group stayed and started an informal discussion. One of the persons who proposed the test target now shared that he didn't want to spoil the session, but the tested product version was outdated already and they had indeed agreed to remove the challenged feature - so the mob's feeling was indeed correct here!

It was great to hear people's experience with testing, mobbing and knowledge sharing. I really enjoyed the conversation to conclude a great session. Afterwards, Amitai shared personal feedback with me. He said he could clearly see I did these sessions very often already. This feedback took me by surprise. I had facilitated several mob sessions since beginning of the year: three in my company, one at a meetup, and three at conferences. So this session had been my eighth only. Amitai shared it was received as really professional and it was exactly what he was hoping for. This showed me I had learned a lot and it also triggered me to reflect. The session had indeed felt good. Maybe because I taught developers new to exploratory testing? Would it have been the same in case they would have been other testers? Still to be answered. This I know for sure: I had shared a lot about testing and testers during the session while people were doing hands-on testing. The mob approach is just an awesome way not only to learn but also to teach testing.
Bonus: Amitai also shared what he learned on his blog as well as recorded a conversation with codecentric sharing their highlights from this stop; including my exploratory testing session! :D

Posted by at No comments:
Labels: , , , , , , , , , , , , , ,

Friday, June 8, 2018

Testing Tour Stop #12: Pair Exploring App Development with João

Recently, I've been at a lot of stops on my testing tour. Here's the summary of another one, and there are more still to come! This time, I had the honor to pair with João Proença. João was one of those people who got inspired by Toyer's and my pact as learning partners at Agile Testing Days 2017. A few months later at European Testing Conference 2018 we had several long conversations and found that perfect mixture of similarities and differences in each other where both can learn a lot from. Toyer and I are really happy that he decided to join our extended pact group along with Dianë Xhymshiti! All in all, it's a pleasure to exchange knowledge with him, so I was really happy he decided to become part of my testing tour.

Preparation? Already done!

Now, normally it was me who prepared a system under test or even a topic to pair on, as most people didn't have a clear notion of what to tackle. This time, however, I did not have to do anything besides looking forward to the session. The reason was that João managed to enable us to have a look at one of his company's products: OutSystems' development environment. How great is that?! Here's part of the email he wrote in advance of our session.
What I'll be proposing we do tomorrow is a bit of paired-up exploratory testing over the "first experience" one has with the product my company, OutSystems, offers. The fact that you know little about it is great!
I'll give you a bit more detail tomorrow when we begin, but we will most likely be using the currently available features of the OutSystems platform, but also some new unreleased ones our teams have been working on!
A couple of teams here that work on product design and UI development are very interested on the outcome of our session and have asked me if we can record it, so that they can watch it later and collect feedback.
Would you be ok with us recording our session for our internal use (a video of our interaction with the platform)?
Recording? I even discussed that idea with Cassandra on our common stop, so yes I really wanted to give it a try. And all this to help people improve their product? Of course, that's exactly what I love to do!

Getting Our Session Started

OutSystems claims to enable you to "Build Enterprise-Grade Apps Fast". On their website you can find the following definition of their product.
OutSystems is a low-code platform that lets you visually develop your entire application, easily integrate with existing systems, and add your own custom code when you need it.
Crafted by engineers with an obsessive attention to detail, every aspect of our platform is designed to help you build and deliver better apps faster.
In the beginning of our session, João explained that OutSystems' development environment, service studio, has major release cycles of a few months just like other IDEs as Microsoft's Visual Studio or Apple's Xcode. The goal was to tackle the software from a newbie perspective. Product design people were really curious about the experience a new user would have, so João asked me to really speak my mind during testing. Sure thing!

We agreed to split the testing session into the following two steps.
  1. We do the "Build a Web App in 5 min" tutorial for the current version 10.
  2. We create a new app in the upcoming service studio version 11 which is currently under test and not yet released.
João does not work on the team developing the UI, so the whole topic was also new for him. Still, of course he's an advanced user already and knows his way around the software. Therefore, we decided that I would be the navigator for step one, and for step two we can switch roles as he also did not see anything about it yet.

Then it was about time. We started recording, and we started testing.

The Joy of Exploring a New Applications

Now, I won't share the video recording, and I won't share any details about the second step testing the beta version, trying to create a web app for a real use case. What I can share, however, are the highlights of the first step, doing the tutorial of the current version to get a first feeling for the IDE. Why? Because the great thing is, you can simply try it for yourself! Personal environments are completely free and available in the cloud as long as you keep them running. For our session, João had prepared everything up to the point that we started the five minutes tutorial to develop a new web app.

One of the major topics we came across all the time during testing was usability.
  • Issues with the tutorial itself. Even recognizing the tutorial as tutorial. Same navigation button in the tutorial sometimes referring to the help, sometimes to the next step. Not seeing helper arrows pointing to the area of interest. Not displaying these arrows when viewing the tutorial steps. Not having it obvious that you don't need Microsoft Excel. Confusing ordering of explanations what to do. Missing steps to take. Constant re-positioning of the tutorial dialog; at one point even misinterpreting this behavior as the next step, triggering me to execute it twice. Having not reached 100% when finishing the tutorial.
  • Inconsistent or misleading styling. Surprisingly different styling for the tutorial, the tutorial steps, as well as any other application dialog. A new application button that looks inactive and does not draw attention. Triangles used as navigation arrows which rather look like running an app.
  • And more issues. Superfluous scrolling not providing more options. A wizard step only providing one option, so why having it at all. Doing the same thing twice leading to two different results on purpose. Viewing your new web application first in the smartphone view. Unexpected field validation in the resulting demo application.
I talked a lot about the feelings I had regarding the application. As a new user, it's very important for me that I don't get lost but find my way through the first steps easily enough, that I get aha moments of what's happening so I learn, and that I don't get annoyed or frustrated by the software. At several points, however, I got those feelings. I had to learn the tutorial's way how to lead me through first, and then could successfully complete it.

I tried to really slip into the shoes of a new user. From a technical point of view I understand how things are built and why certain decisions had been made, but from a pure user point of view I would have asked many questions, so I raised them. Especially as I understood the tutorial trying to take the user by the hand and to make it as easy as possible for them to create a first app. Furthermore, new users will always compare the system at hand to applications they already know, using those as oracles for their expectations.

In our second step, we switched roles and learned about the new version with several things revised. We found again quite interesting things which I cannot disclose here, but João took them with him to forward them to the team.

All in all, all this is of course only part of the story, from a tester perspective. Trying to find those things that can still be improved. The product looked really nice and easy and I would love to dive deeper into it!

In Retrospect

It was a really nice experience to have everything so well-prepared by João - my thanks to him for that! It was awesome to explore yet another completely unknown application. It was fun to be an actual new user as a tester and imagining the perspective of a real new user at the same time who wants to start developing an app, trying to learn what they would learn. It was great we collaborated well and our results were really productive. It's absolutely awesome we have a video recording of our session! This way we could focus on learning and providing feedback. The downside, of course, was that I now had to go through nearly two hours of video material to be able to extract the goodies for this blog. For real-life sessions I would not skip note taking as we did so I would still get that quick overview of issues, questions, or further areas to explore about. Still, video recording can be invaluable there, too. It's proof of what actually happened! Awesome to reproduce and report bugs, or even to investigate them.
Sometimes there are bits of information that are crucial but you only acknowledge that afterwards when you had to go back. ~ João
When watching the recording, I saw lots of things I did not realize during testing, even though João drove for me and I could focus on observing and navigating. Exploring a video recording provides lots of feedback as well! About the application as well as about our own procedure when testing, our thoughts and ideas. Lots to learn from.

We set off exploring with certain goals in mind, and we reached our destinations. However, we did not structure too much how to get there. This is the sort of freedom I love when exploring, with every step we learn more about potential ways ahead of us and can decide which to take. We don't have to follow the one and only route strictly but can discover so much more on our way, even if it's not in our focus.

On a meta level, I noticed that with more practice it's getting indeed easier for me to pair with other people. It still helps me if I had met them already in real life. I feel the fear to look silly is getting less so I can focus more on the actual task at hand and freely express my thoughts. Sessions were constructive from the beginning, but were mostly covered by a layer of doubt about myself to deal with on top.

There's another thing that only came to my mind when writing this blog post: it felt awesome exploring an IDE. Again. I only realized now that I have way more experience in that area than I might have told even myself. As a user of IDEs like Eclipse or IntelliJ of course. But even more importantly, as a tester. I spent my first years as a tester testing an AI middleware for computer game developers. We developed our own engine, IDE and server, and we also integrated in Unity. I did lots of exploring back then already, I even wrote those kind of beginner tutorials myself! :D And I loved this awesome domain.

Finally, the very best thing: João said he took a lot of value out of the session himself. He can now bring the issues we found to the teams. It was great to hear that they do lots of usability tests and really care about the feedback, using it to improve the product!
Posted by at No comments:
Labels: , , , , , , , , , , ,

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! :)
Posted by at 2 comments:
Labels: , , , , , , , ,

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!
Posted by at No comments:
Labels: , , , , , , ,

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!
Posted by at No comments:
Labels: , , , , , , , ,

Tuesday, January 17, 2017

Back On Track, Picking Up Pace

When talking to other testers, I love to hear where they come from and where they are heading to on their testing journeys. Listening to those personal stories I search for similarities I can relate to, as well as contrasts I can learn from, getting to know the person better at the same time. In a couple of posts I want to share some milestones of my personal testing journey with you. See also the related previous posts about My Roller Coaster Years, A Maze of Brick Walls and Taking a Detour. This post got quite lengthy, but as it's the final one in the series I decided to not split it to show the whole picture.


After my non-agile experience and my years learning about teams and system administration, you can't imagine how awesome it was to finally return to agile testing and product development! This post summarizes my experience at my current company so far, as well as feels like a wrap-up of my professional 2016. But let's start the story where it began.

As mentioned in my previous post, my "roller coaster" team comes together once a year to exchange updates and have fun together. At our reunion end of 2014, one of my former leads announced that he just started at a new company where he was about to build a development team from scratch, trying to form an ideal team regarding mindset, skills and bonding. I admit I was a bit jealous at that time; in retrospect, that was already a first hint that I had to change my situation. About half a year later, he asked me if I was up for talking about some challenges his newly built team faced. If I could imagine improving their testing, driving test automation and maybe taking over some DevOps tasks as well. I was intrigued! And after several chats with him I decided to give it a try. Met the team. We aligned. And agreed to work together.

End of 2015 I finally started my new job. I was a bit anxious about how it would be, especially as I was supposed to automate tests which I honestly had never done before. So far I was just playing around with Selenium and WebDriver and knowing some bits and pieces of Java and JavaScript - but I was eager to learn. I had laid my cards on the table, but they hired me nonetheless. And kept me. We agreed that I took over manual exploratory testing as first step which fit to my expertise. Then one thing led to another so that I ended up contributing in lots of different ways; to our product, our team, how we work, how we collaborate across teams and within the whole organization. I'm still eager to learn more about test automation and programming, but that's another story.

What happened in 2016?
  • When I entered the team, they already shared responsibility for quality, with every developer writing automated tests and doing basic manual testing themselves. This was a great foundation for introducing testing from a tester perspective. They had some ideas about how it would look like. For instance I often heard "you can wait with testing, code review is not yet done", and "QA does testing after everybody else finished their jobs", like a gatekeeper for releases. However, they appreciated me sharing my experience. Like testing throughout the workflow, before any line of code is written by asking questions and continuing on production such as by reviewing logs; having many feedback cycles and shortening them; and so on. We iteratively defined how we want to collaborate and how our development workflow looks like. Tried things and kept what worked. The team quickly provided feedback that they see big value in having a person coming from a testing mindset contributing in many ways.
  • Our Java development department grew heavily over the last year, we now have three teams and searching for more people fitting in. We made good experience with careful recruiting. Investing quite some effort mostly paid out for us, but sometimes we feel we need to speed things up not to lose great candidates to competitors.
  • As the whole company grows steadily each month, we moved to a big new office. On the one hand we now have space again and the rooms are much nicer; but on the other hand we lost decent internet connection for half a year due to a mistake made when putting up the new building. You know, internet, this thing everybody in the company depends on? Tough time, we had to figure out how to deal with a mere mobile connection during this period.
  • When the time came that my first team was settled, I additionally started in a second team introducing testing there as well. I quickly realized that both roles were full-time jobs. I learned a lot during that time, but it was quite stressful. I often had the feeling to only run after tickets instead of being able to think ahead of them. We were really lucky to find a working student who, although she is able to program and therefore could work as developer, explicitly wants to test. She does an awesome job and is a perfect fit to our teams. We're even luckier now that she started full-time after finishing university. Back then I knew the second team was in safe hands so I returned full-time to my original team in good conscience.
  • My company went through a merger in 2015. The original organizations lived a very different culture and approach to development which often caused issues when suddenly collaborating. In order to become one unified company, we now started a global transition towards agile product development. Additionally, we set up our own flavor of a matrix organization with teams, chapters and communities, based on approaches of other companies like Spotify. As you might expect, this huge change currently causes a lot of turmoil, raises a lot of questions and has us face a lot of challenges. We all try our best to have our organization move into a direction we all support and grow a culture where we want to be part of. I'm curious how we will have evolved one year from now.
  • When starting, I was the second person identifying as tester at the company. So we started our own little community of practice as a two-man show. With the agile transition and getting closer across different locations, we grew into a larger community where not only testers but anybody interested is welcome to join and share knowledge, experience and challenges. I'm really excited about this opportunity of company-wide sharing and learning.
  • And last but not least, my company enabled me to attend Agile Testing Days 2016 for the full week - which was simply awesome! I did not experience this kind of support at other companies before and heavily appreciate the continuous investment in people development!
Throughout the year I learned several valuable lessons.
  • You can do decent "Scrum" even if you don't have a dedicated Scrum Master. When I learned that there was no one taking over this role, I was skeptical but thought "let's see how this is supposed to work". I discovered that every team member took over some part of the Scrum Master role which worked pretty well. Still, I'm not sure who would have stepped up to moderate and mediate in case of bigger conflict within the team; but probably our disciplinary leader would have done so.
  • I was used to have long sprint planning sessions with the first part discussing and analyzing the upcoming product backlog items to roughly forecast which of them we could tackle in the next sprint, and a second part of breaking those items down into detailed single tasks. Imagine my surprise when my first sprint planning ended after about 45 minutes! We simply don't do part two, but work on story level only. And discuss details just in time when we come to them.
  • We have a team of full-stack developers. Everybody doing everything, just pulling in the next item and working on it. This really increases our bus factor! And it's just great to go on vacation without having work piling up during your absence! Only it's hard to find good people willing to take over all kinds of tasks, learning many new things. And we still have some specialized people knowing more about testing, DevOps and UX; but we're working on improving knowledge sharing in those areas as well.
  • Our Product Owner is completely integrated not only within the team but also within the development workflow. When a first version of any backlog item is implemented, he already reviews it if it fits to his vision and expectations. The feedback cycle is kept as short as possible instead of waiting for a sprint review to accept or reject a feature. This procedure also increases transparency while working on an item. We really value this close collaboration with the Product Owner throughout the sprint.
  • Within the past year I finally understood that it's not about reporting and fixing every issue we found, but about communication, collaboration and needs. Fixing some defects simply has no or too less business value as users won't ever come across them, so we close them unfixed. We rather invest effort in things actually providing value instead of wasting our budget.
  • Our team is distributed as our Product Owner is located in another city. We learned that good conferencing tools and especially a decent internet connection is crucial for us. This had hit us especially during the period when we had to work on mobile internet connection only.
  • Our disciplinary leader reminds me of my former one, being really open and supportive, always trying to develop you further. When he asked me for a personal talk two weeks after I started on the team, my self-doubts showed up again and I thought "oh my god what's up, it's probably about my lack of test automation knowledge...". And was so positively surprised to receive feedback that my contribution is already appreciated, how greatly I fit into the team and that it feels like I've always been a part of it. Wow! This instantly neutralized my biggest fears so I was able to focus on my work and put even more energy into it. I knew if something would come up, I would get timely feedback so I would be able to adapt. Psychological safety for the win!
  • If you treat your working students well, they will stay. And so far, nearly all of ours did so. Some of them even quit their master studies to start working full-time with us. We integrate them completely in our team and collaborate on a level playing field. They do exactly the same as everybody else, sharing the same responsibility, learning a lot and bringing in fresh perspectives, receiving support whenever needed just like anybody else.
  • But the best lesson of last year was the following: The mere fact of working for two teams created bottlenecks as the developers continued pulling in new tickets and the things to test piled up. Our situation got worse and worse. Why is this a good thing? Well, when the teams felt the greatest pain, it made everyone realize that our way of working did not work out. We were not able to deliver value to our users anymore, we just created more useless inventory, increased waiting times etc. Everything took longer. Both teams admitted that we needed to adapt. So they agreed to try the simple approach of "stop starting, start finishing". We agreed that it was not allowed to pull in new tickets before you really were not able to contribute to items in progress anymore. Sometimes not even then, just to not increase the work load. But if there was anything to do, be it support with development, reviews from business, code or testing perspective, everybody swarmed to help out, no matter what their original "roles" were. And suddenly there were no bottlenecks anymore! Even after our new full-time tester took over my second team, they really learned their lesson and continue to swarm to finish highest priority items first before starting new ones. Teaching and supporting each other when testing or doing anything else they do not specialize in. I'm really proud of them, they showed what collaboration and a whole-team approach means.
What about our current challenges and the outlook for the new year?
  • While I had been running after tickets, I hardly found time to prepare test cases upfront of implementation and discuss them with developers and Product Owners. In the end this often caused delays as expectations differed and questions were raised quite late. We're just returning to shorten the feedback cycle again and having those discussions guiding development.
  • When testing for two teams, I was not able to invest much time for conceptional work, thinking about test strategies for our product or trying new tools and techniques. Now having more time again, I want to run more experiments, try new approaches and see which work for us. In addition I'd love to increase efforts of knowledge and experience sharing on team, company, local and global community levels.
  • Our team needs to get to know our users better, who are collocated with our Product Owner. We plan on-site visits to learn how they actually use our products and what their pitfalls, challenges and needs are. Actively include them in our sprint reviews. Same goes for our stakeholders. Currently communication is only channeled by our Product Owner which sometimes makes it hard to understand why priorities change or to come up with new ideas for our product.
  • On our agile journey, we have to find new communication channels within the company and grow a common culture, to finally feel as one big organization. Besides that, thanks to this transition we now finally got a dedicated Scrum Master for our team. Even when things are going well there's always room for improvement, so let's find out together!
  • Our team office needs to become more lively. We're now finally hanging up cartoons, getting a large screen TV and discussing how to breath life into our everyday environment! To make it feel less like a "getting work done" place and more like the creative fun area it is. And attract more of those awesome people. Speaking of which, we are still growing. To do so, we have to spread the word that we are a tech company with great offers, but especially with great people to build the world together!
Dear 2017, let's get started - I'm curious what will be the next lessons to learn!
Posted by at No comments:
Labels: , , , , , , , , , , , , , ,
Subscribe to: Posts (Atom)