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

Re: Expand/Collapse

Expand Messages
  • Chris
    Hi Mike I m not sure if I understand your statement. When you say we , do you mean I ? Collapse/Expand came about because we wanted to shift the discussion
    Message 1 of 220 , Feb 24, 2011
      Hi Mike

      I'm not sure if I understand your statement. When you say "we", do you mean "I"?

      Collapse/Expand came about because we wanted to shift the discussion of value off this group which is about Kanban. It describes the pattern where you expand a single ticket into many tickets and then collapse them back into a single piece of work for processing through subsequent process steps.

      The pattern starts with a BVI Business Value Increment (the new name for an MMF). This is something expressed in terms of value to the business investor. In order to deliver this value, it may be necessary to create a number of tasks (stories?) that need to be delivered and then put together to be tested. The example I originally used was an aeroplane. The customer values transport from London to New York. To do that, the plane needs the features "Take Off", "Fly" and "Land". Without all three features, there is no value to the customer and in fact partial delivery may result in value destruction or risk.

      The key thing with a BVI is that the customer derives no value until all the parts are delivered. It does not mean that all the parts need to be delivered together. In fact, it is often of value to create interim deliverables to reduce delivery risk (from the perspective of the investor) and get early feedback.

      Often during the process, the BVI is split into several BVIs as the team work out that more than one thing of value is being delivered and hence the deliverable can be reduced in size. As such, it is common and a good thing for a BVI to split into a set of tasks that collapse into a BVI for testing, and other BVIs.

      Regards

      Chris





      --- In kanbandev@yahoogroups.com, Mike Burrows <mjb@...> wrote:
      >
      > It occurs to me that we often expand (decompose) big features into a list of
      > smaller ones but don't tend to collapse them back onto the original ticket
      > later.
      >
      > Is this:
      >
      > 1. Common?
      > 2. Good? (I can think of some reasons why it might be)
      > 3. Bad? (likewise)
      > 4. Depends? (on what?)
      >
      >
      > Mike
      > mjb@...
      > http://positiveincline.com
      > http://twitter.com/asplake
      >
    • Karl Scotland
      I m not clear on how something like StackExchange would overlap with this group so its not something I ve pursued. If someone wants to run an experiment
      Message 220 of 220 , Mar 9, 2011
        I'm not clear on how something like StackExchange would overlap with this group so its not something I've pursued.

        If someone wants to run an experiment though, we can find out.

        Karl

        On 9 March 2011 08:18, Kurt Häusler <kurt.haeusler@...> wrote:


        I was about to propose a new one, but couldn't decide what category to put it in, Professional or Technology, and couldn't decide what to call it.

        It might be nice to have a Kanban specific one, so if someone proposes one, I will follow it, and see what happens.


        On Wed, Mar 9, 2011 at 12:23 AM, Jeffrey Cameron <jeffreycameron@...> wrote:
         

        +1 to StackExchange


        It's popular, easy to use and would allow for traffic coming from stackoverflow.com, etc.


        On Tue, Mar 8, 2011 at 4:47 PM, Elizabeth Keogh <liz@...> wrote:
         

        StackExchange run Area 51 for that very purpose:



        On Tue, Mar 8, 2011 at 8:53 PM, Chris Simmons <simmons.chris@...> wrote:
         

        Another idea is a Stack Overflow-type site (http://stackexchange.com/sites). Much more question and answer oriented, but there are plenty of questions and answers here!



        On Mon, Feb 28, 2011 at 2:13 PM, David Anderson <netherby_uk@...> wrote:
         

        The limitedwipsociety.org site is being transitioned to a wiki type platform to be a community contributed hub for the Kanban community. Karl Scotland and Rally Software are in charge of this effort on behalf of the Lean Software & Systems Consortium. If you would like to contribute and help make this happen faster please contact Karl.

        Regards,
        David
        Vice President
        Lean Software & Systems Consortium



        --- In kanbandev@yahoogroups.com, "PAUL" <beckfordp@...> wrote:
        >
        > Hi Chris,
        >
        > >
        > > As far as I know, the C2 wiki is owned by Ward Cunningham or someone else. It is a repository of knowledge related for XP.
        >
        > Thdere is other content on their too. I think there is a car club amongst others. We could simply ask Ward for a Kanban section.
        > >
        > > 1. I do not think it would be appropriate for the Kanban community to use it as their own without permission from the owners.
        >
        > See above. It has several subsections.
        >
        > >
        > > 2. The Kanban community has a number of community sites which could be used. The most obvious being http://www.limitedwipsociety.org/ Karl has mentioned that this is being discussed for this site.
        >
        > Well it is sorely needed and we have been waiting a long time.
        > >
        > > Paul wrote
        > > > What I see is people becoming locked into tribal ghettos, with only a limited appreciation of the wider possibilities.
        > > >
        > >
        > > Funny. I have a different perspective. I see the Kanban Community as one of the few areas of the Agile world where people are discussing new ways of doing things. Pretty much most of the people engaged in the conversation have several years experience of XP and Scrum etc. The fact they chose new words for things should be interesting. Have they seen something new or do they have a different way of expressing something that appeals to a different audience. Your concerns about the language remind me of the "early" discussions about BDD.
        >
        > BDD is different. Dan makes clear references to TDD all the time. Here when anyone mentions XP, Scrum or other software practices there is normally this immediate backlash. Whilst if you use Lean Manufacturing terminology everyone is happy despite how inappropriate it may be (like PDCA or SPC, but I digress :)
        >
        > It seems to me that this group wants to define itself as different. I think the manufacturing inspired language is seen as part of that difference by many.
        >
        >
        > >
        > > Final point. Your e:mails over the weekend remind me of Big Brother in 1984 by George Orwell. Big Brother forcing New Speak on the population. Limiting their language to enforce control. I know that was not your point, but it was the way I felt about the way you are trying get your point across. It starts with one word and before we know it, we lose an entire language.
        >
        > No big brother. I do not have the clout to enforce anything. It was an observation that was all. Language is important in all walks of life and we need to be very careful how we use it. If you know anything about the power of propaganda you'll know what I mean :)
        >
        > Language and thought are intimately linked, and your choice of language can limit your thinking.
        >
        > The struggle we've had as a group communicating over what is really a small point I think proves my case. There is something bigger at play and I think it is holding us back. Being conscious of how we are using language should help I think. (BTW I've been guilty of poor language choices in the past, so I'd be the first to put my hand up :)).
        >
        > Regards,
        >
        > Paul.
        > >
        > > Chris
        > >
        > > --- In kanbandev@yahoogroups.com, "PAUL" <beckfordp@> wrote:
        > > >
        > > >
        > > >
        > > >
        > > > Hi Fedrick,
        > > >
        > > > I totally agree. What's troublesome for me is that it has taken us so long to get here. There is always a difference between what we ideally would like to do and the practical compromises we find ourselves making.
        > > >
        > > > We do need to understand the ideal though. We can then describe alternative patterns with reference to that ideal. A sort of where, when why. A taxonomy or pattern language if you will.
        > > >
        > > > I think Ron's concern, and mine also is that knowledge and understanding of the ideal is being diluted and lost. I've got lots of background to go on, but imaging someone coming to these ideas for the first time.
        > > >
        > > > Based on this discussion they wouldn't have a clue :)
        > > >
        > > > Incidentally, I don't understand why we can't just add to the C2 wiki. It can serve as a common body of knowledge. New ideas and terminology can reference existing terms. That way people can decide for themselves which approach is most appropriate for them, given their specific circumstances.
        > > >
        > > > What I see is people becoming locked into tribal ghettos, with only a limited appreciation of the wider possibilities.
        > > >
        > > > Regards,
        > > >
        > > > Paul.
        > > > --- In kanbandev@yahoogroups.com, Fredrik Lindgren <fredrik@> wrote:
        > > > >
        > > > > Hi Paul,
        > > > >
        > > > > I think an important point here is that the kanban board and the terminology
        > > > > should model the process as it is, rather than modelling the ideal process.
        > > > > I think it is safe to say that the Expand/Collapse pattern is quite common
        > > > > in many development organizations. I do agree with you and Ron that it is
        > > > > better to deliver at the story level if it is feasible, but until you get
        > > > > there, it is still good to be able to visualize how you are currently
        > > > > working.
        > > > >
        > > > > To me the main benefit in the Expand/Collapse pattern is the ability to
        > > > > limit WIP on the BVI level to keep focus while working on delivering slices
        > > > > at the story level. The Collapse part I don't value that much. I'd prefer an
        > > > > Expand/Fulfill model, suggesting that the word Fulfill has a less atomic
        > > > > connotation than Collapse has.
        > > > >
        > > > > Regards,
        > > > >
        > > > > Fredrik
        > > > >
        > > > > On Mon, Feb 28, 2011 at 7:11 AM, PAUL <beckfordp@> wrote:
        > > > >
        > > > > >
        > > > > >
        > > > > > Hi Eb,
        > > > > >
        > > > > > I think you've got it. Ron's way of getting us to understand things can
        > > > > > feel a bit criptic, but if you are paying attemntion hes is virtually always
        > > > > > right.
        > > > > >
        > > > > > Chris's explanation of the history makes it clear to me. Chris wanted to
        > > > > > seperate the unit of release (The MMF, BVI, etc) from the unit of software
        > > > > > delivery (the story). That way the customer and the Analyst could plan
        > > > > > releases independently from the team.
        > > > > >
        > > > > > To deliver a piece of software you first would expand it into stories, then
        > > > > > collapse it back to the unit of release. To me this is very clear and is now
        > > > > > a part of my vocabulary as the definition of Expand/Collapse.
        > > > > >
        > > > > > What Ron is pointing out is that this is not a very Agile way of working. I
        > > > > > agree. As I have mentioned earlier the plan (backlog) for the BVI need not
        > > > > > be fixed, and as Ron has mentioned the BVI's themselves need not be fixed.
        > > > > >
        > > > > > You can release at any time. And releasing sooner and hence more frequently
        > > > > > is a good thing.
        > > > > >
        > > > > > Ultimately there is nothing stopping you releasing after each story, if you
        > > > > > customer is setup to accept such frequent releases, and many XP teams
        > > > > > actually do.
        > > > > >
        > > > > > Regards,
        > > > > >
        > > > > > Paul.
        > > > > >
        > > > > > --- In kanbandev@yahoogroups.com, Eb <amaeze@> wrote:
        > > > > > >
        > > > > > > On 02/27/2011 09:11 PM, Siddharta Govindaraj wrote:
        > > > > > > > On 28-Feb-11 7:24 AM, Eb wrote:
        > > > > > > >> Why would you deliver the stories piecemeal into production if there
        > > > > > is
        > > > > > > >> seemingly no inherent value to them except they are all there? I guess
        > > > > > > >> if the transaction costs are negligible, it doesn't matter. But in
        > > > > > > >> organizations where there is a stringent change management program and
        > > > > > > >> everything needs to be tested by the end user, I could see this
        > > > > > getting
        > > > > > > >> interesting.
        > > > > > > >>
        > > > > > > > Hi Eb,
        > > > > > > >
        > > > > > > > This was the scenario you pointed out higher up in the thread :)
        > > > > > > >
        > > > > > > >> Dennis -
        > > > > > > >>
        > > > > > > >> Not trying to speak for anyone, but I believe the difference of
        > > > > > opinion
        > > > > > > >> lies in the delivery (and not the development). Some would deliver
        > > > > > each
        > > > > > > >> story as its completed (and that's probably the more agile way)
        > > > > > > Aha, but I was actually corrected on that which is why I was trying to
        > > > > > > make the distinction.
        > > > > > > > In another example (Chris Matts?), after all the stories are done, the
        > > > > > > > BVI would go into testing and deployment in one piece. So it's
        > > > > > certainly
        > > > > > > > context dependent.
        > > > > > > >
        > > > > > > > There is also a fair amount of terminology confusion here. To be clear,
        > > > > > > > the terminology I've used is
        > > > > > > >
        > > > > > > > BVI - an increment of business value, a big feature eg: send email
        > > > > > > > functionality
        > > > > > > > Story - a small slice of functionality, eg: compose an email (the
        > > > > > > > editor), send the email over the network, handle protocol errors
        > > > > > > Where is the user story definition coming from?
        > > > > > > http://c2.com/cgi/wiki?UserStory? Are you customers working with you to
        > > > > > > slice things that they can truly test and would use to measure progress?
        > > > > > >
        > > > > > >
        > > > > > > --
        > > > > > > blog: http://eikonne.wordpress.com
        > > > > > > twitter: http://twitter.com/eikonne
        > > > > > >
        > > > > >
        > > > > >
        > > > > >
        > > > >
        > > >
        > >
        >





        --
        Elizabeth Keogh
        liz@...
        http://lizkeogh.com
        http://lunivore.com








        --
        Karl Scotland
        Lean & Agile Coach
        http://www.availagility.co.uk/
      Your message has been successfully submitted and would be delivered to recipients shortly.