Getting the right mix for your team can be a pretty difficult thing to get right. Obviously your goal is always to have a team that 'clicks,' that meshes together well, can take communication short cuts and can share the hell out of a vision and deliver deliver deliver.
There's a trap inherent in that path of thinking though. It's not as simple as finding a bunch of like minded people that really gel as a group with high levels of camaraderie and etc. OK, that's actually a way to pretty good results in a lot of ways, or at least it will seem like you're getting good results. Your team can work together relatively well, perform smoothly and deliver deliver deliver. What they won't really do, unless they're super-special is innovate.
Think of it like a troop of soldiers. Once they've spent their 300 hours of training to march together, when they're going down the road together, that's where they remain. There won't be the misfit who wonders off the road, runs to catch up, wanders ahead and has time to look at other things, kind of like a lost puppy. Nope, they look really cool, marching in step, making progress, getting where you want them to go. unfortunately, when they get there they're all still wearing the same clothes and saying the same things that they've been saying for the past 400 years.
Don't take this to mean that you should be going out and hiring a bunch of star performers either. Plunk that idea into the same analogy. Now what you have is an unruly bunch of puppies that are tearing off after every little thing that they can find and if, and that's a huge if, you can ever get them to the destination they'll still be an unruly mob with no real delivery. the only way around this is a truly exceptional leader who can hold things together but that person is likely a super-genious, or in this analogy, has a pocket full of steak.
Here's where the diversity comes in. Hire cross-spectrum. Take on a few star performers and some solid but smart performers. The smart performers are going to keep your troupe moving along to the final destination, keeping the goal in mind as they goal. they're there to not only get the core work done but to hold onto the vision in the group mind so that your stars can be guided back to it by honest peer pressure. Maybe not even peer pressure, that feels too directed of an action on the part of the team. More of a peer gravitation. the star performer should see what direction the team is going and be motivated to catch up and help it get there.
An exception here is the prima dona class of star performer. For me, your general prima dona isn't actually a star performer. Because while they can be responsible for some pretty stellar results, they don't consistently perform for you, nor do they bring things forward as a general rule. They are quite useful in cutting edge industries but most of us aren't working in such a place and don't really need amazing sometimes, we need great all the time.
The other benefit of the diversity is that the differences within your team are what help to drive the innovation. When you put different people in a room and start to brain storm, the building of the storm of creativity comes because someone says something that triggers something in another persons mind and then true innovation can happen. if you have over-alignment, then you don't get that spark of difference that helps the entire team create. it will often be your star that gets sparked but it doesn't have to happen that way, idea generation can happen all around. in fact, what your star performers do is help bring all of your core performers up a notch. Now your entire team is producing something of even better quality.
The one caveat here is that fit is still important. your team still has to be chosen so that a base level they can work together amicably. You need some shared experience or like mindedness to keep everything moving along forward. No one likes strife in the workplace. As for mix - like everything else in life, there's a balance here that you have to find. In my experience the mix has been about 70/30 core to star. And indeed there's even room to discuss adding some grunts, juniors or under-achievers but i think that's a discussion for another day.
In the end though, you have to find the ideal mix for your team, maximizing fit where you can and then lead them forward, herding the puppies when necessary but allowing them the room to lift your team out of the doldrums.
Thursday, August 30, 2012
Thursday, August 16, 2012
Culture of Quality
I think that the biggest single thing that stands in the way of the so-called culture of quality having the impact that it desires is the fact that all-to-often the words are simply lip service. It's far to easy to say to people that it's really important to have the highest possible levels of quality and yet it's not easy at all to actually back up that commitment.
I think that one of the largest things that have you end up in a place where you say one thing about quality and actually do another is the fact that saying you have a culture of quality is not quite the same thing as trying to make one happen. I've been in countless releases where the QA time budget gets chopped due to timeline commitments and invariably you end up having a risk/benefit conversations.
A risk/benefit conversation is that conversation where you go in knowing that there is appreciable risk from moving forward with the release but the benefits, not only of the product to be released but to the relationships that it will feed are more appealing. The big problem with this conversation is that generally the way that the risk is mitigated comes around to a statement like this, 'sure we'll go, and if it goes badly or there's bugs, we'll figure out how to spin that so things are still ok.'
Simply put, that's not quality. I don't disagree that you always have to do a risk analysis and weigh the pro's and cons of your remaining issues pre-launch. That's obviously the way to go but when it becomes a battle between QA and pretty much the rest of the world to go live then you obviously haven't fostered a culture of quality. You may, in fact, have empowered your QA to fight against the rest of the company but that's a hard battle to fight and it really doesn't help.
In order to achieve the culture of quality you have to give every participant in product design and delivery the idea that quality is the first and foremost goal of the organization. That means that 'good enough' when figuring out your requirements is never the right answer. I don't mean that you have to have feature upon feature or that each feature has to be the best possible feature that it can be. Those goals simply aren't practical but the goal that is is complete requirements that truly define what the end product will be. Going back to the well to figure out these complete definitions needs to be the norm.
Developers who write code and throw it over the wall to QA need to be schooled. Take pride in your work. Use test driven development, always build unit tests into your code. Above all else, when you do your design work, think about the environment that your code will live in, how it will interact with other systems and the performance needs that will be met.
QA needs to consider usability where it may have been missed, analyse requirements properly to get the root needs and communicate clearly. They also need to stick to their guns when quality isn't been met.
For all of these things to be possible, from the top down there has to be support to the concept that quality comes first. That when things aren't ready they don't ship. C'levels have to protect themselves from this possibility simply by having the culture supporting quality throughout the process. You won't ever come to the hard question of 'should we ship' that's been guarded by an empowered gate keeper if everyone along the path has already spent their time and their empowerment producing the highest quality that they can. (ok...won't ever might be slightly idealistic)
Culture of Quality...it starts with you, and you, and you.
I think that one of the largest things that have you end up in a place where you say one thing about quality and actually do another is the fact that saying you have a culture of quality is not quite the same thing as trying to make one happen. I've been in countless releases where the QA time budget gets chopped due to timeline commitments and invariably you end up having a risk/benefit conversations.
A risk/benefit conversation is that conversation where you go in knowing that there is appreciable risk from moving forward with the release but the benefits, not only of the product to be released but to the relationships that it will feed are more appealing. The big problem with this conversation is that generally the way that the risk is mitigated comes around to a statement like this, 'sure we'll go, and if it goes badly or there's bugs, we'll figure out how to spin that so things are still ok.'
Simply put, that's not quality. I don't disagree that you always have to do a risk analysis and weigh the pro's and cons of your remaining issues pre-launch. That's obviously the way to go but when it becomes a battle between QA and pretty much the rest of the world to go live then you obviously haven't fostered a culture of quality. You may, in fact, have empowered your QA to fight against the rest of the company but that's a hard battle to fight and it really doesn't help.
In order to achieve the culture of quality you have to give every participant in product design and delivery the idea that quality is the first and foremost goal of the organization. That means that 'good enough' when figuring out your requirements is never the right answer. I don't mean that you have to have feature upon feature or that each feature has to be the best possible feature that it can be. Those goals simply aren't practical but the goal that is is complete requirements that truly define what the end product will be. Going back to the well to figure out these complete definitions needs to be the norm.
Developers who write code and throw it over the wall to QA need to be schooled. Take pride in your work. Use test driven development, always build unit tests into your code. Above all else, when you do your design work, think about the environment that your code will live in, how it will interact with other systems and the performance needs that will be met.
QA needs to consider usability where it may have been missed, analyse requirements properly to get the root needs and communicate clearly. They also need to stick to their guns when quality isn't been met.
For all of these things to be possible, from the top down there has to be support to the concept that quality comes first. That when things aren't ready they don't ship. C'levels have to protect themselves from this possibility simply by having the culture supporting quality throughout the process. You won't ever come to the hard question of 'should we ship' that's been guarded by an empowered gate keeper if everyone along the path has already spent their time and their empowerment producing the highest quality that they can. (ok...won't ever might be slightly idealistic)
Culture of Quality...it starts with you, and you, and you.
Wednesday, August 1, 2012
A dorky video about quality management
The Chartered Quality Institute put out a little video explaining what quality management can do for you.
It's kind of dorky and a little trivializing but it's still cute and informative.
The CQI link page
It's kind of dorky and a little trivializing but it's still cute and informative.
The CQI link page
Monday, July 30, 2012
Specifications and Tolerances - relativity strikes again
Over the years i've been noticing a little something about the usage of specs in design and how you should write and interpret the specs for your design. It's easy to build to a spec (ok, loaded statement but i'll let it stand for the purpose of this article) but what's not easy always is understanding the intent of the spec and the design and building in tolerance for usability.
I think that most of the time we talk about tolerance in engineering as the fudge factor that we allow for in our designs. Or to make the nitpickers more happy, it's the variance that we have to plan for we because we can only expend a certain amount of resources achieving the right level of variation. It's a numbers game filled with trade-off. There's nothing wrong with that, to me it seems like a perfectly reasonable way for the world to work. I don't think that people realize, however, just how much personal opinion they put into the tolerances that they choose.
We were in a meeting a little while ago talking about the design of our parking pay stations and we were talking about meeting ADA standards. (American Disabilities Association). This included putting our keypad at certain heights, angles and etc so people confined to wheelchairs could use them easily. We had a design that we were reviewing and one of our VP's said, 'That's not going to cut it, sure it meets the ADA requirements but it's terrible usability for a person over 6'2". They have to scrunch over to see the keyboard.'
That got me to thinking about such things. I'd noticed something else myself years ago. Most of the cars designed in Japan seemed to be technically large enough to fit a person who is over 6' tall but when you actually fit someone in there'd be a problem with headroom and/or legroom and just overall comfort. But when you put a someone into a similarly sized German car, the tall guy would fit fine. I don't really know but I've always assumed that they are designing against the similar international standards.
But watching what happened in that meeting i understood a lot better what was really going on. When it came time to approve the design or go through product testing, without someone there that actually pushed the bounds of the tolerance themselves the limitation wouldn't be known. And without passing that discomfort onto someone with the power to influence decisions, then it likely wouldn't be heard. In our case the VP made the statement and suddenly it was an important design decision. Compare the average heights of people in Germany to Japan and suddenly things begin to really make sense.
Over time, Japanese design has tailored itself better for North American sizes and i can fit rather comfortably into most of the cars i get into. It's too important a lesson to learn if you want to make sales. I'm sure there's a bunch of science out there about designing for human sizes and if i was a better blogger i might go out and find it for you. but for now i'm happy enough to have learned my little lesson about tolerance, both internal to human interaction as well as to external. After all, the chair that's comfortable to a 6' person, likely isn't nearly as comfortable to someone who's only 4'.
I think that most of the time we talk about tolerance in engineering as the fudge factor that we allow for in our designs. Or to make the nitpickers more happy, it's the variance that we have to plan for we because we can only expend a certain amount of resources achieving the right level of variation. It's a numbers game filled with trade-off. There's nothing wrong with that, to me it seems like a perfectly reasonable way for the world to work. I don't think that people realize, however, just how much personal opinion they put into the tolerances that they choose.
We were in a meeting a little while ago talking about the design of our parking pay stations and we were talking about meeting ADA standards. (American Disabilities Association). This included putting our keypad at certain heights, angles and etc so people confined to wheelchairs could use them easily. We had a design that we were reviewing and one of our VP's said, 'That's not going to cut it, sure it meets the ADA requirements but it's terrible usability for a person over 6'2". They have to scrunch over to see the keyboard.'
That got me to thinking about such things. I'd noticed something else myself years ago. Most of the cars designed in Japan seemed to be technically large enough to fit a person who is over 6' tall but when you actually fit someone in there'd be a problem with headroom and/or legroom and just overall comfort. But when you put a someone into a similarly sized German car, the tall guy would fit fine. I don't really know but I've always assumed that they are designing against the similar international standards.
But watching what happened in that meeting i understood a lot better what was really going on. When it came time to approve the design or go through product testing, without someone there that actually pushed the bounds of the tolerance themselves the limitation wouldn't be known. And without passing that discomfort onto someone with the power to influence decisions, then it likely wouldn't be heard. In our case the VP made the statement and suddenly it was an important design decision. Compare the average heights of people in Germany to Japan and suddenly things begin to really make sense.
Over time, Japanese design has tailored itself better for North American sizes and i can fit rather comfortably into most of the cars i get into. It's too important a lesson to learn if you want to make sales. I'm sure there's a bunch of science out there about designing for human sizes and if i was a better blogger i might go out and find it for you. but for now i'm happy enough to have learned my little lesson about tolerance, both internal to human interaction as well as to external. After all, the chair that's comfortable to a 6' person, likely isn't nearly as comfortable to someone who's only 4'.
Thursday, July 5, 2012
perception...
quicky...listening to "Under the Influence" with Terry O'Reilly yesterday and heard some cool things.
it's all in how you look at things.
QWERTY keyboards weren't invented to slow down typists as the myth indicates that they were.
There were already 'faster' key layouts in existence that artificially slowed people down because they kept resulting in jams. The QWERTY solution allowed people to go much faster without risks of jams.
So QWERTY, in effect, sped up typists. Today we look at it as a solution to slow down typists but that's a relative statement that doesn't really capture the truth of the matter, it was an efficiency measure.
Side note - also learned that one of the reasons that the exclamation point of the past was much more rarely used was that into the '70's the only way you could get an exclamation point on a typewriter (there was no key) was to type a period, press the backspace key and then type an apostrophe.
it's all in how you look at things.
QWERTY keyboards weren't invented to slow down typists as the myth indicates that they were.
There were already 'faster' key layouts in existence that artificially slowed people down because they kept resulting in jams. The QWERTY solution allowed people to go much faster without risks of jams.
So QWERTY, in effect, sped up typists. Today we look at it as a solution to slow down typists but that's a relative statement that doesn't really capture the truth of the matter, it was an efficiency measure.
Side note - also learned that one of the reasons that the exclamation point of the past was much more rarely used was that into the '70's the only way you could get an exclamation point on a typewriter (there was no key) was to type a period, press the backspace key and then type an apostrophe.
Wednesday, July 4, 2012
It's good to have a Sacrificial Monkey
This post is a bit about presentation capabilities but also about my own personal management style.
On a personal level i have very little shame. There simply isn't much that can happen to me, or that i can cause myself that i can't spin or laugh off or otherwise absorb in some manner. I think this is a skill that derives from my razor (sometimes far too razor-like) wit and fast reaction times. I do feel shame when i say or do things that inadvertently hurt another person's feelings for sure but you simply can't make fun of me to the point where i will blush up and hide my face. Rather in fact i excel at the old give-and-take and it's possibly when i'm feeling most alive. (having said that out loud, that might be a little sad.)
Fast forward from the slightly awkward confession stage of the blog post to the part where i talk about the benefits of having a sacrificial monkey and how, for the sake of this discussion i, myself, was said monkey.
Recently my company brought in a speaker who gave a seminar about personal financial health. A talk about debt managment, managing personal risk (ie buy some insurance from me please) and saving for the future. A topic, if you will, that is at great risk for being slightly traumatic and highly dry and boring.
When our paid speaker came out you could tell that this is what she does for a living. She's dynamic, smiley, friendly and filled with personality. She has lots of little personal anecdotes and stories and tries to make a personal connection to the crowd right from the start. She has two assistants with her who help by passing out some high-quality (read expensive) info folders and then essentially stand around for the rest of the presentation. Attached to each folder is a 'hi my name is' sticker and a pen. First thing i do is pop my name on that sucker and throw it on my chest. I am the ONLY person on the room to do so. I notice this but don't really care and certainly don't take my tag off.
The talk proceeds and as you might expect, even with the dynamic speaker at the front, the dry and yet awkward material has a fairly quiet and potentially non-receptive crowd. After all, who wants to know that their spending and saving habits are probably killing them slowly. She would ask the audience for input or responses to questions and there were only a couple of people who would speak up, the rest were quiet as church mice.
As we went along it was pretty obvious that while it was a respectful audience there wasn't that sort of give and take that can make a presentation really meaningful and help what you learn really sink in. Then the presenter called me out by name...remember, mine was the only name tag available, and asked me a question about something I'd said a little before. And then made fun of me. And then asked me some more questions and made fun of me some more. The more that she interacted with me as part of her presentation, the more you could see the rest of the audience becoming engaged with the talk.
I reacted well to the interplay, joked back with her and effectively kept the humour flowing. In the end, it made for a more enjoyable and powerful discussion. At the end as I was leaving she apologized for picking on me, saying that it seemed like i was able to handle it all right. I agreed, laughed it off and went on with my day.
This interplay helped bring some clarity to something that i've not only observed but used myself in such situations. It works in meetings as well as presentations. It's finding someone to be the 'sacrificial monkey.' Someone willing to be involved in the discussion, willing to be made to look a little silly and to simply be the example. Seeing someone else in that humourous or distressful situation helps bring the rest of the audience alive. You can see the same sort of thing at the circus where a clown plays with an audience member or even with magicians who are using volunteers from the audience.
Whether it be because the audience identifies with the sacrificial monkey, are glad they aren't them or simply revels in the pain of another, it brings their own personal involvement to the situation to a whole new level.
Of course i can not warn you strongly enough that choosing the wrong sacrificial monkey can end up in tears, harassment complaints or just bad feelings. Some people don't react well to the spotlight and you have to be able to see their unease and back away.
In this case i was fine with it. Certainly i didn't need to be apologized two because i knew the trick of bringing in an audience foil. I'm not sure if the presenter actively uses the trick on a regular basis but i'm happy that i was there for her, and more importantly the members of my team that were there and able to have a more powerful learning experience. Being able to use humour, mocking and other tools as part of your management style can give you some pretty powerful tools. As i evolve as a manager, i hope to be able to document some of these tricks in a way that people can learn to embrace the methods themselves.
Until then...will you be my sacrificial monkey?
On a personal level i have very little shame. There simply isn't much that can happen to me, or that i can cause myself that i can't spin or laugh off or otherwise absorb in some manner. I think this is a skill that derives from my razor (sometimes far too razor-like) wit and fast reaction times. I do feel shame when i say or do things that inadvertently hurt another person's feelings for sure but you simply can't make fun of me to the point where i will blush up and hide my face. Rather in fact i excel at the old give-and-take and it's possibly when i'm feeling most alive. (having said that out loud, that might be a little sad.)
Fast forward from the slightly awkward confession stage of the blog post to the part where i talk about the benefits of having a sacrificial monkey and how, for the sake of this discussion i, myself, was said monkey.
Recently my company brought in a speaker who gave a seminar about personal financial health. A talk about debt managment, managing personal risk (ie buy some insurance from me please) and saving for the future. A topic, if you will, that is at great risk for being slightly traumatic and highly dry and boring.
When our paid speaker came out you could tell that this is what she does for a living. She's dynamic, smiley, friendly and filled with personality. She has lots of little personal anecdotes and stories and tries to make a personal connection to the crowd right from the start. She has two assistants with her who help by passing out some high-quality (read expensive) info folders and then essentially stand around for the rest of the presentation. Attached to each folder is a 'hi my name is' sticker and a pen. First thing i do is pop my name on that sucker and throw it on my chest. I am the ONLY person on the room to do so. I notice this but don't really care and certainly don't take my tag off.
The talk proceeds and as you might expect, even with the dynamic speaker at the front, the dry and yet awkward material has a fairly quiet and potentially non-receptive crowd. After all, who wants to know that their spending and saving habits are probably killing them slowly. She would ask the audience for input or responses to questions and there were only a couple of people who would speak up, the rest were quiet as church mice.
As we went along it was pretty obvious that while it was a respectful audience there wasn't that sort of give and take that can make a presentation really meaningful and help what you learn really sink in. Then the presenter called me out by name...remember, mine was the only name tag available, and asked me a question about something I'd said a little before. And then made fun of me. And then asked me some more questions and made fun of me some more. The more that she interacted with me as part of her presentation, the more you could see the rest of the audience becoming engaged with the talk.
I reacted well to the interplay, joked back with her and effectively kept the humour flowing. In the end, it made for a more enjoyable and powerful discussion. At the end as I was leaving she apologized for picking on me, saying that it seemed like i was able to handle it all right. I agreed, laughed it off and went on with my day.
This interplay helped bring some clarity to something that i've not only observed but used myself in such situations. It works in meetings as well as presentations. It's finding someone to be the 'sacrificial monkey.' Someone willing to be involved in the discussion, willing to be made to look a little silly and to simply be the example. Seeing someone else in that humourous or distressful situation helps bring the rest of the audience alive. You can see the same sort of thing at the circus where a clown plays with an audience member or even with magicians who are using volunteers from the audience.
Whether it be because the audience identifies with the sacrificial monkey, are glad they aren't them or simply revels in the pain of another, it brings their own personal involvement to the situation to a whole new level.
Of course i can not warn you strongly enough that choosing the wrong sacrificial monkey can end up in tears, harassment complaints or just bad feelings. Some people don't react well to the spotlight and you have to be able to see their unease and back away.
In this case i was fine with it. Certainly i didn't need to be apologized two because i knew the trick of bringing in an audience foil. I'm not sure if the presenter actively uses the trick on a regular basis but i'm happy that i was there for her, and more importantly the members of my team that were there and able to have a more powerful learning experience. Being able to use humour, mocking and other tools as part of your management style can give you some pretty powerful tools. As i evolve as a manager, i hope to be able to document some of these tricks in a way that people can learn to embrace the methods themselves.
Until then...will you be my sacrificial monkey?
Saturday, June 23, 2012
DDoS - Issue Tracking Style
Sometimes following process bites you in the ass. Or maybe i mean that sometimes following process just bites. Doesn't mean it's not still the right thing to do, it's just sometimes hard. By example...
We use Jira as our issue tracking system at work. As with most issue tracking systems, if you're not incredibly (arguably impossibly) diligent at upkeep you end up getting a number of cases that languish forevermore in an uncertain state. It's just the way of things. there's bugs that you're not going to fix...bugs that didn't make any sense...bugs that got fixed through some other issue but never got cross related...bugs that simply aren't applicable any more because that entire system has been deprecated...and...the list goes on. If you can follow strong process and make sure that every single bug that you get in is cross-referenced properly and categorized well then it minimizes it but i simply don't believe that anyone out there has no issue with growing languished bug lists. My opinion is that you try hard to have a good categorization scheme, strong workflow built into your process and your bug tracking system and make your best effort. And then every couple of years you devote some time to clean-up.
So fast forward to week before last at my company. One of the Dev managers decided that before we start some fairly major re-design efforts that the backlog of languishing bugs should be sorted and dealt with so that when we start the design we're not only taking into consideration the requirements and issues that currently rest in the forefront of everyone's brains but that we also make sure we're building upon lessons learned in the past. A very good and honourable intent. I wasn't aware that she was making this effort...at least until i started to see it's results.
So, as QA manager i have it set up that any bug that gets updated, entered, closed etc in Jira sends me a notification. Daily i read all of these updates, generally less than 50 on your average day and it only takes a few seconds per case unless there are issues. It keeps me in the loop on a lot of things and when i spot issues then the time spent has been invaluable. It's a good process to follow for me and as i'm still pretty new, an important one. Jira has a few annoyances along this line in that standard process for closing bugs for some of my team gets me 3 notifications back to back. But i've learned to recognize these in the first case and just mark the next 2 read and move on.
Well one day a couple of weeks ago i started noticing quite a lump of cases coming from the Dev manager. As i was processing them i noticed that they were all old (some of them 4 years or older) and that they fell into three basic categories;
a) 'no longer an issue, closing the bug,'
b) 'probably not an issue, please retest and confirm,'
c) 'still an issue,' additional categorization added.
So i started to process these cases myself. And by process i mean read. A couple, and only a couple of the close ones i grabbed and asked for re-test instead because i wasn't sure and most of the retest ones i assigned to a particular resource. It was all good. Fast forward again, this time until i've processed over fifty of the things and i go to find out what's up. She tells me what she's doing and i think it's a good idea and i resign myself to some extra work for the next few days. When it hit a 100 or so i realized that although i was seeing about a 25% rate of ones marked for closing i was never actually seeing any bugs being closed.
So i went and asked the Dev Manager if she was closing any, to which her response was that she wasn't because Dev's don't close bugs, QA should. Which i think is a great response and really how it should be. I objected to the use of the term in the bug 'closing the bug,' and she agreed. We discussed and since i review all bugs, even those that have been closed, and since she had some 750 of them to process for this short period she was going to close them as well and rather than my having to read the email notification and then open the bug and update it she would just do that part.
This sounded like a good, safe solution to me. Until she emailed me 15 minutes later saying that she didn't have the rights to close bugs.
Here's where proper process bit me in the ass. It's pretty standard to have this process as well. It's common to only allow QA's to close issues so that you don't have the devs making decisions without knowing the full story. It's good process. I don't argue this fact at all. However, when i went home that friday i still had a queue of about 100 to go through, when i came back in monday, i had 385, the dev manager worked until 8:30 PM on a friday night going through the backlog.
Here's where the DDoS (denial of service) title of the blog entry comes in. All last week i tried to find time to process this stack but all i had was this ever-increasing list of notifications to process because she was finding more time that i could. When you have 400 notification emails most of them with the same sender name beside them, it becomes difficult to see the new updates from other team members. Each scrum that week i mocked the dev manager for her DDoS attack, and each time she apologized. I indicated it was ok but that i was still going to mock her for the attack. It was my method of releasing the annoyance of the task.
Because, everything else said, it's still an important task. Two people processing all the cases seems from some standpoints to be silly but in the end, clearing out the backlog is great. It's going to provide excellent information for the new design work and i'm learning a ton about the system as we go. And i've caught a dozen or so that i wasn't happy with the action taken and altered it to be a little safer.
Sometimes process hurts.
If it's good process though, it always helps.
When i left this friday i still had 100 in the queue. But i had started sorting and ensuring i was going through the new ones first every day. And she's through all 750 now, so 100 is all i should have left.
We use Jira as our issue tracking system at work. As with most issue tracking systems, if you're not incredibly (arguably impossibly) diligent at upkeep you end up getting a number of cases that languish forevermore in an uncertain state. It's just the way of things. there's bugs that you're not going to fix...bugs that didn't make any sense...bugs that got fixed through some other issue but never got cross related...bugs that simply aren't applicable any more because that entire system has been deprecated...and...the list goes on. If you can follow strong process and make sure that every single bug that you get in is cross-referenced properly and categorized well then it minimizes it but i simply don't believe that anyone out there has no issue with growing languished bug lists. My opinion is that you try hard to have a good categorization scheme, strong workflow built into your process and your bug tracking system and make your best effort. And then every couple of years you devote some time to clean-up.
So fast forward to week before last at my company. One of the Dev managers decided that before we start some fairly major re-design efforts that the backlog of languishing bugs should be sorted and dealt with so that when we start the design we're not only taking into consideration the requirements and issues that currently rest in the forefront of everyone's brains but that we also make sure we're building upon lessons learned in the past. A very good and honourable intent. I wasn't aware that she was making this effort...at least until i started to see it's results.
So, as QA manager i have it set up that any bug that gets updated, entered, closed etc in Jira sends me a notification. Daily i read all of these updates, generally less than 50 on your average day and it only takes a few seconds per case unless there are issues. It keeps me in the loop on a lot of things and when i spot issues then the time spent has been invaluable. It's a good process to follow for me and as i'm still pretty new, an important one. Jira has a few annoyances along this line in that standard process for closing bugs for some of my team gets me 3 notifications back to back. But i've learned to recognize these in the first case and just mark the next 2 read and move on.
Well one day a couple of weeks ago i started noticing quite a lump of cases coming from the Dev manager. As i was processing them i noticed that they were all old (some of them 4 years or older) and that they fell into three basic categories;
a) 'no longer an issue, closing the bug,'
b) 'probably not an issue, please retest and confirm,'
c) 'still an issue,' additional categorization added.
So i started to process these cases myself. And by process i mean read. A couple, and only a couple of the close ones i grabbed and asked for re-test instead because i wasn't sure and most of the retest ones i assigned to a particular resource. It was all good. Fast forward again, this time until i've processed over fifty of the things and i go to find out what's up. She tells me what she's doing and i think it's a good idea and i resign myself to some extra work for the next few days. When it hit a 100 or so i realized that although i was seeing about a 25% rate of ones marked for closing i was never actually seeing any bugs being closed.
So i went and asked the Dev Manager if she was closing any, to which her response was that she wasn't because Dev's don't close bugs, QA should. Which i think is a great response and really how it should be. I objected to the use of the term in the bug 'closing the bug,' and she agreed. We discussed and since i review all bugs, even those that have been closed, and since she had some 750 of them to process for this short period she was going to close them as well and rather than my having to read the email notification and then open the bug and update it she would just do that part.
This sounded like a good, safe solution to me. Until she emailed me 15 minutes later saying that she didn't have the rights to close bugs.
Here's where proper process bit me in the ass. It's pretty standard to have this process as well. It's common to only allow QA's to close issues so that you don't have the devs making decisions without knowing the full story. It's good process. I don't argue this fact at all. However, when i went home that friday i still had a queue of about 100 to go through, when i came back in monday, i had 385, the dev manager worked until 8:30 PM on a friday night going through the backlog.
Here's where the DDoS (denial of service) title of the blog entry comes in. All last week i tried to find time to process this stack but all i had was this ever-increasing list of notifications to process because she was finding more time that i could. When you have 400 notification emails most of them with the same sender name beside them, it becomes difficult to see the new updates from other team members. Each scrum that week i mocked the dev manager for her DDoS attack, and each time she apologized. I indicated it was ok but that i was still going to mock her for the attack. It was my method of releasing the annoyance of the task.
Because, everything else said, it's still an important task. Two people processing all the cases seems from some standpoints to be silly but in the end, clearing out the backlog is great. It's going to provide excellent information for the new design work and i'm learning a ton about the system as we go. And i've caught a dozen or so that i wasn't happy with the action taken and altered it to be a little safer.
Sometimes process hurts.
If it's good process though, it always helps.
When i left this friday i still had 100 in the queue. But i had started sorting and ensuring i was going through the new ones first every day. And she's through all 750 now, so 100 is all i should have left.
Subscribe to:
Posts (Atom)