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

Re: [scrumdevelopment] Re: To split or not to split

Expand Messages
  • Cass Dalton
    I don t think splitting stories along personnel lines is any better than splitting stories along architecture lines. Each story has intrinsic value lines
    Message 1 of 59 , Sep 19, 2012
    View Source
    • 0 Attachment
      I don't think splitting stories along personnel lines is any better than splitting stories along architecture lines.  Each story has intrinsic value lines along which it wants to be split.  Iteration planning and backlog refinement need to seek out those lines.  But those intrinsic lines have nothing to do with the people who are working the stories.

      You're not going to get advice that you consider useful until you realize that your underlying process is anti-agile.  You have several levels of batch processing in a waterfall style process.  The reason that the advice doesn't seem to make sense is that for you to really embrace agile, you will have to completely remove the mass production style idea of Customer->BA->programmer->tester.

      >If half the members cannot write code and are trained as BAs in the domain, I don't see how the last bullet point can be true
      Can the BA's help test the code?  You don't have to be a programmer to test code.  In fact, having the BAs actually have to test the code that was implemented from their requirements will make them better BAs.  They will have a better holistic understanding of what the programmers can achieve and how the programmers can misinterpret ambiguous requirements.  If the BAs and programmers do not have tight collaboration, you are ignoring principles 4 and 6 and the first value of the agile manifesto:
       - Individuals and interactions over processes and tools
       - Business people and developers must work together daily throughout the project.
       - The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
      Requirements analysis and other functions normally performed by BAs are built into Scrum.  Ron keeps bringing up the backlog refinement because backlog refinement/grooming IS business analysis.  If you separate the groups, then you are explicitly circumventing parts of Scrum that give you huge payoffs.

      It's not that your process is wrong, it's that your process is wrong for Scrum.  I suggest you either give up on Scrum, or take a deep and honest look at your entire process.  But I would suggest doing the latter after reading a book like "Lean Software Development: An Agile Toolkit" or "Leading Lean Software Development: Results Are not the Point" by Tom and Mary Poppendieck.  I'm sure others people have their own suggestions for books on the organizational and cultural change that is required to succeed with agile.

      On Wed, Sep 19, 2012 at 7:52 AM, RonJeffries <ronjeffries@...> wrote:
       

      Michael,


      On Sep 19, 2012, at 7:44 AM, Michael Wollin <yahoo@...> wrote:

      If half the members cannot write code and are trained as BAs in the domain, I don't see how the last bullet point can be true. Anyway, the driver is the stories have external dependencies that always contain a wait state. Pipelining makes sense from a pure process point of view. So even if the team remains intact, shouldn't they split the stories into two parts? Alas, the specification by itself would not have business value. Hence the conundrum. 

      The solution really is in the backlog refinement practice. Really.

      Ron Jeffries
      I have two cats, and a big house full of cat stuff. 
      The cats fight and divide up the house, messing up their own lives. 
      Nice work cats. 
      Meow.


    • Kevin Callahan
      Cass, At this point, I believe it comes down to a single test: individuals and interactions over processes and tools. Should be deeply familiar :) If the
      Message 59 of 59 , Oct 4, 2012
      View Source
      • 0 Attachment
        Cass,

        At this point, I believe it comes down to a single test: individuals and interactions over processes and tools. Should be deeply familiar :)

        If the people in the system are unwilling, or unable, to improve what they bring to the table and how they work together, sometimes in radically different ways, productivity will suffer. It's not easy to shift, especially if there's not support at the exec level for such cultural transformation. Simply adopting scrum, or any other agile process without being capable of addressing the dysfunction surfaced is a zero-sum game. And if that sounds hard, well, it is :) And it can take a long time with slow incremental progress...

        -k

        On Oct 4, 2012, at 10:33 AM, Charles Bradley - Scrum Coach CSP CSM PSM I wrote:

         

        Cass,

        > Do you not see requirements generated by BAs as commitments?  
        No, I do not.  Until the entire Scrum team has had a conversation with the PO, there is no lockdown of requirements.

        > If everyone in the organization claims to be in favor of agile, but refuses to change the traditional mindsets that make agile difficult, is that an anti-agile organization?
        Yes

        > The fact that no one was "forcing" the org to stay waterfall doesn't mean that the organization itself was not anti-agile
        True, and if there was evidence given by the OP to support that the org was anti-agile, I would agree with you.


        > Maybe I'm jaded in my attempts to move my current organization to be more agile, but the fact that the org is trying to be agile but doesn't see the queues for what they are tells me that they will have a hard time seeing them when they are in the thick of things.  You have to want to look for root causes.  You have to be open and honest AS AN ORGANIZATION for that type of visibility to 1) be noticed and 2) be changed.

        In this particular case, I didn't get a sense that the org needed to see the queues directly.  If the team saw the queues and took some empirical data, they could help the organization plan for this in their scheduling.  It may very well be that the queue is not something that the OP's org has much control over.  OTOH, the opposite may be true.  First, measure.  Then, inspect and adapt.  It may be as simple as two director level people at the company having a 2 minute conversation in order to reduce the queue.  OTOH, the opposite may be true.  However, until you have empirical data(transparency) to present, the inspect and adapt can *never* occur.  At least if you have the data you can try your hand at the "art of the possible."

        You may be completely correct about the OP's org being anti-Agile.  However, I just didn't see much evidence of that in the OP's posts, so rather than assuming they are anti-Agile, I'm going on what context the OP did provide instead.

        -------
        Charles Bradley
        http://www.ScrumCrazy.com




        From: Cass Dalton <cassdalton73@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Monday, September 24, 2012 2:17 PM
        Subject: Re: [scrumdevelopment] Is it, or is it not, Agile/Scrum? was: To split or not to split



        >OTOH, the OP proposed splitting the teams(1BA team, 1 Scrum team), and while I don't think that's very Agile/Scrum, he was not forced into doing so.  As such, the organization was not Anti-Agile, IMO.

        I guess it comes down to what you think an anti-agile organization is.  If everyone in the organization claims to be in favor of agile, but refuses to change the traditional mindsets that make agile difficult, is that an anti-agile organization?  The fact that no one was "forcing" the org to stay waterfall doesn't mean that the organization itself was not anti-agile.  In my view, the culture and process that hinders success in agile makes an organization anti-agile.

        >> The ones making commitments are not implementing.

        >I saw no evidence of this in the OP's story.  I saw no evidence of commitments at all.  How did you draw this conclusion?

        Do you not see requirements generated by BAs as commitments?  

        >Very true, but it sounded like to me that the likelihood of this changing was near zero, because they are working with an organization over which they have very little to no control.  Instead of scrapping Scrum for this reason, I'd recommend they focus on the "art of the possible," and let Scrum shine some transparency on the queuing problem.   

        I think the only difference between your suggestion and mine is that I suggest that they look at their process prior to trying to implement scrum and you suggest that they wait for things to fail and hope that they can notice that the failures are coming from their organization, and not from Scrum itself, which I don't see as very likely.  Management is much more likely to blame the new fangled process over the organizational culture that has been "working" for them previously.

        > Very true, but it sounded like to me that the likelihood of this changing was near zero, because they are working with an organization over which they have very little to no control.  Instead of scrapping Scrum for this reason, I'd recommend they focus on the "art of the possible," and let Scrum shine some transparency on the queuing problem.  (Or maybe it already has.)  As you'll recall, in my advice, I also mentioned a Kanban board as a way to track stories that were being groomed, as well as the major bottleneck of waiting on the other org. 

        Maybe I'm jaded in my attempts to move my current organization to be more agile, but the fact that the org is trying to be agile but doesn't see the queues for what they are tells me that they will have a hard time seeing them when they are in the thick of things.  You have to want to look for root causes.  You have to be open and honest AS AN ORGANIZATION for that type of visibility to 1) be noticed and 2) be changed.

        On Mon, Sep 24, 2012 at 12:04 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
         
        (Side discussion from previous thread)

        > So you believe that BAs doing requirements analysis and then handing the requirements to programers to develop is agile?
        I think, in some teams where the requirements and business logic are very complex, BA's will work on the Scrum team.  Some times they will share/support the PO role, sometimes they will be the PO,  and some times they will act as a Dev Team member, assisting other Scrum team members in whatever way they can (testing, as you pointed out, organizing UAT, etc).  Some of these may or not be optimal, but they are still Agile/Scrum so long as they are on the same team.  OTOH, the OP proposed splitting the teams(1BA team, 1 Scrum team), and while I don't think that's very Agile/Scrum, he was not forced into doing so.  As such, the organization was not Anti-Agile, IMO.

        > The implementers are not involved in the analysis and customer interaction.
        There is no requirement for implementers(programmers, testers, etc) to interact with customers in Agile(other than the delivery of software).  It's a good practice when done well, but it is not a requirement.  It *is* a requirement for developers to interact with "business people" (Agile), and it is a requirement for the developers to interact with the PO(Scrum), who is, or represents, the business people.  You may be right on the the "implementers are not involved in the analysis" bit, but that problem will become(or already is) transparent and is pretty easily solved.

        > The ones making commitments are not implementing.
        I saw no evidence of this in the OP's story.  I saw no evidence of commitments at all.  How did you draw this conclusion?
         
        > But keeping handoffs is setting up queues.
        Very true, but it sounded like to me that the likelihood of this changing was near zero, because they are working with an organization over which they have very little to no control.  Instead of scrapping Scrum for this reason, I'd recommend they focus on the "art of the possible," and let Scrum shine some transparency on the queuing problem.  (Or maybe it already has.)  As you'll recall, in my advice, I also mentioned a Kanban board as a way to track stories that were being groomed, as well as the major bottleneck of waiting on the other org.

        -------
        Charles Bradley
        http://www.ScrumCrazy.com




        From: Cass Dalton <cassdalton73@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Wednesday, September 19, 2012 4:22 PM
        Subject: Re: [scrumdevelopment] Re: To split or not to split



        So you believe that BAs doing requirements analysis and then handing the requirements to programers to develop is agile?  Maybe I'm misunderstanding the situation, but that seems like it goes against several agile principals.  The implementers are not involved in the analysis and customer interaction.  The ones making commitments are not implementing.  Sure you can impose one piece flow on that, and you can drop sprints and scrums on top of that, and you will even get better coordination.  But as ling as you keep those organizational divides, you are holding on to the separation of responsibility.  You are holding on to the handoff mechanism.  The best case is to make teams cross functional in a way that puts BAs in teams with developers and they work to a common small deliverable.  But keeping handoffs is setting up queues.  Every queue is a chance to clog up your flow.
        On Sep 19, 2012 6:08 PM, "Charles Bradley - Scrum Coach CSP CSM PSM I" <chuck-lists2@...> wrote:
         
        > It's not that your process is wrong, it's that your process is wrong for Scrum.

        I completely disagree with this.  I don't see anything about Michael's situation that makes it unsuitable to Scrum.

        I'm sure some Lean/Kanban concepts could help, but Michael's team is not a snowflake(at least not based on what he has said so far).  They are a software development team -- and IMO, that means they are always suitable for Scrum. 

        I have heard a lot of stories of people thinking "Scrum is not a good fit for us", when in fact, Scrum exposed an inconvenient truth about their team or their org that they decided not to address.  As our fellow list member Ron likes to say... "We Tried Baseball and It Didn’t Work

        Baseball wasn't the problem.
         
        -------
        Charles Bradley
        http://www.ScrumCrazy.com




        From: Cass Dalton <cassdalton73@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Wednesday, September 19, 2012 6:17 AM
        Subject: Re: [scrumdevelopment] Re: To split or not to split



        I don't think splitting stories along personnel lines is any better than splitting stories along architecture lines.  Each story has intrinsic value lines along which it wants to be split.  Iteration planning and backlog refinement need to seek out those lines.  But those intrinsic lines have nothing to do with the people who are working the stories.

        You're not going to get advice that you consider useful until you realize that your underlying process is anti-agile.  You have several levels of batch processing in a waterfall style process.  The reason that the advice doesn't seem to make sense is that for you to really embrace agile, you will have to completely remove the mass production style idea of Customer->BA->programmer->tester.

        >If half the members cannot write code and are trained as BAs in the domain, I don't see how the last bullet point can be true
        Can the BA's help test the code?  You don't have to be a programmer to test code.  In fact, having the BAs actually have to test the code that was implemented from their requirements will make them better BAs.  They will have a better holistic understanding of what the programmers can achieve and how the programmers can misinterpret ambiguous requirements.  If the BAs and programmers do not have tight collaboration, you are ignoring principles 4 and 6 and the first value of the agile manifesto:
         - Individuals and interactions over processes and tools
         - Business people and developers must work together daily throughout the project.
         - The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
        Requirements analysis and other functions normally performed by BAs are built into Scrum.  Ron keeps bringing up the backlog refinement because backlog refinement/grooming IS business analysis.  If you separate the groups, then you are explicitly circumventing parts of Scrum that give you huge payoffs.

        It's not that your process is wrong, it's that your process is wrong for Scrum.  I suggest you either give up on Scrum, or take a deep and honest look at your entire process.  But I would suggest doing the latter after reading a book like "Lean Software Development: An Agile Toolkit" or "Leading Lean Software Development: Results Are not the Point" by Tom and Mary Poppendieck.  I'm sure others people have their own suggestions for books on the organizational and cultural change that is required to succeed with agile.

        On Wed, Sep 19, 2012 at 7:52 AM, RonJeffries <ronjeffries@...> wrote:
         
        Michael,

        On Sep 19, 2012, at 7:44 AM, Michael Wollin <yahoo@...> wrote:

        If half the members cannot write code and are trained as BAs in the domain, I don't see how the last bullet point can be true. Anyway, the driver is the stories have external dependencies that always contain a wait state. Pipelining makes sense from a pure process point of view. So even if the team remains intact, shouldn't they split the stories into two parts? Alas, the specification by itself would not have business value. Hence the conundrum. 

        The solution really is in the backlog refinement practice. Really.

        Ron Jeffries
        I have two cats, and a big house full of cat stuff. 
        The cats fight and divide up the house, messing up their own lives. 
        Nice work cats. 
        Meow.

















        Kevin Callahan, CSP
        Scrum Master
        mobile: 207-691-2997
        AIM: kevmocal


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