What does it mean to let a team self-organize? I am guessing that it varies some from team to team, but I tend to think of concepts like managers trusting the team's opinion on what they need to get things done, empowering them and giving them the freedom to determine their best composition, structure, and timelines.
I have read a lot lately about why that makes sense; how letting the people closest to the work make decisions about it makes sense, and how empowering the teams allows for the best decisions to be made.
So .... why would people say this? Well, again, I am sure you can read all about it from the Ron Jeffries, or Ken Schwaber, or Mary Poppendieck people of the world. Following my precedent, let me be the one to give you a whole bunch of reasons why preventing self-organization *doesn't* work (speaking from experience, of course).
What about team composition? Recently, one member of our team was taken off the team by upper management. That team member had previously been "voted back onto the island" by the team. It bothered me that after our team had chosen for that team member to be included as part of the team, that a member of management would just decide to take them off. What concerned me more was the motivation for doing it (as reported by mgmt): the team has complained that we don't focus enough on the project that has been pounded into our heads as our number 1 priority. This team member focuses mainly on other things, so by removing him from the team, the rest of the team should feel more focused.
The team's response was predictable. They felt like their decision had been undermined by mgmt. The team does not feel empowered to make decisions about what is best for them, and worse, recognizes that the root problem has not been addressed. Removing people from the team does not magically fix the fact that the team is not allowed to focus on the number 1 goal.
A team that is not empowered to make decisions feels disrespected. They feel like they are not trusted and cannot do their best job. These teams do not give their best effort. They stop taking the time to think through everything as thoroughly as they do when they feel passionate, trusted, and empowered. Nobody wins in this situation.
Friday, August 15, 2008
Why not removing impediments does not work
What goes wrong when impediments are not removed? Let me put it simply: the team can not succeed! Our team has gone sprint after sprint after sprint saying the *same* things over and over. Here's an example: we use TFS for source control. The box that houses TFS is DOG SLOW .... for those who use the web interface, you click a link, and then go get a cup of coffee ... Every sprint for 9 months, the team has said "we need a better TFS box".
When we didn't get one, it didn't take a lot of time before people resisted using it. And when some people stopped using it (for tracking things like Product Backlog Items and Sprint Backlog Items!!), *that* behavior became an impediment to other team members. Over a few sprints, we eventually dropped the electronic tracking of user story cards altogether!
Back to index cards we went ... but *sigh*. Rather than work toward solving the original problem (faster TFS box!), we started trying to solve the problems that we had with index cards. We have remote employees, and they couldn't see the cards. Worse, the cards lacked detail, and we never have yet solved the problem of several team members not knowing more than just a few words of information about a card.
Our team has spent sprint after sprint trying to work around problems that we have previously identified but not been able to solve, so much so that we are losing sight of our original problems, and are starting to work around problems that some of us have forgotten about.
When we didn't get one, it didn't take a lot of time before people resisted using it. And when some people stopped using it (for tracking things like Product Backlog Items and Sprint Backlog Items!!), *that* behavior became an impediment to other team members. Over a few sprints, we eventually dropped the electronic tracking of user story cards altogether!
Back to index cards we went ... but *sigh*. Rather than work toward solving the original problem (faster TFS box!), we started trying to solve the problems that we had with index cards. We have remote employees, and they couldn't see the cards. Worse, the cards lacked detail, and we never have yet solved the problem of several team members not knowing more than just a few words of information about a card.
Our team has spent sprint after sprint trying to work around problems that we have previously identified but not been able to solve, so much so that we are losing sight of our original problems, and are starting to work around problems that some of us have forgotten about.
Tuesday, August 12, 2008
Why not having an available Product Owner does not work
This one seems like a no-brainer, right? Summarizing how I interpret many of the basic ideas behind agile development, a reasonably dedicated, always available product owner is key, right? I feel like agile teams are largely about collaboration and integration of team members, rather than the separation of skills in previous methodologies.
For anyone who for, whatever reason, hasn't read the agile manifesto ... here's a link:
http://agilemanifesto.org/
So, *why* is that the case? *Why* did all of those people get together and publish these ideas, much less advocate for them?
Well, there are plenty of resources out there describing, advocating, and downright fighting for the *why*. I will take the opposite approach and describe why *not*. Here are some of the things that I have seen happen when a team does *not* have a clearly defined, available product owner:
My team has struggled for many many months without a product owner. As we first tried incorporating Scrum into our organization, our first planning meetings were grueling, at best. We had poorly defined ideas of what we should work on. We spent hours asking questions and trying to answer them right there in the planning meetings! We definitely wanted a clear idea of what we were going to do as soon as the planning meeting was over. So we talked through logistics of features and we made decisions.
LET ME TELL YOU .... people in the company who have ideas about what they would like developed DO NOT LIKE when a team makes a decision by themselves! The problem was, they were not around for answering questions. They are located at other geographical locations, and generally do not respond to emails or phone calls in a timely manner. What's a team to do?
So ... we went through a BIG requirements push ... we even hired someone to fill this gap: a dedicated, full time, requirements person. It was partly her job to get the details of desired functionality documented, so that when the team went into planning meetings, they would have the answers to the questions they came up with.
Well, it turns out that "product owners" who are not available to answer questions on the fly, ALSO do not have the time to write requirements. Many planning meetings were entered with still incomplete requirements, or "product owners" promising that they would finish them in a day or two. I guess that maybe having all VPs as your product owners isn't really meant to be the point. Planning meetings became very difficult, as the team started pushing back with saying that they could not estimate incomplete requirements.
Why do I keep saying "they"? Because one of the reasons that having a bunch of product owners is a bad idea is that when they conflict with each other, how can a team solve this problem? We had something like 8 product owners, and each one had an interest in getting *their* features into the development team. Sometimes the team chose what they thought they could do, but were quickly told they were WRONG.
About this time, scrum master #1 had started to burn out, and we had hired a Project Manager (yes, the Gantt chart type). Upper Management decided that the roles should shift, and the previous scrum master would now be a product owner proxy (product owner of product owners, if you will), and the project manager would be the new scrum master (another post soon about why the Gantt chart type has difficulty in scrum master roles!). So ... to solve the "too many product owners" problem, we would funnel everything through one!
Hmm. As it turns out, doing that will not work as long as the product owner proxy does not have any authority to prioritize backlog items. Our PO proxy found himself bringing conflicts to the attention of the other POs, and nobody could make a decision. When he would try to make decisions himself, he even got told "You don't have the authority to make that decision!!"
During this time, upper management decided to create the Sprint Governing Board. The SGB was to meet regularly to decide the priority of story cards. OH WHAT A MESS! In what can only be the most ridiculous planning, the SGB met immediately *after* the planning meeting, and at least 2 sprints in a row, they rearranged the story cards within HOURS of the team spending a day in the planning meeting. This did nothing but make the team angry and tip the scales for a few of the developers into sheer bitterness and outrage.
Most recently, a different person has been given PO responsibility. It's another off-site and unavailable person, previously titled a "product manager". An example of how this goes now ... On Thursday, myself and another team member hit a roadblock; well, a point where we could not proceed without an ok from the PO. We sent her an email (she's not in our office) and told her that we needed help, a decision.
Then ............ we waited. And waited. Thursday night, she sent an email and detailed a whole mess of documentation that we would need to write in order for her to make a decision, and that once that documentation was written, she would be willing to have a conversation about it. To make that frustration even better, a VP followed that up by saying that we *should not* write such documentation, that we should all meet. Then, we waited again. In Monday's stand-up, I said that I was impeded by the fact that I had conflicting instructions from people above my pay grade, and that I needed a decision. After the stand-up, our scrum master scheduled a meeting for Wednesday morning at 10:30.
Do you see the direction this is going ..... ? Even better, do you see the root of the problem? I think I do ... but rather than speculate, I will let you draw your own conclusion. For now, I think I have covered plenty 'o reasons why the lack of a product owner is NOT GOOD.
For anyone who for, whatever reason, hasn't read the agile manifesto ... here's a link:
http://agilemanifesto.org/
So, *why* is that the case? *Why* did all of those people get together and publish these ideas, much less advocate for them?
Well, there are plenty of resources out there describing, advocating, and downright fighting for the *why*. I will take the opposite approach and describe why *not*. Here are some of the things that I have seen happen when a team does *not* have a clearly defined, available product owner:
My team has struggled for many many months without a product owner. As we first tried incorporating Scrum into our organization, our first planning meetings were grueling, at best. We had poorly defined ideas of what we should work on. We spent hours asking questions and trying to answer them right there in the planning meetings! We definitely wanted a clear idea of what we were going to do as soon as the planning meeting was over. So we talked through logistics of features and we made decisions.
LET ME TELL YOU .... people in the company who have ideas about what they would like developed DO NOT LIKE when a team makes a decision by themselves! The problem was, they were not around for answering questions. They are located at other geographical locations, and generally do not respond to emails or phone calls in a timely manner. What's a team to do?
So ... we went through a BIG requirements push ... we even hired someone to fill this gap: a dedicated, full time, requirements person. It was partly her job to get the details of desired functionality documented, so that when the team went into planning meetings, they would have the answers to the questions they came up with.
Well, it turns out that "product owners" who are not available to answer questions on the fly, ALSO do not have the time to write requirements. Many planning meetings were entered with still incomplete requirements, or "product owners" promising that they would finish them in a day or two. I guess that maybe having all VPs as your product owners isn't really meant to be the point. Planning meetings became very difficult, as the team started pushing back with saying that they could not estimate incomplete requirements.
Why do I keep saying "they"? Because one of the reasons that having a bunch of product owners is a bad idea is that when they conflict with each other, how can a team solve this problem? We had something like 8 product owners, and each one had an interest in getting *their* features into the development team. Sometimes the team chose what they thought they could do, but were quickly told they were WRONG.
About this time, scrum master #1 had started to burn out, and we had hired a Project Manager (yes, the Gantt chart type). Upper Management decided that the roles should shift, and the previous scrum master would now be a product owner proxy (product owner of product owners, if you will), and the project manager would be the new scrum master (another post soon about why the Gantt chart type has difficulty in scrum master roles!). So ... to solve the "too many product owners" problem, we would funnel everything through one!
Hmm. As it turns out, doing that will not work as long as the product owner proxy does not have any authority to prioritize backlog items. Our PO proxy found himself bringing conflicts to the attention of the other POs, and nobody could make a decision. When he would try to make decisions himself, he even got told "You don't have the authority to make that decision!!"
During this time, upper management decided to create the Sprint Governing Board. The SGB was to meet regularly to decide the priority of story cards. OH WHAT A MESS! In what can only be the most ridiculous planning, the SGB met immediately *after* the planning meeting, and at least 2 sprints in a row, they rearranged the story cards within HOURS of the team spending a day in the planning meeting. This did nothing but make the team angry and tip the scales for a few of the developers into sheer bitterness and outrage.
Most recently, a different person has been given PO responsibility. It's another off-site and unavailable person, previously titled a "product manager". An example of how this goes now ... On Thursday, myself and another team member hit a roadblock; well, a point where we could not proceed without an ok from the PO. We sent her an email (she's not in our office) and told her that we needed help, a decision.
Then ............ we waited. And waited. Thursday night, she sent an email and detailed a whole mess of documentation that we would need to write in order for her to make a decision, and that once that documentation was written, she would be willing to have a conversation about it. To make that frustration even better, a VP followed that up by saying that we *should not* write such documentation, that we should all meet. Then, we waited again. In Monday's stand-up, I said that I was impeded by the fact that I had conflicting instructions from people above my pay grade, and that I needed a decision. After the stand-up, our scrum master scheduled a meeting for Wednesday morning at 10:30.
Do you see the direction this is going ..... ? Even better, do you see the root of the problem? I think I do ... but rather than speculate, I will let you draw your own conclusion. For now, I think I have covered plenty 'o reasons why the lack of a product owner is NOT GOOD.
10,000 ways to not invent a light bulb ...
Having grown up in Central Jersey, Thomas Edison's house was the standard field trip fare. I have been thinking a lot lately about that quote from him .... the one about 10,000 ways to *not* invent a light bulb, but only needing one way to get it right.
Hopefully, with each of the 10,000 failures, Thomas (and most of us, with any luck!) learned why the attempt did not work. So, let me see if I can explain the things that I have seen not work, and then more specifically, explain *why* it did not work.
Immediately after our team's stand-up yesterday, we were being told about changes that were coming, set down to us from our "Release Plan Steering Committee" (formerly the Sprint Governing Board). We were told that we were going to try a technique wrt our user story cards that we had not tried before. Some people wondered why we don't handle these things the way(s) that we have all read about, involving user story cards, and breaking the highest priority ones down into tasks in the planning meeting to determine what we thought we could reasonably get done in a sprint.
What I found was the veteran team members started explaining all of the reasons that doing things that way had not worked for us. I started thinking of our original scrum master, and how passionate he had been ... and of Ken Schwaber saying that the average burnout is 18 months. Well, we are on scrum master number 2, and he is trying the same things that this team has already tried, repeatedly ..... So, let me start with the obvious.
Why not having a single, prioritized, and clearly defined product backlog does not work
Here is how this process has (not) worked for us.
When we started trying agile, we had "stuff" that we needed to build. We didn't have user stories, but we did have cards. We tried to go through this process of going into the planning meeting with cards, breaking them down into tasks to complete them and estimating how much we could do. But here was the problem: The team didn't understand enough about the desired functionality to break it down into tasks. As a result, we would spend the better part of a whole day trying to answer the questions we had.
Simple to solve, you say? Just have the Product Owner there, and he/she can answer those questions, and hopefully after a time of two of LOTS of questions, he/she will learn to start thinking through those kind of questions *before* the planning meeting!
Ah, there it was .... that word: "just". Our team has banned that word, among others.
Problem 1 with that statement: To this day, there is not a clear "product owner". There are several, and they conflict with each other, and ALL of their stuff is the Toppermost Toppermost priority. So I will have to write a "Why not having a product owner doesn't work".
At some point, our upper management decided that a *whole day* in planning meetings was too much. So we started having a shorter planning meeting - 1/2 a day. Well, since the lack of defined backlog items problem had not gone away, this just made things worse. We went into even *less* detail in planning, and we were WAY off of our estimates.
Next, they brought in a consultant, a scrum "expert", if you will. He suggested that we stop breaking things down into tasks and that we start writing better user stories. He suggested that we try to break each user story down into some detail on the back of the card, asking the questions of the product owner(s) before the planning meeting. He suggested that in the planning meeting, we just estimate the whole user story.
Okay ..... well, we have been dong that. And, we have struggled with estimating a user story card in story points, and then assigning a number of days to that story card. As one of our team members has said repeatedly, "when you estimate in hours, you are off by hours. when you estimate in days, you are off by days" (I don't know how much I agree with that, but ... it's not a bad concept).
So, the dictate that the team got yesterday from the Steering Committee says that we will no longer put days estimates on story cards. We will only worry about user story points and try to pick off the top points in the planning meeting.
Can you guess how well this will work? I can .. and I think the way to fix the problem, is to fix the problem. We need a single backlog, and it needs to be well-defined and prioritized.
Hopefully, with each of the 10,000 failures, Thomas (and most of us, with any luck!) learned why the attempt did not work. So, let me see if I can explain the things that I have seen not work, and then more specifically, explain *why* it did not work.
Immediately after our team's stand-up yesterday, we were being told about changes that were coming, set down to us from our "Release Plan Steering Committee" (formerly the Sprint Governing Board). We were told that we were going to try a technique wrt our user story cards that we had not tried before. Some people wondered why we don't handle these things the way(s) that we have all read about, involving user story cards, and breaking the highest priority ones down into tasks in the planning meeting to determine what we thought we could reasonably get done in a sprint.
What I found was the veteran team members started explaining all of the reasons that doing things that way had not worked for us. I started thinking of our original scrum master, and how passionate he had been ... and of Ken Schwaber saying that the average burnout is 18 months. Well, we are on scrum master number 2, and he is trying the same things that this team has already tried, repeatedly ..... So, let me start with the obvious.
Why not having a single, prioritized, and clearly defined product backlog does not work
Here is how this process has (not) worked for us.
When we started trying agile, we had "stuff" that we needed to build. We didn't have user stories, but we did have cards. We tried to go through this process of going into the planning meeting with cards, breaking them down into tasks to complete them and estimating how much we could do. But here was the problem: The team didn't understand enough about the desired functionality to break it down into tasks. As a result, we would spend the better part of a whole day trying to answer the questions we had.
Simple to solve, you say? Just have the Product Owner there, and he/she can answer those questions, and hopefully after a time of two of LOTS of questions, he/she will learn to start thinking through those kind of questions *before* the planning meeting!
Ah, there it was .... that word: "just". Our team has banned that word, among others.
Problem 1 with that statement: To this day, there is not a clear "product owner". There are several, and they conflict with each other, and ALL of their stuff is the Toppermost Toppermost priority. So I will have to write a "Why not having a product owner doesn't work".
At some point, our upper management decided that a *whole day* in planning meetings was too much. So we started having a shorter planning meeting - 1/2 a day. Well, since the lack of defined backlog items problem had not gone away, this just made things worse. We went into even *less* detail in planning, and we were WAY off of our estimates.
Next, they brought in a consultant, a scrum "expert", if you will. He suggested that we stop breaking things down into tasks and that we start writing better user stories. He suggested that we try to break each user story down into some detail on the back of the card, asking the questions of the product owner(s) before the planning meeting. He suggested that in the planning meeting, we just estimate the whole user story.
Okay ..... well, we have been dong that. And, we have struggled with estimating a user story card in story points, and then assigning a number of days to that story card. As one of our team members has said repeatedly, "when you estimate in hours, you are off by hours. when you estimate in days, you are off by days" (I don't know how much I agree with that, but ... it's not a bad concept).
So, the dictate that the team got yesterday from the Steering Committee says that we will no longer put days estimates on story cards. We will only worry about user story points and try to pick off the top
Can you guess how well this will work? I can .. and I think the way to fix the problem, is to fix the problem. We need a single backlog, and it needs to be well-defined and prioritized.
Saturday, August 2, 2008
Deprecated ScrumMaster
I should be writing this blog ... but I am not. It's got some good stuff about how scrum and agile can be twisted until they are no longer recognizable. I know that feeling oh-so-well .....
A little off-topic .... GTD?
I was looking just now at all of the tabs that open as my "home pages". One of them, that I'd like to talk about and perhaps get comments on, is Toodledo.
A few months ago, I got all into the whole GTD thing again. I started trying to find GTD software that would help me keep the things I needed to do organized. I read about everything from text files to settings in Outlook to full-fledged standalone software.
Eventually, I chose Toodledo (www.toodledo.com). It's free and web-based. Here are the reasons I liked this particular method:
A few months ago, I got all into the whole GTD thing again. I started trying to find GTD software that would help me keep the things I needed to do organized. I read about everything from text files to settings in Outlook to full-fledged standalone software.
Eventually, I chose Toodledo (www.toodledo.com). It's free and web-based. Here are the reasons I liked this particular method:
- First and foremost, it was about portability. It's web-based, and usually I don't like web-based things for interface reasons, but in this case, the portability outweighed clunkiness. Biggest reason I liked it: It has a mobile site, and I know that I *always* have my Blackberry with me. This way, if I wanted to add things as I thought of them, I could hit the mobile page in the BB Browser and enter my item.
- Portability, part 2: I have a Mac at home and a PC for work. The Mac is not allowed to go to work. Therefore, any standalone software package that had to stay on one computer would only be available for me to enter items or clear items while I was at home.
- Features I liked, off the top of my head: short-term goals, long-term goals, contexts, folders, tags .... I could organize things any way I want and customize my view to show me my items in the ways that were applicable to the organization method I chose.
- Other features: collaboration, due dates, hierarchies ..........
Wishing I was going to Agile 2008 ....
I am most definitely wishing I was going to Agile 2008. I have seen on the Yahoo groups and on the web page that there will be many people there that I would love to listen to and learn from. I saw that someone is posting constant updates from there and I will certainly be following that.
http://friendfeed.com/rooms/agile-2008
I'll be watching the Twitterers as well. To the people I know who are going, I'll be there in spirit!
http://friendfeed.com/rooms/agile-2008
I'll be watching the Twitterers as well. To the people I know who are going, I'll be there in spirit!
Thursday, July 10, 2008
More questions, again
Reading the agile-testing list recently, I came up with a few questions that I have seen a few answers to, but would like to figure out a few more details on.
How do people out there handle "documentation"? "Requirements"? We have user story cards, and we all recognize that these cards don't have the necessary detail. We do try to have the conversations that the user story cards should necessitate as well. The success varies, but still, there are details associated with a card that we still don't do a very good job of documenting.
We have struggled with where to put this info. We are all .NET, running TFS. We have the Cochango Scrum for TFS framework that sits on top of TFS, but we aren't very good about using it. It contains Product backlog items, Sprint backlog items, bugs, imepdiments, etc ..... The team just hasn't been very good about actually putting stuff into it.
2 sprints ago, we tried a wiki page. One guy spent a bunch of time documenting everything he could as the 'power of 3' meetings occurred at the beginning of the sprint. Then, nobody touched them again.
We have remote employees, and they tend to be impacted the most, especially remote testers. They get notification that a user story is code complete, and then they tend to come to me and say "I don't know where to even start with this story" (yes, they should have been involved from the beginning .... baby steps).
So, how are other people handling documenting the info for a user story?
How do people out there handle "documentation"? "Requirements"? We have user story cards, and we all recognize that these cards don't have the necessary detail. We do try to have the conversations that the user story cards should necessitate as well. The success varies, but still, there are details associated with a card that we still don't do a very good job of documenting.
We have struggled with where to put this info. We are all .NET, running TFS. We have the Cochango Scrum for TFS framework that sits on top of TFS, but we aren't very good about using it. It contains Product backlog items, Sprint backlog items, bugs, imepdiments, etc ..... The team just hasn't been very good about actually putting stuff into it.
2 sprints ago, we tried a wiki page. One guy spent a bunch of time documenting everything he could as the 'power of 3' meetings occurred at the beginning of the sprint. Then, nobody touched them again.
We have remote employees, and they tend to be impacted the most, especially remote testers. They get notification that a user story is code complete, and then they tend to come to me and say "I don't know where to even start with this story" (yes, they should have been involved from the beginning .... baby steps).
So, how are other people handling documenting the info for a user story?
Questions, and more questions
So, I have been reading Lisa Crispin's blog lately, and as usual, I have read most of her recent ones with a whole bunch of "yeah, but what if ... ?" questions in my head. I thought about just emailing her directly, but eventually decided that other people might have similar questions, and well, honestly, it's been a while since my last post.
I think the biggest thing that I have read from her recently that I have difficulty with is the ides of focusing on one story at a time thing. To quote her: "Try to quit multitasking, and focus on getting one thing done".
Hmmmm .... but what if you can't, because people above you won't let you? What if, at any given time, you are juggling half a dozen tasks? To take that variable out of the equation, what if the stories' interdependencies aren't clear enough, and you really can't finish one story until another story (that has not yet been completed) *gets* completed?
In my team, we have enough people involved who aren't really a part of the team, that we end up with a nontrivial amount of "this story is waiting on X person before it can continue".
Of course, fundamentally, I *know* the answers to many of these questions .... Have a clear product owner, have people who are more dedicated to the team, etc. But what if we can't? Are there still ways to work around those "higher than us" non-commitments, and still succeed as a team?
I think the biggest thing that I have read from her recently that I have difficulty with is the ides of focusing on one story at a time thing. To quote her: "Try to quit multitasking, and focus on getting one thing done".
Hmmmm .... but what if you can't, because people above you won't let you? What if, at any given time, you are juggling half a dozen tasks? To take that variable out of the equation, what if the stories' interdependencies aren't clear enough, and you really can't finish one story until another story (that has not yet been completed) *gets* completed?
In my team, we have enough people involved who aren't really a part of the team, that we end up with a nontrivial amount of "this story is waiting on X person before it can continue".
Of course, fundamentally, I *know* the answers to many of these questions .... Have a clear product owner, have people who are more dedicated to the team, etc. But what if we can't? Are there still ways to work around those "higher than us" non-commitments, and still succeed as a team?
Thursday, June 12, 2008
What do you mean, don't submit bugs?
Of all of my "aha!" moments in transitioning from a waterfall-style QA person to an agile tester, the one I am about to talk about is *definitely* in the top 3. Top 5, most .... *Definitely* top 10. :)
I have to give my credit to Janet Gregory, yet again ... during her presentation at STAREast that I named in my last post. This one, in particular, hit me personally, rather than being a suggestion for the whole team.
Janet talked about how as an agile tester, the "Quality Police" mindset must be avoided. I have to admit, I am *really* guilty of playing "quality police". *REALLY* guilty .... However, I was *really shocked* when she said that one of the indicators that you may be playing "quality police" is that you insist that all bugs go into a bug tracking system.
"Well, DUUUUUUUH," I thought, "OF COURSE all bugs go into the bug tracking system!"
(pause)
Wait. What?
As this discussion went on, I learned that there was a practice that I not only had never thought of, but actually made sense! It went something like this: When testing in the scope of a user story inside a sprint, DON'T SUBMIT BUGS. Just go talk to the developer and have him fix it!
I brought this idea back to my team. It was easy to sell this one ... I was able to play the humble one, and show them Janet's slide that shows the indicators for "quality police". We all had a big laugh while the list was read ... describing me, just about to a tee.
The amazing part, however, was that within hours, I could hear testers going to developers and talking about things they found, and I could hear developers yelling, "Hey Sally! I checked in that change. Get latest and let me know." It was almost like this team was waiting for exactly this kind of idea.
What we decided follows roughly this pattern: If a tester is testing a user story card within the scope of a sprint and finds a small problem that can be fixed easily, they just go talk to the developer (maybe send an email ... ). Bugs are submitted if issues are found relating to work done in a previous sprint, or if an issue is so big that it can't easily be fixed within the scope of the current sprint, or if we hear about issues from our customers (our product owners or beta users, for example).
I monitor the bug list and watch for developer activity during a sprint that relates to issues in the bug list. If I see that a developer is working in a certain section of code, I ask if he can look into the related issue. In this way, I still get to play quality police *a little* ....
Benefits that we see from this process:
I have to give my credit to Janet Gregory, yet again ... during her presentation at STAREast that I named in my last post. This one, in particular, hit me personally, rather than being a suggestion for the whole team.
Janet talked about how as an agile tester, the "Quality Police" mindset must be avoided. I have to admit, I am *really* guilty of playing "quality police". *REALLY* guilty .... However, I was *really shocked* when she said that one of the indicators that you may be playing "quality police" is that you insist that all bugs go into a bug tracking system.
"Well, DUUUUUUUH," I thought, "OF COURSE all bugs go into the bug tracking system!"
(pause)
Wait. What?
As this discussion went on, I learned that there was a practice that I not only had never thought of, but actually made sense! It went something like this: When testing in the scope of a user story inside a sprint, DON'T SUBMIT BUGS. Just go talk to the developer and have him fix it!
I brought this idea back to my team. It was easy to sell this one ... I was able to play the humble one, and show them Janet's slide that shows the indicators for "quality police". We all had a big laugh while the list was read ... describing me, just about to a tee.
The amazing part, however, was that within hours, I could hear testers going to developers and talking about things they found, and I could hear developers yelling, "Hey Sally! I checked in that change. Get latest and let me know." It was almost like this team was waiting for exactly this kind of idea.
What we decided follows roughly this pattern: If a tester is testing a user story card within the scope of a sprint and finds a small problem that can be fixed easily, they just go talk to the developer (maybe send an email ... ). Bugs are submitted if issues are found relating to work done in a previous sprint, or if an issue is so big that it can't easily be fixed within the scope of the current sprint, or if we hear about issues from our customers (our product owners or beta users, for example).
I monitor the bug list and watch for developer activity during a sprint that relates to issues in the bug list. If I see that a developer is working in a certain section of code, I ask if he can look into the related issue. In this way, I still get to play quality police *a little* ....
Benefits that we see from this process:
- fewer bugs (which means less of everyone's time reviewing bugs) !!
- more developer/tester interaction ... better relationships
- better tester insight into developer processes (they talk about where problems are in the code)
- less email traffic
- cards marked as 'done' earlier
- ? I haven't yet seen any direct pitfalls .... the one concern I have is not being able to analyze issues for patterns. I have in the past, seen a bug crop up several times, and being able to review previous discussions and/or fixes can help reduce troubleshooting/fixing time. Instinct tells me that I can look through checkin comments just as easily ..... but this is an edge case, nonetheless ......
Tuesday, June 3, 2008
Give it a name, and they will follow ....
Ok, well, my idea of going chronologically is blown ... I have to say, I learned the most from my recent trip to STAREast, and I think that those are the most valuable lessons I can share.
Part of my problem with this agile transition has always been that I am a "details girl" (that's what they say here). I can read LOTS of Schwaber and Cohn and get lots of concepts and ideas, but I really need the details ... exactly *how* do I follow the procedures outlined therein?
I got LOTS of those ideas at STAREast, so I will talk about one of them now.
This one came from Janet Gregory's track talk, called "Perils and Pitfalls of the New Agile Tester". The concept was called "The Power of 3". I brought this idea back to work ...
Here is the problem it solved for me, and helped the team with: lack of everyone being on the same page. The problem plays out in many ways, and I know it happens whether you do waterfall or agile or whatever. There exists some requirement/user story/work piece, and over time, someone comes up with a question and asks someone else. Perhaps it's the tester who asks the developer, and they make a decision and move on ... to the surprise of the product owner, who then looks at it and says "That's not what I wanted it to do!"
For me, the frustration has been when a developer asks product owner questions and they hash out some details, but I don't know about them. Then when it comes time to test, I feel like I start over from the beginning. I ask questions, and someone says "Oh yeah, I talked to Joe about that and we decided x" (for privacy reason, names of coworkers have been changed :) ).
GRR.
I have suggested many ways to try to alleviate this ... and as I think about it now, I don't think my suggestions hit the problem early enough (the Power of 3 does!). I had asked for a group email list, and we required that all questions were sent out to the list, so that everyone would know the answer. Several people complained that this filled their inbox with too many emails. I made it worse by suggesting that verbal conversations (since they were bound to happen), be followed up with an email to the list with the info discussed in the conversation. Do you think anyone followed through with this? Of course not (I don't think I even did that one!).
How the Power of 3 works for us: The basic idea is that for any discussion on a user story card, all 3 stakeholders must be involved. The 3 stakeholders on our cards are the product owner, the developer, and the tester. All of these are assigned (if not obvious, like product owner), during the planning meeting. So, if the developer wants to ask a question of the product owner, one of them just needs to remember to grab the tester as well.
To my surprise,the team took to this really well!!! We all still forget once in a while, but if I just poke with a little "power of 3", they realize it should have included someone else, and then laugh at me :) I love this concept, and since I had not yet come up with it on my own, was *so happy* to hear it at the conference.
I have been totally excited to see little meeting requests go out that say "power of 3 discussion about x group of cards" .... (we have MANY meetings, so I cannot escape that yet). It seems, that if you just put a catchy phrase on a concept, it's more fun to implement.
Part of my problem with this agile transition has always been that I am a "details girl" (that's what they say here). I can read LOTS of Schwaber and Cohn and get lots of concepts and ideas, but I really need the details ... exactly *how* do I follow the procedures outlined therein?
I got LOTS of those ideas at STAREast, so I will talk about one of them now.
This one came from Janet Gregory's track talk, called "Perils and Pitfalls of the New Agile Tester". The concept was called "The Power of 3". I brought this idea back to work ...
Here is the problem it solved for me, and helped the team with: lack of everyone being on the same page. The problem plays out in many ways, and I know it happens whether you do waterfall or agile or whatever. There exists some requirement/user story/work piece, and over time, someone comes up with a question and asks someone else. Perhaps it's the tester who asks the developer, and they make a decision and move on ... to the surprise of the product owner, who then looks at it and says "That's not what I wanted it to do!"
For me, the frustration has been when a developer asks product owner questions and they hash out some details, but I don't know about them. Then when it comes time to test, I feel like I start over from the beginning. I ask questions, and someone says "Oh yeah, I talked to Joe about that and we decided x" (for privacy reason, names of coworkers have been changed :) ).
GRR.
I have suggested many ways to try to alleviate this ... and as I think about it now, I don't think my suggestions hit the problem early enough (the Power of 3 does!). I had asked for a group email list, and we required that all questions were sent out to the list, so that everyone would know the answer. Several people complained that this filled their inbox with too many emails. I made it worse by suggesting that verbal conversations (since they were bound to happen), be followed up with an email to the list with the info discussed in the conversation. Do you think anyone followed through with this? Of course not (I don't think I even did that one!).
How the Power of 3 works for us: The basic idea is that for any discussion on a user story card, all 3 stakeholders must be involved. The 3 stakeholders on our cards are the product owner, the developer, and the tester. All of these are assigned (if not obvious, like product owner), during the planning meeting. So, if the developer wants to ask a question of the product owner, one of them just needs to remember to grab the tester as well.
To my surprise,the team took to this really well!!! We all still forget once in a while, but if I just poke with a little "power of 3", they realize it should have included someone else, and then laugh at me :) I love this concept, and since I had not yet come up with it on my own, was *so happy* to hear it at the conference.
I have been totally excited to see little meeting requests go out that say "power of 3 discussion about x group of cards" .... (we have MANY meetings, so I cannot escape that yet). It seems, that if you just put a catchy phrase on a concept, it's more fun to implement.
Friday, May 30, 2008
How *NOT* to win the hearts of developers, part 2
So, this next one, for me, points out something that I felt was a difficulty in being a tester with development experience.
I don't believe I handled it the best way, but hope that I can use it as an example and teach, perhaps, better ways to deal with developers.
Not long after I started, we were developing a way to download data from our website to a file. The requirements said that the file name had to be alphanumeric, with spaces allowed. This seems easy enough to test, right? So, in the file name field, I held down my shift key and I went all over the keyboard:
~!@#$%^&*()_+|}{":?/.,';\][=-`
As I expected, I broke the site. Broke it in a bad way, like big exception on the screen. Wowee ... I filed a bug. It got worked on, and I repeated my steps in the file name field.
~!@#$%^&*()_+|}{":?/.,';\][=-`
AHA! The SAME THING HAPPENED! Incredulous, I walked over to the developer's desk, sat down, and talked about the issue with him. He pulled up the source code. I couldn't believe what I saw. It looked something like this (pseudo-code):
for (each char in filename field) {
if (char == !) {
pop message up to the user about invalid chars;
if (char == @) {
pop message up to the user about invalid chars;
if (char == #) {
pop message up to the user about invalid chars;
if (char == $) {
pop message up to the user about invalid chars;
if (char == %) {
pop message up to the user about invalid chars;
if (char == ^) {
pop message up to the user about invalid chars;
if (char == &) {
pop message up to the user about invalid chars;
and so on .....
*GASP* I absolutely could not believe what I saw. CS 102 taught me better than that. So I said to him "Why are you doing it that way? Can't you use something like a regular expression?" He said something like "Oh, well, Java doesn't have regular expressions." Me: "Um, yes it does. I have used them. In Java." Him: "Well, I don't know how to use them, so this will work for now."
Huh? Angry that he had tried to pull a fast one on me, absolutely shocked that it was being done how it was being done, I left the conversation. I ended up talking to a few other people, informally, about my concern, but nothing happened immediately. Of course, he found out I had complained about him (I don't suppose I expressed it in the nicest way), and once again, I had created a dev vs. QA situation.
Eventually, I worked out the relationship with said developer, and made it a friendly one again. That code was never released.
As I thought about it later ... I realized that I *did* know how to do what needed to be done, but I let his strictly "tester" view of me prevent me from trying to teach him how to be a better developer. In hindsight, when the conversation hit the "Well, I don't know how to do it" point, I should have been able to say, "Okay, let's work through this together and let me show you. Let's find the regex class ..." etc. I have found since then that our developers are generally pretty open to sitting down together with me and letting me show them a way to do something that I have used before.
Laughing at myself yet again ... in a more true to agile way, the team works much better when testers and developers can just sit together for a while, and non-confrontationally (I don't think that's a word, but it's a quality I strive for) discuss the pros and cons of using certain strategies for solving problems. I have seen many problems solved really early when I pair program/test with a developer as they code, when I can ask the questions and point out the things that I know will come up in my testing. It just makes sense.
I don't believe I handled it the best way, but hope that I can use it as an example and teach, perhaps, better ways to deal with developers.
Not long after I started, we were developing a way to download data from our website to a file. The requirements said that the file name had to be alphanumeric, with spaces allowed. This seems easy enough to test, right? So, in the file name field, I held down my shift key and I went all over the keyboard:
~!@#$%^&*()_+|}{":?/.,';\][=-`
As I expected, I broke the site. Broke it in a bad way, like big exception on the screen. Wowee ... I filed a bug. It got worked on, and I repeated my steps in the file name field.
~!@#$%^&*()_+|}{":?/.,';\][=-`
AHA! The SAME THING HAPPENED! Incredulous, I walked over to the developer's desk, sat down, and talked about the issue with him. He pulled up the source code. I couldn't believe what I saw. It looked something like this (pseudo-code):
for (each char in filename field) {
if (char == !) {
pop message up to the user about invalid chars;
if (char == @) {
pop message up to the user about invalid chars;
if (char == #) {
pop message up to the user about invalid chars;
if (char == $) {
pop message up to the user about invalid chars;
if (char == %) {
pop message up to the user about invalid chars;
if (char == ^) {
pop message up to the user about invalid chars;
if (char == &) {
pop message up to the user about invalid chars;
and so on .....
*GASP* I absolutely could not believe what I saw. CS 102 taught me better than that. So I said to him "Why are you doing it that way? Can't you use something like a regular expression?" He said something like "Oh, well, Java doesn't have regular expressions." Me: "Um, yes it does. I have used them. In Java." Him: "Well, I don't know how to use them, so this will work for now."
Huh? Angry that he had tried to pull a fast one on me, absolutely shocked that it was being done how it was being done, I left the conversation. I ended up talking to a few other people, informally, about my concern, but nothing happened immediately. Of course, he found out I had complained about him (I don't suppose I expressed it in the nicest way), and once again, I had created a dev vs. QA situation.
Eventually, I worked out the relationship with said developer, and made it a friendly one again. That code was never released.
As I thought about it later ... I realized that I *did* know how to do what needed to be done, but I let his strictly "tester" view of me prevent me from trying to teach him how to be a better developer. In hindsight, when the conversation hit the "Well, I don't know how to do it" point, I should have been able to say, "Okay, let's work through this together and let me show you. Let's find the regex class ..." etc. I have found since then that our developers are generally pretty open to sitting down together with me and letting me show them a way to do something that I have used before.
Laughing at myself yet again ... in a more true to agile way, the team works much better when testers and developers can just sit together for a while, and non-confrontationally (I don't think that's a word, but it's a quality I strive for) discuss the pros and cons of using certain strategies for solving problems. I have seen many problems solved really early when I pair program/test with a developer as they code, when I can ask the questions and point out the things that I know will come up in my testing. It just makes sense.
Tuesday, May 27, 2008
How *NOT* to win the hearts of developers, part 1
So, I had this crazy idea that I would try to do this blog in some chronological order, since a lot of the early posts will be historical lessons.
I know it won't happen that way, but I will at least start pretty early.
I recently attended the STAREast conference, and during Janet Gregory's agile testing talk, I heard her talk about some qualities that an agile tester should NOT have that sounded eerily like me. The team got a kick out of my presentation to them after I got back, where I talked about how testers who acted like "quality police" did no good for an agile team. It was a big lesson for me, and very humbling.
So let me tell you one thing NOT TO DO when you are trying to help a team of developers transition to agile. Come to think of it, it reminds me of a Thomas Edison quote about being able to tell you 10,000 ways NOT to make an electric light bulb .... (I grew up just a few towns south of Edison, NJ).
In any case, in one of my first official testing assignments at Rainbow, I had very much a "quality police" mindset still. Their adoption of scrum had not yet quite kicked in, and they did a whole bunch of development and then gave me a final product to test.
And test I did. That night, working fervently from home, I sent an email out with 37 bugs in it (bugs over email? I will address this later). Though I was rather proud of myself at the time (37 bugs! YEAH!), it turned out the team was not quite ready for that. There were complaints of not being able to tell the status of the issues I had sent out, not knowing who was working on what issue, not knowing which issues they were required to fix ....
In short, I had created chaos. A testing and development nightmare. I had, unwittingly, pitted myself against the development team, thus splitting our budding agile team into dev vs. QA. I have a tendency to come on strong ... and the team learned it early and thoroughly.
Recently, I have suggested a few changes to the way we do things ... now, our testers are involved at the initial stages of user story development. We can run the web site locally and check on things the moment that a developer has finished some part of development (get latest, build, go to localhost website). I think most importantly, formal bugs are not submitted within the scope of a sprint's user story work ... if a tester sees an issue, he simply walks over to the developer (or IMs him or calls him) and says "hey, I see this thing, can we look at it together?"
I have watched these few changes bring our testers and developers closer. I have watched how much more comfortable they are talking to each other. I have learned how to become a more agile tester, and how much more effectively and efficiently a team can run when approached the right way.
I know it won't happen that way, but I will at least start pretty early.
I recently attended the STAREast conference, and during Janet Gregory's agile testing talk, I heard her talk about some qualities that an agile tester should NOT have that sounded eerily like me. The team got a kick out of my presentation to them after I got back, where I talked about how testers who acted like "quality police" did no good for an agile team. It was a big lesson for me, and very humbling.
So let me tell you one thing NOT TO DO when you are trying to help a team of developers transition to agile. Come to think of it, it reminds me of a Thomas Edison quote about being able to tell you 10,000 ways NOT to make an electric light bulb .... (I grew up just a few towns south of Edison, NJ).
In any case, in one of my first official testing assignments at Rainbow, I had very much a "quality police" mindset still. Their adoption of scrum had not yet quite kicked in, and they did a whole bunch of development and then gave me a final product to test.
And test I did. That night, working fervently from home, I sent an email out with 37 bugs in it (bugs over email? I will address this later). Though I was rather proud of myself at the time (37 bugs! YEAH!), it turned out the team was not quite ready for that. There were complaints of not being able to tell the status of the issues I had sent out, not knowing who was working on what issue, not knowing which issues they were required to fix ....
In short, I had created chaos. A testing and development nightmare. I had, unwittingly, pitted myself against the development team, thus splitting our budding agile team into dev vs. QA. I have a tendency to come on strong ... and the team learned it early and thoroughly.
Recently, I have suggested a few changes to the way we do things ... now, our testers are involved at the initial stages of user story development. We can run the web site locally and check on things the moment that a developer has finished some part of development (get latest, build, go to localhost website). I think most importantly, formal bugs are not submitted within the scope of a sprint's user story work ... if a tester sees an issue, he simply walks over to the developer (or IMs him or calls him) and says "hey, I see this thing, can we look at it together?"
I have watched these few changes bring our testers and developers closer. I have watched how much more comfortable they are talking to each other. I have learned how to become a more agile tester, and how much more effectively and efficiently a team can run when approached the right way.
Monday, May 26, 2008
Zero to Sixty Agile Testing
So, here is my first blog post .... let me give you a little introduction and some background to my current story.
I am Dawn, developer-tester and tester-developer ... I have my BS in Comp Sci from Clemson University. I spent 6 years with a bioinformatics company, starting as a part-time tester, and eventually becoming QA Lead. I had a large part in creating their QA department -- policies, procedures, bug tracking, training, the whole gamut. We used Test Director and WinRunner for a while. I was able to keep my hand in some development, for our internally written bug tracking system and for a project I was technical Project Lead on for the NSF. I can still remember hearing the word 'agile' for the first time while I was there.
When I left that job, I did some .NET development for a while. I developed several enterprise applications, from website/database to mobile/web services apps. I learned a LOT there, like all of the reasons why I don't want to be a developer full-time.
I was happy to get a QA Engineer job at Symantec when I decided full-time development wasn't working for me. However, not long after I got there, Symantec decided that our local office wasn't worth keeping open, and I found myself looking for a job, along with a few hundred other developers and testers. Symantec was one of the best jobs I have ever had.
To my surprise, at about that exact time, a local company, just 2.5 miles from home, had posted for a QA Engineer position that I was a perfect fit for. They were hoping for someone with at least a familiarity with development, and as it turned out, they had never had any formal QA. Luckily, I had experience building a QA department from the ground up. I will call this company 'Rainbow' from this point on.
This is where I get my "Zero to Sixty" reference .... this development team had just started Scrum, just 2 weeks before I started. So ... not only had they never had any formal testing of their products, but they were just starting the transition to an agile team. The road has been bumpy, to say the least, but I have found that as much I thought I had to teach these guys, I have learned some incredible lessons along the way about agile and how testing fits in.
I hope that this blog will tackle, one by one, many of the lessons that I have learned, and the ones that I have taught along the way ..... so buckle your seat belts (yes, I realize how completely dorky that reference was), and get ready.
I am Dawn, developer-tester and tester-developer ... I have my BS in Comp Sci from Clemson University. I spent 6 years with a bioinformatics company, starting as a part-time tester, and eventually becoming QA Lead. I had a large part in creating their QA department -- policies, procedures, bug tracking, training, the whole gamut. We used Test Director and WinRunner for a while. I was able to keep my hand in some development, for our internally written bug tracking system and for a project I was technical Project Lead on for the NSF. I can still remember hearing the word 'agile' for the first time while I was there.
When I left that job, I did some .NET development for a while. I developed several enterprise applications, from website/database to mobile/web services apps. I learned a LOT there, like all of the reasons why I don't want to be a developer full-time.
I was happy to get a QA Engineer job at Symantec when I decided full-time development wasn't working for me. However, not long after I got there, Symantec decided that our local office wasn't worth keeping open, and I found myself looking for a job, along with a few hundred other developers and testers. Symantec was one of the best jobs I have ever had.
To my surprise, at about that exact time, a local company, just 2.5 miles from home, had posted for a QA Engineer position that I was a perfect fit for. They were hoping for someone with at least a familiarity with development, and as it turned out, they had never had any formal QA. Luckily, I had experience building a QA department from the ground up. I will call this company 'Rainbow' from this point on.
This is where I get my "Zero to Sixty" reference .... this development team had just started Scrum, just 2 weeks before I started. So ... not only had they never had any formal testing of their products, but they were just starting the transition to an agile team. The road has been bumpy, to say the least, but I have found that as much I thought I had to teach these guys, I have learned some incredible lessons along the way about agile and how testing fits in.
I hope that this blog will tackle, one by one, many of the lessons that I have learned, and the ones that I have taught along the way ..... so buckle your seat belts (yes, I realize how completely dorky that reference was), and get ready.
Subscribe to:
Posts (Atom)