“The ratio of people to cake is too big.” ~ Milton Waddams — Office Space
My first rant of the new year:) Maybe it’s because I work for a large company, but it sometimes feels like something out of the movie Office Space. I can only hope that it’s just me, but in 2016 I’m already struggling with thinking that seems to be straight out of the 90’s Waterfall development culture.
Agile in Name Only
We implemented Agile and BDD practices on a new development effort a little over two years ago, Although we’re really good at the easy, non-critical things that make it look like we are “Agile”– like forcing everyone to work in one room like a bunch of sheep to being “co-located” and having two-week sprints so we can develop “quickly,” we still struggle with the most important thing that Agile and BDD is supposed to help with, which is to create a culture that values communication and collaboration between teams.
Email Flame Wars with Developers
Just today I received this little flame mail in my inbox:
“Today this was brought to my attention (I didn’t realize that before) that BDD tests resulting in serious data inconsistency on all test systems. As a result a number of “spurious” defects are opened by the QA because of such inconsistency.
Then developers fixing those “pseudo-bugs” by providing unnecessary workarounds in the code thus increasing code complexity. It is clearly a waste of time. Then when the tests are completed, some code is cleaning up tables. Unfortunately, it is done in the same clueless way without a proper transaction logic while deleting data rows or similar. As result of such “exercises” a number of records become orphans. Such scenario is not the case in real production since all is managed by supported consistent SQL code encapsulated in RCM(s) which are called in certain order. That’s said, I consider this as a serious issue impacting team productivity.
Whoever is responsible for the BDD automation scripts and other test codes have to perform this in supported consistent way.”
That’s the whole Email. Very helpful, right? WRONG! Although the writer brings up some valid points, it contains elements that are pretty disturbing to me. Worse, I know this isn’t unique to my team or company; I hear similar stories from test engineers at other companies all the time.
Look in the Mirror
[three_fourth_first]Don’t you just love people that seem to know how to fix something but offer no help in resolving the issue? They are quick to kick the can and say “I told you so,” but not lift a finger to actually resolve the issue. This is also a classic case of waterfall silo thinking with the old walls of separation between developers and QA.[/three_fourth_first][one_fourth_3_last]
[/one_fourth_3_last]
Let me mention again: If you ask anyone on this team they will swear we’re using “Agile,” but this “developers vs. QA” mentality is still prevalent throughout the organization.
So, to answer one of the questions in this email (“Whoever is responsible for BDD”) the answer is, “Look in the mirror, because we are all responsible for Behavior-Driven Development!”
Ownership – Solve the Problem
The funny thing is that I just stared to read the book Flipping the Switch – Unleashing the Power of Personal Accountability and it talks about how just by changing the types of questions that we ask from blame centered to more personally responsibility type question can change your entire outlook and help you achieve better success.
Here are some better questions anyone can ask (even developers) this year to make things better rather than play this waterfall non-productive blame game:
- How can I solve the problem?
- What can I do to contribute?
Notice how these question are the opposite of the types of question from the email above where the person asks more unproductive questions like Who is there to blame? Who is going to fix this?
Take Personal Responsibility
Better questions that can (and should) be asked to actually improve the situation are:
- How can I help the BDD effort?
- What can I do to make this BDD test data situation better?
- How can I take Ownership of this issue and move it forward?
Only when each and every team member begins taking personal responsibility by asking these types of questions will our development and testing efforts start to improve.
