What do you do when you are "just a QA person" or "just a tester", and you *know* *know* *know*, down in the deepest depths of your coding soul, that the developers on your team are DOIN IT RONG?
Do you quit the job and go find some decent coders? Nah ... What fun is there in that?
Yesterday, I attended Agilepalooza 2009 in Charlotte, NC. There were 2 main tracks, one for learning about agility with several speakers lined up and one for "advancing agility", which was Open Space format. David Hussman was there, and so was Jeff Sutherland, with whom I got to have a great discussion about testing on an agile team. It was a VersionOne sponsored event, and yes, it was myself who yelled out during the introductory meeting "Does anyone use Rally?" You don't have to believe me that I honestly did not know at that point that V1 sponsored it, though I sure played on that point later.
ANYWAY, I digress. I *love* going to conferences, especially those that allow for the opportunity to have in-depth discussions with others out there "in the trenches". I get some practical knowledge out of talks, but I get the *most* out of talking to individuals, and being able to say "I am struggling with this particular problem right now ... have you dealt with this before, and/or do you have any suggestions?" I have found that most of the Agile community, and especially the testing-focused subset, are always very willing to help and share and ask for your help right back.
So I had the opportunity to ask a few people my most pressing "What do you do when ... ?" questions, and here are some of my highlights.
Q: "What do you do when you know that the software you are developing against is unstable and likely not even following normal standards?"
A: Try Fxcop (I'm working on .NET apps), or FindBug for Java. WOW! I have actually heard of FindBug before, but haven't worked that deeply on Java programs in some time, so I have not spent much time with it. I got an opportunity to check out the fact that Fxcop has a whole type of messages centering on Performance, which happens to be a specific focus for my current project. I CAN'T WAIT to be able to use it.
Here's where this answer gets creative though. In true "don't pull punches" form, I would be the type to toss all 8,000 errors (arbitrary number) at my dev team. Instead, it was suggested that I pick a SINGLE error, print it out, and take it to a developer. I can tell them that I was using this tool (Fxcop), and here was an error (relevant to current work) that might help our current efforts. I love the idea, and I don't think I would have ever thought of it on my own. It is so simple, yet so ingenious .... I'll be doing this one soon.
Q: "What do you do when you are having trouble automating tests around custom controls that require some specific events to be called?"
A: Grab a network sniffer and watch exactly what events get called in the background! In this particular case, the suggestion was to use Knoppix (a lightweight Linux distro), which has a sniffer built in, or Chris McMahon suggested wireshark.
So, my background on this question is that I have been trying to throw some automated tests onto our web client, and we use Infragistics controls. I know that IG (Infragistics) uses Webaii internally, but still have been unable to get through exactly what I need to call and in what order to get Webaii to interact with these guys. The disappointing thing is that Telerik, who released Webaii AND who also makes custom controls (RAD Controls), posts right in their forums and on blogs about how to automate their controls. Infragistics does not. I have tried many permutations of interactions with these controls (my immediate need has been a WebCombo and a button), and have eventually had to put them on a back burner for other tasks.
However, if I can get past that one hurdle immediately, I can move forward with starting the seriously overdue task of putting some automation around our software.
Ok, those are my 2 biggest takeaways from yesterday, and I am sure there will be more later .... For the record, I have to give credit to Jared Richardson for the ideas presented above. It was really great to meet him and to talk with him about some specific issues, even if he did almost fall off the table listening to me :)
Saturday, August 15, 2009
Thursday, June 4, 2009
Help! My Selenium tests are flaky!
In my development of Selenium tests, I have come to dread the oh-so-common "Permission denied" errors. A quick scan of google search results indicates that there is likely some cross-domain issue, and a suggested workaround is using an experimental browser, like *iehta. I generally use *iehta anyway, and still seem to have problems with the "Permission denied" error.
In my most recent experience, testing against what seems to be an inconsistently slow and sometimes flaky web app, I have come to expect that "Permission denied" usually indicates that an element that I am trying to access is not yet accessible. For my app, which is heavily AJAXed, "waitforpagetoload" doesn't cut it. Since the AJAX scripts are still running, Selenium would wait until the end of time (or the timeout, whichever comes first) for the page to load and it would not.
So, I found a few people who solved this problem by creating a function that would wait for a specific element to load. I decided to go with it, and now my "WaitForElement" function is standard in my local Selenium Template for Visual Studio.
This function looks like this (this is C# code):
private void WaitForElement(string elementName)
{
for (int second = 0; ; second++)
{
if (second >= 120) Assert.Fail("timeout");
try
{
if (selenium.IsElementPresent(elementName)) break;
}
catch (Exception e) { }
Thread.Sleep(1000);
}
}
I call this function the first time I am going to take action after the web app has has to re-load or re-render elements. I tend to pass it the element which I am wanting to interact with first.
So in my test, the steps tend to look like this:
selenium.Click("btn1");
WaitForElement("txtBox1");
selenium.Type("txtBox1", "username");
I have seen some other suggestions from people on stabilizing selenium tests, but would love to hear from anyone else who has worked out a way to make their selenium tests less fail-prone.
In my most recent experience, testing against what seems to be an inconsistently slow and sometimes flaky web app, I have come to expect that "Permission denied" usually indicates that an element that I am trying to access is not yet accessible. For my app, which is heavily AJAXed, "waitforpagetoload" doesn't cut it. Since the AJAX scripts are still running, Selenium would wait until the end of time (or the timeout, whichever comes first) for the page to load and it would not.
So, I found a few people who solved this problem by creating a function that would wait for a specific element to load. I decided to go with it, and now my "WaitForElement" function is standard in my local Selenium Template for Visual Studio.
This function looks like this (this is C# code):
private void WaitForElement(string elementName)
{
for (int second = 0; ; second++)
{
if (second >= 120) Assert.Fail("timeout");
try
{
if (selenium.IsElementPresent(elementName)) break;
}
catch (Exception e) { }
Thread.Sleep(1000);
}
}
I call this function the first time I am going to take action after the web app has has to re-load or re-render elements. I tend to pass it the element which I am wanting to interact with first.
So in my test, the steps tend to look like this:
selenium.Click("btn1");
WaitForElement("txtBox1");
selenium.Type("txtBox1", "username");
I have seen some other suggestions from people on stabilizing selenium tests, but would love to hear from anyone else who has worked out a way to make their selenium tests less fail-prone.
Tuesday, May 5, 2009
Back to blogging ... Selenium and modal dialogs
It has been *way* too long since my last blog post, but another post is better late than never, right?
Most recently, I have struggled through automating a heavily AJAX-ey and fairly complex web interface using Selenium.
I have a setup that looks like this:
Visual Studio C# Express
NUnit
Selenium RC
IE Developer Toolbar, for identifying objects on the page
(and now AutoIT)
The occasional use of the Selenium IDE for speed and efficiency's sake.
I was having this particularly stubborn problem with a little dialog that popped up to confirm completion of some action, such as "User profile saved successfully". To this day, I am not 100% certain that I can identify what to call this guy: A pop-up? Alert? Confirmation? IE modal dialog?
Selenium IDE did not record or recognize in any way that this dialog exists. Further, my IE developer toolbar does not recognize this dialog when it's up, either. This all makes identifying it a bit difficult.
In my Selenium script, I tried identifying it as a pop-up, I tried identifying it as an alert, confirmation, and prompt, and none of them worked. My research indicated that this might be an "IE modal dialog" -- which is not supported by Selenium.
As I reached out to the agile-testing Yahoo group for help, I asked the developers how this dialog was being created. They showed me some code that simply called a javascript alert. I am still a little confused about that part, since Selenium RC should capture javascript alerts and close them. (Eventually I figured out that if the alert was called without a page redirect, Selenium behaved as expected, but if it was called as part of a page redirect function, Selenium failed to get it.)
Here is what the code that calls this dialog looks like:
The only difference between that and a similar dialog that Selenium correctly handles are those couple of lines that do the redirect ("parent.SetIframeMainModule "). I am still unclear about why that throws a wrench into my Selenium script, but the bottom line was that my Selenium script was not running!
Chris McMahon responded to my thread on the agile testing list that he had successfully used AutoIT to "hit it with a hammer". After a little bit of searching online, I found a blog post where someone else had used this tool -- in this case, the poster created an executable that looked for windows with certain visible text, and just closes them. This script runs separately from the Selenium test, just constantly polling the windows. It's an ugly hack, but when I tried it, it worked and allowed my Selenium tests to run.
To give proper credit, here is a link to the blog that posted this particular solution:
Most recently, I have struggled through automating a heavily AJAX-ey and fairly complex web interface using Selenium.
I have a setup that looks like this:
Visual Studio C# Express
NUnit
Selenium RC
IE Developer Toolbar, for identifying objects on the page
(and now AutoIT)
The occasional use of the Selenium IDE for speed and efficiency's sake.
I was having this particularly stubborn problem with a little dialog that popped up to confirm completion of some action, such as "User profile saved successfully". To this day, I am not 100% certain that I can identify what to call this guy: A pop-up? Alert? Confirmation? IE modal dialog?
Selenium IDE did not record or recognize in any way that this dialog exists. Further, my IE developer toolbar does not recognize this dialog when it's up, either. This all makes identifying it a bit difficult.
In my Selenium script, I tried identifying it as a pop-up, I tried identifying it as an alert, confirmation, and prompt, and none of them worked. My research indicated that this might be an "IE modal dialog" -- which is not supported by Selenium.
As I reached out to the agile-testing Yahoo group for help, I asked the developers how this dialog was being created. They showed me some code that simply called a javascript alert. I am still a little confused about that part, since Selenium RC should capture javascript alerts and close them. (Eventually I figured out that if the alert was called without a page redirect, Selenium behaved as expected, but if it was called as part of a page redirect function, Selenium failed to get it.)
Here is what the code that calls this dialog looks like:
The only difference between that and a similar dialog that Selenium correctly handles are those couple of lines that do the redirect ("parent.
Chris McMahon responded to my thread on the agile testing list that he had successfully used AutoIT to "hit it with a hammer". After a little bit of searching online, I found a blog post where someone else had used this tool -- in this case, the poster created an executable that looked for windows with certain visible text, and just closes them. This script runs separately from the Selenium test, just constantly polling the windows. It's an ugly hack, but when I tried it, it worked and allowed my Selenium tests to run.
To give proper credit, here is a link to the blog that posted this particular solution:
Get rid of those pesky IE dialogs with AutoIt
I would still love to hear about more graceful solutions ... I understand that Watir has found a way to handle these types of issues, and would love to see Selenium also be able to handle them. Please comment if you have solved a similar problem in a different way!Friday, August 15, 2008
Why not letting a team self-organize does not work, part 1
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.
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.
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.
Subscribe to:
Posts (Atom)