Tuesday, April 15, 2014

Frustrated on the silo mentality and working solo

With 17 years in testing and intensively learning about pretty much everything on software development is (positively) mixing up my duties at work. I tend to contribute on pretty much everything we do, and try to speak for the idea that others could too.

To take a break from testing, today I contributed summarizing our product roadmap - just to make it visible what we've already talked about that needs doing in a visual format. And I initiated a meeting to collaborate on user interface design. The latter left me thinking, which turns into writing.

A little over a month ago, I was asked to test a new feature in the product. The feature was a search and with the first minute looking at it, it was obvious to me that it was close to "as designed" but nothing close to what the users were likely to need from it. With a history of failing this way a few times before (and also succeeding not to do this a few times), I felt frustrated. I obviously had missed the fact that we started implementing this based on a user interface design that just would not work - again. I could have helped, I could have contributed, but I had not. So again, I was in a position to tell how it would not work.

The message was taken well, but I was still puzzled. I asked around to ask if anyone had been helping the developer with the feature. I learned that our project manager had contributed the user interface sketch in efforts to explain what the feature could be, and that the feature had been reviewed by our user interface specialist. The developer had suggested a couple of relevant improvements, within the limits of the design he had presented. I talked with the user interface specialist, to learn that he had reviewed it as in "yes, that's a user interface sketch" and with all the other work, passed it on without paying much attention.

As the design had already been implemented, I took on more time testing it than the first minute. I learned through testing that not only the design was inappropriate, the implementation was also quite buggy. With the worst possible experience, I logged the bugs and just checked to see the issues are still waiting in the queue with no progress what so ever. Not fun for anyone, I'd claim.

I got back to this experience, as I managed to volunteer myself to participate in a "managerial" meeting with the business users end of last week. Listening and asking questions, I learned that my perception of "this will not work for the users" was indeed the case. Taking the lessons from that discussion, we had another one within the team today on collaborating with the user interface design.

We looked at the existing design, which focuses on showing the database fields to user as separate search criteria. I brought in a post-it note I had sketched on what I thought the users needed while I had tested. We had a discussion, and agreed to leave the user interface designer to work onwards with it with some quick sketching.

A few hours later, we had another design. We reviewed it together and I contributed both ideas of how the design would fail with the users and what I saw as it's strengths. Five minutes later, we had yet another design that looked brilliant. I quickly still went through the use scenarios in my head, testing it, to realize we had dropped a significant requirement. With additional discussion, a few minutes later we realized that the current design could easily be extended incrementally to the missed requirement, and that there would be a lot of value for the users to just do the first part first.

To my surprise, the feature with the second part included, looks exactly like my little sketch from testing. I guess we're now more in synch as a team, but it took a lot of calendar time and effort, leaving me hoping for ways to accelerate learning with better on-time collaboration.

My team has a product-owner -type of a project manager, a user interface design specialist, developers and myself as a testing specialist. I don't particularly like the idea that removing the testing specialist, so much of our results crumble. It's not because a tester is needed, it's because someone like myself is needed. I go through what I thought, what I learned and how I felt. I work through a lot of ideas on how I could help us succeed, how I could contribute, how I could help others learn. I can change what I do, and hope others will pick up stuff they find relevant - and learn to find the end goal relevant.

Occasionally, like today, I feel the amount of "not in my job description, somebody else's work" is overwhelming. And on days like this I wonder what is the experience that transforms the silo mentality to something a little more productive. I want something better, and I'm sure others do too. There's something wrong with the system that causes us to shy away from delivering value together to play with our individual tasks. So, more collaboration, more doing together. I wonder when the initiative is on someone else and not assumed to be "in my job description" - as I have no such thing, by choice.

1 comment:

  1. Sometimes I think it comes down to the simple fact that a tester is always thinking of who the user is.

    Even on great teams where silos don't exist you tend to find one individual who thinks things through more deeply than the others. Maybe this person should always be the designer, or maybe the product manager but unfortunately I think it is a skill which doesn't necessarily get recruited for in any role. Your team are just lucky that you have the ability and motivation to go through these steps.

    ReplyDelete