In the first part of my retrospective series, I told you about the first three months I spent on the project, the challenges I encountered and the lessons I learned.
What changed after those 3 months?
Well, the Pilot project ended. And the actual collaboration started.
Since the Pilot project went well and the clients were pleased with my involvement, work and qualified opinions, the project was extended. The trips to Germany were carried on as before.
After exactly 3 months since I had joined the project, I was announced I would switch from the “Desktop” project to the “Mobile” one. Yeeey!
The new thing about the latter project was that, besides focusing on launching a mobile interface for the Online shop, the scope was also to switch from the old Waterfall model to the Agile practices.
I started the knowledge transfer from a colleague that was leaving the project and helped him on the regression testing. Things were going well, so soon I received independence on the project and got my own User Stories to analyze and prepare test cases for. I was attending all the Scrum events. At one point, I was also free to decide what we will retest in the regression phase.
I helped on familiarizing other colleagues with the Agile concepts and project, explaining them what was important to know about the sprints and what we had been working on up to that point, so that they could help me on the testing side.
In the first period of 2014, the mobile team started to grow: a front-end developer joined and from that point on, the Romanian team started growing in number (front-end developers, app developers, team lead, testers).
Something big came up and somewhere around May 2014, there was some massive restructuring on the client’s side. The new structure aimed to extend from the top management to department managers, test managers, testers, etc…New people came into the project, and others left the project.
Challenges:
- Testing was not taken too seriously
Both developers and business people were not really considering testing as part of the “delivery process”. Features were implemented, business was checking them at a superficial level and they wanted to present them to the stakeholders, without the features being first tested.
In the beginning, the testing team was not really invited in the planning meetings.
Even when they started to join them, testers were not asked about their effort on testing a particular feature, estimations. The same was happening in the daily meetings.
What I’ve learned: Advocate for your own work and contribution.
Feeling somehow disappointed about that, I started to push testing into the bigger picture. The testing team let the business know we all wanted to be involved in the planning meetings, arguing that besides being aware of all features and bugs planned for the next sprint, we could also bring a valuable support to the discussions. Understanding the functionalities well, I was often offering support to my colleagues for user stories clarifications.
If they were not asking me about my estimations, I would intervene during the meetings. The same for the daily stand-up meetings.
I started to address this problem in the retrospectives, and kept doing that for many retrospectives. My colleagues and our team lead were also supporting me, and in the end we managed to convince the PO that features that hadn’t been tested by us shouldn’t be presented to the stakeholders.
I started to send status emails and to make us more visible, highlighting the problems we had discovered in the product and specifically asking for their feedback, so that they got involved more than just reading the email and ignoring it.
- The only tester in the team
During a period of almost one year, I was the only tester fully allocated on the project (I had some colleagues that helped me from time to time when having time/allocation), while there were a lot of developers and a lot of new functionalities. I was in charge of testing them, but the problem was that I didn’t have the physical time to test them all by the time a sprint was ending. I was also in the position where I didn’t have another tester colleague whom to consult with, in terms of testing ideas, scenarios, different understanding and perceptions of a specific feature, etc…
What I’ve learned: Don’t be ashamed, ask for help.
I think people are often afraid to ask for help, because they would think it’s a matter of weakness. Due to this, they would rather try to keep it for themselves, accumulating emotions of frustration and anger.
In my case, I had some persons I knew I could honestly talk and confess my frustrations to and that opened my eyes.
I asked for help with reprioritizing the topics, from the business side, decreasing the number of tasks I was involved in and even hiring more testers in the team. Of course the problem was not entirely solved not even until my last day on the project (because there was always something to do or test), but was improved a lot: from one tester, the team grew to 4 testers.
- Test Cases
There was a stage in the project when test cases were allocated to me and I was required to run them and report the status. Then followed a phase when I was in charge of certain user stories, but I was still asked to document test cases for each story.
Coming from Altom, where I had learned that testing is a rich activity, which implies exploring, questioning, investigating, learning, critical thinking, oracles, heuristics, I couldn’t stay in those phases for a long time. It was conflicting with my beliefs.
What I’ve learned: Support your ideas with relevant examples. Be consistent.
When you want to change something, come up having good reasons and present them well. Back up your ideas with actual examples, based on your previous experiences, or on those shared by others. If you’ve encountered a problem in the past that was solved in that manner, explain the others the results. Explain the benefits that could outcome from the change you propose. If you don’t succeed from the first, try it again. Try it harder.
I had a previous experience on a project (I was asked to write many, many test cases; so many that most of the time was spent on writing them, instead of really exploring, testing the product and finding problems), so it was easy to recall the outcome obtained there, try to adapt it and apply it in this case.
I invested time in arguing about changing the mindset of using test cases, the belief that writing cases will enclose all testing activities, or that someone will get a relevant overview of the testing process by counting them (how many were run/day, how many passed, failed, were blocked, etc…). And I succeeded. Instead of writing test cases, I obtained more time for exploring the functionalities that were supposed to be tested. I agreed that we should give visibility in case someone wanted to see what we covered with our tests, so instead of writing test cases, we documented our testing activities (sometimes before starting to test, sometimes while testing, or even after we finished). It was a good deal and both parties were happy about it.
- Split team/s
From the beginning of the project, teams were split over different geographical locations. This is a challenge that is still present today. There was a time when there were four teams in Germany (situated in different cities) and one in Cluj. Then, things changed and settled to a big team split in 3 locations (two of them located in Germany, one in Cluj-Napoca).
The biggest challenge I see with split teams is how to make them feel as one team, aiming for the same goals? Communication and collaboration is another point.
What I’ve learned: Sharing the same “space” can make a difference.
If that is possible, why not make the effort of traveling and spending time together? Try sitting in the same office, interacting with each other, having lunches together, organizing dinners or beer-nights. Find out what the other colleagues are expecting from such a team, how they are feeling about it.
We tried different approaches. Went all to “Team no.1” in Germany and sat in the same office. Went all to “Team no. 2” in Germany and worked together for a release scope. Then, some of the German colleagues came to Cluj for a couple of days. In all cases, we tried to interact as much as possible, have lunch together, go out for a couple of times, even some of us had a party together (in that case, the scope was different, but the point was that we were all together).
When traveling was not possible, we were using technology to communicate and interact easier (calls, video conferences, sharing screens, chats, even had groups for sharing unrelated work discussions). We were also sharing information in a common location, we had specific mailing lists defined, or specific work spaces we were using.
Another example is from when we started to use a software for bug tracking, issue tracking, and project management functions. We hadn’t all had the chance to meet in person so, we agreed to attach our pictures to our profiles, so that team members could relate to each other from a more personal perspective.
- Reposition towards new people
New people joining the project probably means people that don’t know you, yet. The context in the project changed when the restructuring took place and some of the people that already knew me, or the team, left the project.
There was a chance that things that had worked until then would be affected or would change.
New people might have other expectations from you, might implement their own vision, and most important: they don’t even know you.
What I’ve learned: Build trust. Over and over again.
Don’t take it for granted. It doesn’t mean that if you once earned someone’s trust (e.g. a colleague, lead, manager, client), it will just be passed from the old person to the new one. You need to build the relationship again.
What I did in this sense was to try to communicate with the new people, to involve myself into different tasks with them, so that we could work together. I didn’t want to impress anybody, I just let myself be known by the others, while being myself.
- Agile? Not there yet.
Several months passed since the project had started, we were pretending we had switched to Agile, but we were not even close to it. We were testing features/functionalities implemented two sprints before, while the development team was implementing new functionalities which we would get to test three sprints from then (!). The scope of some of the meetings was not reached, our retrospectives were not really reflecting on the problems we had and not focusing on the outcomes. There are many other examples, but I’d rather stop here. Is was pretty much chaos at one point.
We wanted to be Agile, we wanted to say we succeeded.
What I’ve learned: Rome wasn’t build in a day.
Changes require time and patience.
Changes require people willing to get involved in the process of changing, of analyzing and trying different solutions until finding the one that fits the team.
Changes require people that can pick out when something goes wrong and consider the differences of opinion as being useful.
I consider that, for us, building a new structure for working in an Agile way required a lot of time, effort, willingness to change, understanding and patience. Looking back to where we started, analyzing my notes taken during retrospectives or other meetings, I can honestly admit that things have positively changed. Of course we haven’t reached the point of following the Agile practices 100%, but that’s why there’s always room for improvements.
- Stories and Bugs
The main issue was that most stories and some bugs were not detailed enough. There were situations when there was a single sentence and sometimes that would not be enough to clarify the entire story…
Also, there were cases when the business was reporting bugs (found by them, or during UAT), and they were not clear enough, without details, or even written in German (and assigned to the Romanian front-end/app team).
What I’ve learned: Take initiative.
Using the knowledge gained in the BBST Bug Advocacy course and also drawing upon previous experiences, I talked to my team lead and we went to the business representatives with two examples of templates: for User Story and for Bug reporting. After a while, and after some other people advocated for the same things, they accepted it. We couldn’t say the bugs were always decently reported, but still, there was an improvement to be seen in most reports. Also, user stories were better defined.
There’s more to the story, so I invite you keep close by, as Part 3 will disclose new challenges and situations encountered while working on the client’s site.