Loading ...
Sorry, an error occurred while loading the content.

Re: Requirement communication between dev and PO

Expand Messages
  • gregc
    Jiang, Scrum is good at exposing problems. So it s been successful in that regard. And now that the problem is defined, let s look at ways to address it.
    Message 1 of 21 , Dec 6, 2012
    • 0 Attachment
      Jiang,

      Scrum is good at exposing problems. So it's been successful in that regard. And now that the problem is defined, let's look at ways to address it. There is a gap in design and that gap needs to be closed. Part of that can be closed through good collaboration around the story. The story has the three elements: the actual story, the conversation around it, and the joint development of the satisfaction criteria. This should be part of your definition of "ready" before a story can be accepted into a sprint. I'm confident if you do this, things will improve but I am not convinced your problem will be solved.

      A first step would be to lay out the design tasks (which I think for your team means detailed description of functionality, mock-ups, etc.) that aren't being adequately covered today and have the dev team and PO come to some understanding of who is responsible for each of these and how those tasks are going to get done. I think the Team also has to decide if they have the necessary skill set or if a skills gap needs to be filled. Out of this, at least the problem can be recognized, internalized, and the team can develop a plan to address it.

      The conundrum as I see it is the dev team doesn't want to own design. Their passion is for building, not designing. Yet the PO, even if he wants to own design, is unlikely to be able to deliver. Your PO is the VP of Product. And a VP of product has a lot of market facing responsibilities that will prevent him from being able to spend the time necessary to meet the dev team's expectations and needs. I don't think your core problem is with your scrum practices but rather with how you're organized.

      I don't know if this is possible for your company, but my first reaction is that you need a new PO. One who who has more of an analyst skill set. And then I would divide the VP of Product (i.e. product management) and PO responsibilities along the following lines:

      1) Your VP of Product will focus on understanding the market, VOC, competitive analysis, business strategy, product positioning and the strategic roadmap.

      2) The PO will focus on being the expert on the user and everything about the job the user is trying to accomplish (yes, this means the PO will need to be comfortable spending time with users. The knowledge the PO needs to succeed does not come second hand.) The PO will have responsibility, while still collaborating with the team, for feature definition (using stories as the main artifact with supplemental documents like mock-ups, business logic, and task flows as needed), usability, scoping, and the product roadmap.

      Once again, diagnosing via email is tough. Let me know if I've misinterpreted your situation. Also, it sounds like you're a relatively young company. If your company has not yet achieved product-market fit and a scalable business model, I would organize slightly differently.

      Best,

      -greg

      --- In scrumdevelopment@yahoogroups.com, "changjiang1124@..." <changjiang1124@...> wrote:
      >
      > Greg:
      >
      > Exactly!! I almost get your conclusion by finishing reading the first 2 paragraphs.
      >
      > This is like a grey zone. Both side (PO and dev) would think that's the other's problem. Right now, it seems kinda a solution by gathering PO and dev (maybe just some of them) together to discuss the details, inspired by backlog grooming. The whole team could need some time to get used to this meeting and find the routine.
      >
      > Could I get some advices from you?
      >
      >
      > Best regards
      > Chang, Jiang
      >
      >
      >
      > On Dec 6, 2012, at 3:55 PM, "gregc" <greg@...> wrote:
      >
      > > Jiang,
      > > It's very challenging to diagnose with the pace of information exchange over a group list like this. I was hoping to understand a bit more about what being "responsible" for the product really means as far as the activities the PO owns. But for now, I'll attempt to layout a simple model and tell you what I've heard and you can let me know if this model applies and if my hypothesis on where the problem might lay has merit.
      > >
      > > In one of the simpler views of the world, new product development has 3 phases that need to be passed through. This is true of waterfall or agile: these only differ in the batch size accepted into each phase. The phases are Define --> Design --> Build.
      > >
      > > This step in the middle, Design, is really important. It is where we match the problem or need to a solution. In definition we get a sense of what a customer is trying to accomplish, how they think about success, and their impediments to realizing that. Definition is about needs. It requires research, VOC, ethnography, observation. In the design step, it's about analysis, a feature or set of features begin to emerge to satisfy the need. This takes analysts skills and a deep understanding of workflows, data elements, rules. There's also user experience, understanding the interaction design, visual design, information architecture, and actual content that needs to be presented and which data elements can be manipulated and how, etc. and you need technical architecture skill describe how the design will be implemented. Now it sounds to me like
      > >
      > > 1) your developers are well equipped to build and well equipped to handle the technical architecture.
      > > 2) your PO can define the customer's need (although I'm not certain of this.)
      > > 3) you may have a gap in design where some or all of the major design tasks are not being handled by anyone. Or no one is willing to own them so they are being handled in an adhoc fashion. This might be an issue of individuals not believing it is their responsibility or a missing skill set within the team.
      > >
      > > Let me know if this is on target or not.
      > >
      > > -greg
      > >
      > > --- In scrumdevelopment@yahoogroups.com, "changjiang1124@" <changjiang1124@> wrote:
      > > >
      > > > Greg:
      > > >
      > > > He is responsible for all the product of our company, like a VP or a product director.
      > > >
      > > >
      > > > Best regards
      > > > Chang, Jiang
      > > >
      > > >
      > > >
      > > > On Dec 4, 2012, at 2:15 PM, "gregc" <greg@> wrote:
      > > >
      > > > > Jiang,
      > > > >
      > > > > And what are his current responsibilities?
      > > > >
      > > > > Thanks,
      > > > >
      > > > > -greg
      > > > >
      > > > > --- In scrumdevelopment@yahoogroups.com, "changjiang1124@" <changjiang1124@> wrote:
      > > > > >
      > > > > > Hi Greg:
      > > > > >
      > > > > > He was a developer in Adobe for about 2 years after his graduating. After then, he co-founded this company and being a product manager for about 2 years.
      > > > > >
      > > > > >
      > > > > > Best regards
      > > > > > Chang, Jiang
      > > > > >
      > > > > >
      > > > > >
      > > > > > On Dec 1, 2012, at 1:16 PM, gregc <greg@> wrote:
      > > > > >
      > > > > > >
      > > > > > > Jiang,
      > > > > > >
      > > > > > > Would you share a little more about the PO. What is his/her background and what are his or her full responsibilities at the company?
      > > > > > >
      > > > > > > -greg
      > > > > > >
      > > > > > > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@> wrote:
      > > > > > > >
      > > > > > > > Jiang,
      > > > > > > >
      > > > > > > > On 11/28/12 11:27 PM, changjiang1124@ wrote:
      > > > > > > > >
      > > > > > > > >
      > > > > > > > > Thanks for all your replies.
      > > > > > > > >
      > > > > > > > > Charles:
      > > > > > > > > Our PO does like to interact with Dev, but he would miss some details,
      > > > > > > > > some of which are important, some are not. Dev doesn't foresee these
      > > > > > > > > details until they begin to develop these modules.
      > > > > > > > > I am the SM, also dev manager. We work together. Maybe I heard from dev
      > > > > > > > > too much, but they are just sick of too many things must ask first,
      > > > > > > > > rather than according to documentations, which could make dev progress
      > > > > > > > > more smooth.
      > > > > > > >
      > > > > > > > It's all about the conversations. Take a look at
      > > > > > > > http://www.stickyminds.com/sitewide.asp?Function=WEEKLYCOLUMN&ObjectId=17232&ObjectType=ARTCOL&btntopic=artcol
      > > > > > > > to get some ideas about how these conversations can help.
      > > > > > > >
      > > > > > > > - George
      > > > > > > >
      > > > > > > > --
      > > > > > > > ----------------------------------------------------------
      > > > > > > > * George Dinwiddie * http://blog.gdinwiddie.com
      > > > > > > > Software Development http://www.idiacomputing.com
      > > > > > > > Consultant and Coach http://www.agilemaryland.org
      > > > > > > > ----------------------------------------------------------
      > > > > > > >
      > > > > > >
      > > > > > >
      > > > > >
      > > > >
      > > > >
      > > >
      > >
      > >
      >
    • changjiang1124@gmail.com
      Hi Greg: All your thoughts on my situation are right, include we are a young company. Thanks for your detailed reply, I really got lots of ideas from it. We
      Message 2 of 21 , Dec 7, 2012
      • 0 Attachment
        Hi Greg:

        All your thoughts  on my situation are right, include we are a young company.

        Thanks for your detailed reply, I really got lots of ideas from it. 
        We do need a new PO, coz right now we just have 1 PO that he are managing too many things. Since it's hard to find a suitable candidate, even I could be a half PO, which I don't know whether this is the right thing.

        I still have one thought about this under the current circumstance, I put my QA to write test items just after the kick-off, since they need to think through the details, they can come out really nice questions about the stories to help them get designed at the early stage of building.

        Can this be a solution, or there maybe exist some potential risks? 


        Best regards
        Chang, Jiang



        On Dec 7, 2012, at 2:44 PM, "gregc" <greg@...> wrote:

         

        Jiang,

        Scrum is good at exposing problems. So it's been successful in that regard. And now that the problem is defined, let's look at ways to address it. There is a gap in design and that gap needs to be closed. Part of that can be closed through good collaboration around the story. The story has the three elements: the actual story, the conversation around it, and the joint development of the satisfaction criteria. This should be part of your definition of "ready" before a story can be accepted into a sprint. I'm confident if you do this, things will improve but I am not convinced your problem will be solved.

        A first step would be to lay out the design tasks (which I think for your team means detailed description of functionality, mock-ups, etc.) that aren't being adequately covered today and have the dev team and PO come to some understanding of who is responsible for each of these and how those tasks are going to get done. I think the Team also has to decide if they have the necessary skill set or if a skills gap needs to be filled. Out of this, at least the problem can be recognized, internalized, and the team can develop a plan to address it.

        The conundrum as I see it is the dev team doesn't want to own design. Their passion is for building, not designing. Yet the PO, even if he wants to own design, is unlikely to be able to deliver. Your PO is the VP of Product. And a VP of product has a lot of market facing responsibilities that will prevent him from being able to spend the time necessary to meet the dev team's expectations and needs. I don't think your core problem is with your scrum practices but rather with how you're organized.

        I don't know if this is possible for your company, but my first reaction is that you need a new PO. One who who has more of an analyst skill set. And then I would divide the VP of Product (i.e. product management) and PO responsibilities along the following lines:

        1) Your VP of Product will focus on understanding the market, VOC, competitive analysis, business strategy, product positioning and the strategic roadmap.

        2) The PO will focus on being the expert on the user and everything about the job the user is trying to accomplish (yes, this means the PO will need to be comfortable spending time with users. The knowledge the PO needs to succeed does not come second hand.) The PO will have responsibility, while still collaborating with the team, for feature definition (using stories as the main artifact with supplemental documents like mock-ups, business logic, and task flows as needed), usability, scoping, and the product roadmap.

        Once again, diagnosing via email is tough. Let me know if I've misinterpreted your situation. Also, it sounds like you're a relatively young company. If your company has not yet achieved product-market fit and a scalable business model, I would organize slightly differently.

        Best,

        -greg

        --- In scrumdevelopment@yahoogroups.com, "changjiang1124@..." <changjiang1124@...> wrote:
        >
        > Greg:
        >
        > Exactly!! I almost get your conclusion by finishing reading the first 2 paragraphs.
        >
        > This is like a grey zone. Both side (PO and dev) would think that's the other's problem. Right now, it seems kinda a solution by gathering PO and dev (maybe just some of them) together to discuss the details, inspired by backlog grooming. The whole team could need some time to get used to this meeting and find the routine.
        >
        > Could I get some advices from you?
        >
        >
        > Best regards
        > Chang, Jiang
        >
        >
        >
        > On Dec 6, 2012, at 3:55 PM, "gregc" <greg@...> wrote:
        >
        > > Jiang,
        > > It's very challenging to diagnose with the pace of information exchange over a group list like this. I was hoping to understand a bit more about what being "responsible" for the product really means as far as the activities the PO owns. But for now, I'll attempt to layout a simple model and tell you what I've heard and you can let me know if this model applies and if my hypothesis on where the problem might lay has merit.
        > >
        > > In one of the simpler views of the world, new product development has 3 phases that need to be passed through. This is true of waterfall or agile: these only differ in the batch size accepted into each phase. The phases are Define --> Design --> Build.
        > >
        > > This step in the middle, Design, is really important. It is where we match the problem or need to a solution. In definition we get a sense of what a customer is trying to accomplish, how they think about success, and their impediments to realizing that. Definition is about needs. It requires research, VOC, ethnography, observation. In the design step, it's about analysis, a feature or set of features begin to emerge to satisfy the need. This takes analysts skills and a deep understanding of workflows, data elements, rules. There's also user experience, understanding the interaction design, visual design, information architecture, and actual content that needs to be presented and which data elements can be manipulated and how, etc. and you need technical architecture skill describe how the design will be implemented. Now it sounds to me like
        > >
        > > 1) your developers are well equipped to build and well equipped to handle the technical architecture.
        > > 2) your PO can define the customer's need (although I'm not certain of this.)
        > > 3) you may have a gap in design where some or all of the major design tasks are not being handled by anyone. Or no one is willing to own them so they are being handled in an adhoc fashion. This might be an issue of individuals not believing it is their responsibility or a missing skill set within the team.
        > >
        > > Let me know if this is on target or not.
        > >
        > > -greg
        > >
        > > --- In scrumdevelopment@yahoogroups.com, "changjiang1124@" <changjiang1124@> wrote:
        > > >
        > > > Greg:
        > > >
        > > > He is responsible for all the product of our company, like a VP or a product director.
        > > >
        > > >
        > > > Best regards
        > > > Chang, Jiang
        > > >
        > > >
        > > >
        > > > On Dec 4, 2012, at 2:15 PM, "gregc" <greg@> wrote:
        > > >
        > > > > Jiang,
        > > > >
        > > > > And what are his current responsibilities?
        > > > >
        > > > > Thanks,
        > > > >
        > > > > -greg
        > > > >
        > > > > --- In scrumdevelopment@yahoogroups.com, "changjiang1124@" <changjiang1124@> wrote:
        > > > > >
        > > > > > Hi Greg:
        > > > > >
        > > > > > He was a developer in Adobe for about 2 years after his graduating. After then, he co-founded this company and being a product manager for about 2 years.
        > > > > >
        > > > > >
        > > > > > Best regards
        > > > > > Chang, Jiang
        > > > > >
        > > > > >
        > > > > >
        > > > > > On Dec 1, 2012, at 1:16 PM, gregc <greg@> wrote:
        > > > > >
        > > > > > >
        > > > > > > Jiang,
        > > > > > >
        > > > > > > Would you share a little more about the PO. What is his/her background and what are his or her full responsibilities at the company?
        > > > > > >
        > > > > > > -greg
        > > > > > >
        > > > > > > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@> wrote:
        > > > > > > >
        > > > > > > > Jiang,
        > > > > > > >
        > > > > > > > On 11/28/12 11:27 PM, changjiang1124@ wrote:
        > > > > > > > >
        > > > > > > > >
        > > > > > > > > Thanks for all your replies.
        > > > > > > > >
        > > > > > > > > Charles:
        > > > > > > > > Our PO does like to interact with Dev, but he would miss some details,
        > > > > > > > > some of which are important, some are not. Dev doesn't foresee these
        > > > > > > > > details until they begin to develop these modules.
        > > > > > > > > I am the SM, also dev manager. We work together. Maybe I heard from dev
        > > > > > > > > too much, but they are just sick of too many things must ask first,
        > > > > > > > > rather than according to documentations, which could make dev progress
        > > > > > > > > more smooth.
        > > > > > > >
        > > > > > > > It's all about the conversations. Take a look at
        > > > > > > > http://www.stickyminds.com/sitewide.asp?Function=WEEKLYCOLUMN&ObjectId=17232&ObjectType=ARTCOL&btntopic=artcol
        > > > > > > > to get some ideas about how these conversations can help.
        > > > > > > >
        > > > > > > > - George
        > > > > > > >
        > > > > > > > --
        > > > > > > > ----------------------------------------------------------
        > > > > > > > * George Dinwiddie * http://blog.gdinwiddie.com
        > > > > > > > Software Development http://www.idiacomputing.com
        > > > > > > > Consultant and Coach http://www.agilemaryland.org
        > > > > > > > ----------------------------------------------------------
        > > > > > > >
        > > > > > >
        > > > > > >
        > > > > >
        > > > >
        > > > >
        > > >
        > >
        > >
        >


      • Markus Gaertner
        Hi Jiang, for the testers, I recommend that they come up with the following at least during the backlog refinement or grooming meetings: - criteria for
        Message 3 of 21 , Dec 7, 2012
        • 0 Attachment
          Hi Jiang,

          for the testers, I recommend that they come up with the following at least during the backlog refinement or grooming meetings:
          - criteria for acceptance of that particular story
          - exploratory test sessions they would like to run once the story has been implemented
          - further quality criteria (i.e. non-functional requirements like performance and stability) they think needs to be addressed.

          This can help to prepare them about which tests are going to be automated, and to close the gaps with non-functional tests which require special tools alongside with a human engaged brain where it is necessary like layout problems, usability, and so on.

          Best
          Markus

          On Fri, Dec 7, 2012 at 10:58 AM, changjiang1124@... <changjiang1124@...> wrote:


          Hi Greg:

          All your thoughts  on my situation are right, include we are a young company.

          Thanks for your detailed reply, I really got lots of ideas from it. 
          We do need a new PO, coz right now we just have 1 PO that he are managing too many things. Since it's hard to find a suitable candidate, even I could be a half PO, which I don't know whether this is the right thing.

          I still have one thought about this under the current circumstance, I put my QA to write test items just after the kick-off, since they need to think through the details, they can come out really nice questions about the stories to help them get designed at the early stage of building.

          Can this be a solution, or there maybe exist some potential risks? 


          Best regards
          Chang, Jiang



          On Dec 7, 2012, at 2:44 PM, "gregc" <greg@...> wrote:

           

          Jiang,

          Scrum is good at exposing problems. So it's been successful in that regard. And now that the problem is defined, let's look at ways to address it. There is a gap in design and that gap needs to be closed. Part of that can be closed through good collaboration around the story. The story has the three elements: the actual story, the conversation around it, and the joint development of the satisfaction criteria. This should be part of your definition of "ready" before a story can be accepted into a sprint. I'm confident if you do this, things will improve but I am not convinced your problem will be solved.

          A first step would be to lay out the design tasks (which I think for your team means detailed description of functionality, mock-ups, etc.) that aren't being adequately covered today and have the dev team and PO come to some understanding of who is responsible for each of these and how those tasks are going to get done. I think the Team also has to decide if they have the necessary skill set or if a skills gap needs to be filled. Out of this, at least the problem can be recognized, internalized, and the team can develop a plan to address it.

          The conundrum as I see it is the dev team doesn't want to own design. Their passion is for building, not designing. Yet the PO, even if he wants to own design, is unlikely to be able to deliver. Your PO is the VP of Product. And a VP of product has a lot of market facing responsibilities that will prevent him from being able to spend the time necessary to meet the dev team's expectations and needs. I don't think your core problem is with your scrum practices but rather with how you're organized.

          I don't know if this is possible for your company, but my first reaction is that you need a new PO. One who who has more of an analyst skill set. And then I would divide the VP of Product (i.e. product management) and PO responsibilities along the following lines:

          1) Your VP of Product will focus on understanding the market, VOC, competitive analysis, business strategy, product positioning and the strategic roadmap.

          2) The PO will focus on being the expert on the user and everything about the job the user is trying to accomplish (yes, this means the PO will need to be comfortable spending time with users. The knowledge the PO needs to succeed does not come second hand.) The PO will have responsibility, while still collaborating with the team, for feature definition (using stories as the main artifact with supplemental documents like mock-ups, business logic, and task flows as needed), usability, scoping, and the product roadmap.

          Once again, diagnosing via email is tough. Let me know if I've misinterpreted your situation. Also, it sounds like you're a relatively young company. If your company has not yet achieved product-market fit and a scalable business model, I would organize slightly differently.

          Best,

          -greg

          --- In scrumdevelopment@yahoogroups.com, "changjiang1124@..." <changjiang1124@...> wrote:
          >
          > Greg:
          >
          > Exactly!! I almost get your conclusion by finishing reading the first 2 paragraphs.
          >
          > This is like a grey zone. Both side (PO and dev) would think that's the other's problem. Right now, it seems kinda a solution by gathering PO and dev (maybe just some of them) together to discuss the details, inspired by backlog grooming. The whole team could need some time to get used to this meeting and find the routine.
          >
          > Could I get some advices from you?
          >
          >
          > Best regards
          > Chang, Jiang
          >
          >
          >
          > On Dec 6, 2012, at 3:55 PM, "gregc" <greg@...> wrote:
          >
          > > Jiang,
          > > It's very challenging to diagnose with the pace of information exchange over a group list like this. I was hoping to understand a bit more about what being "responsible" for the product really means as far as the activities the PO owns. But for now, I'll attempt to layout a simple model and tell you what I've heard and you can let me know if this model applies and if my hypothesis on where the problem might lay has merit.
          > >
          > > In one of the simpler views of the world, new product development has 3 phases that need to be passed through. This is true of waterfall or agile: these only differ in the batch size accepted into each phase. The phases are Define --> Design --> Build.
          > >
          > > This step in the middle, Design, is really important. It is where we match the problem or need to a solution. In definition we get a sense of what a customer is trying to accomplish, how they think about success, and their impediments to realizing that. Definition is about needs. It requires research, VOC, ethnography, observation. In the design step, it's about analysis, a feature or set of features begin to emerge to satisfy the need. This takes analysts skills and a deep understanding of workflows, data elements, rules. There's also user experience, understanding the interaction design, visual design, information architecture, and actual content that needs to be presented and which data elements can be manipulated and how, etc. and you need technical architecture skill describe how the design will be implemented. Now it sounds to me like
          > >
          > > 1) your developers are well equipped to build and well equipped to handle the technical architecture.
          > > 2) your PO can define the customer's need (although I'm not certain of this.)
          > > 3) you may have a gap in design where some or all of the major design tasks are not being handled by anyone. Or no one is willing to own them so they are being handled in an adhoc fashion. This might be an issue of individuals not believing it is their responsibility or a missing skill set within the team.
          > >
          > > Let me know if this is on target or not.
          > >
          > > -greg
          > >
          > > --- In scrumdevelopment@yahoogroups.com, "changjiang1124@" <changjiang1124@> wrote:
          > > >
          > > > Greg:
          > > >
          > > > He is responsible for all the product of our company, like a VP or a product director.
          > > >
          > > >
          > > > Best regards
          > > > Chang, Jiang
          > > >
          > > >
          > > >
          > > > On Dec 4, 2012, at 2:15 PM, "gregc" <greg@> wrote:
          > > >
          > > > > Jiang,
          > > > >
          > > > > And what are his current responsibilities?
          > > > >
          > > > > Thanks,
          > > > >
          > > > > -greg
          > > > >
          > > > > --- In scrumdevelopment@yahoogroups.com, "changjiang1124@" <changjiang1124@> wrote:
          > > > > >
          > > > > > Hi Greg:
          > > > > >
          > > > > > He was a developer in Adobe for about 2 years after his graduating. After then, he co-founded this company and being a product manager for about 2 years.
          > > > > >
          > > > > >
          > > > > > Best regards
          > > > > > Chang, Jiang
          > > > > >
          > > > > >
          > > > > >
          > > > > > On Dec 1, 2012, at 1:16 PM, gregc <greg@> wrote:
          > > > > >
          > > > > > >
          > > > > > > Jiang,
          > > > > > >
          > > > > > > Would you share a little more about the PO. What is his/her background and what are his or her full responsibilities at the company?
          > > > > > >
          > > > > > > -greg
          > > > > > >
          > > > > > > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@> wrote:
          > > > > > > >
          > > > > > > > Jiang,
          > > > > > > >
          > > > > > > > On 11/28/12 11:27 PM, changjiang1124@ wrote:
          > > > > > > > >
          > > > > > > > >
          > > > > > > > > Thanks for all your replies.
          > > > > > > > >
          > > > > > > > > Charles:
          > > > > > > > > Our PO does like to interact with Dev, but he would miss some details,
          > > > > > > > > some of which are important, some are not. Dev doesn't foresee these
          > > > > > > > > details until they begin to develop these modules.
          > > > > > > > > I am the SM, also dev manager. We work together. Maybe I heard from dev
          > > > > > > > > too much, but they are just sick of too many things must ask first,
          > > > > > > > > rather than according to documentations, which could make dev progress
          > > > > > > > > more smooth.
          > > > > > > >
          > > > > > > > It's all about the conversations. Take a look at
          > > > > > > > http://www.stickyminds.com/sitewide.asp?Function=WEEKLYCOLUMN&ObjectId=17232&ObjectType=ARTCOL&btntopic=artcol
          > > > > > > > to get some ideas about how these conversations can help.
          > > > > > > >
          > > > > > > > - George
          > > > > > > >
          > > > > > > > --
          > > > > > > > ----------------------------------------------------------
          > > > > > > > * George Dinwiddie * http://blog.gdinwiddie.com
          > > > > > > > Software Development http://www.idiacomputing.com
          > > > > > > > Consultant and Coach http://www.agilemaryland.org
          > > > > > > > ----------------------------------------------------------
          > > > > > > >
          > > > > > >
          > > > > > >
          > > > > >
          > > > >
          > > > >
          > > >
          > >
          > >
          >







          --
          Dipl.-Inform. Markus Gärtner
          Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development
          http://www.shino.de/blog
          http://www.mgaertne.de
          http://www.it-agile.de
          Twitter: @mgaertne

        Your message has been successfully submitted and would be delivered to recipients shortly.