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

Re: Innovation in an Agile World

Expand Messages
  • MarvinToll.com
    Perhaps there is a premise observable in this video? That creativity is often demonstrated within an ordered context and mature tooling... and then, the
    Message 1 of 110 , May 9, 2012
    View Source
    • 0 Attachment
      Perhaps there is a premise observable in this video?

      That creativity is often demonstrated within an ordered context and mature tooling... and then, the addition of time yields a useful outcome.

      --- In leandevelopment@yahoogroups.com, Joakim Ohlrogge <joakim.ohlrogge@...> wrote:
      >
      > Immediately made me think about this movie: http://youtu.be/jgvx9OfZKJw
      >
      >
    • Patrick Steyaert
      Hello Louis-Philippe, Did you also have a look at Alan Ward s video on Michael Kennedy s site: http://bit.ly/LrBJvG. From the video I learn that the purposes
      Message 110 of 110 , Jun 6, 2012
      View Source
      • 0 Attachment
        Hello Louis-Philippe,

        Did you also have a look at Alan Ward's video on Michael Kennedy's site: http://bit.ly/LrBJvG.

        From the video I learn that the purposes of trade-off curves are:
        - Make experience useful
        - Design it right
        - Review designs
        - Teach and Learn
        - Negotiate and explain
        - Think about new concepts

        So, as you point out, there may be different other ways to achieve the above purposes.

        For example. As a software product developer I might be interested in the feature interactions so that I can better design features in the software without unexpected interactions. A model that describes feature interactions will help me design the software better, think about new concepts etc.

        As a software product development company I am interested in a model that explains how my software can be customized for different customer types. Again this helps me design it right, think about new concepts, etc.

        For all of the above purposes the following criteria seem to be important:
        1) it must be explicit (as opposed to tacit) knowledge
        2) it should capture a trade-off; specifically a trade-off around a quality that is valued by the customer versus a design choice
        3) it should be generalized enough so that it captures different situations

        I'm curious what examples other people can come up with that fit the criteria and help to achieve the purposes (design it right, think about new concepts, ...).

        Patrick.



        --- In leandevelopment@yahoogroups.com, "Louis-Philippe Carignan" <lpcarignan@...> wrote:
        >
        > I re-watched Michael Kennedy talk at LSSC 2012 and am still wondering how we can apply the curves to pure software development.
        >
        > As I am reading Steven J. Spear book "The High-Velocity Edge", it says the following on page 30:
        >
        > "... how local discoveries are made useful throughout the organization. Common themes will emerge from an example of disseminating the most effective known methods of "master craftsmen", an example of capturing knowledge and using it over several product design"
        >
        > Mary asks "how do people remember what they have learned about a software system and
        > preserve the knowledge in a permanent and effective manner?"
        >
        > Could code re-use in the form of a public library (or service) be part of the answer? Could a weekly coding dojo be another way to share knowledge? Could a 5 minute webcast about how a valued piece of code works be another way to share knowledge? When a great piece of code emerge from a team, how is it promoted to other teams for future projects? Should the context in which this valued piece of code emerged be also shared? But how do we capture business decision that influence (and structure) the software.
        >
        > I'm just intrigued at finding "our curves" in software development.
        >
        > Louis-Philippe
        >
        > --- In leandevelopment@yahoogroups.com, "Mary Poppendieck" <mary@> wrote:
        > >
        > > Hi Patrick,
        > >
        > >
        > >
        > > The concept that Michael Kennedy talks about is quite relevant to hardware
        > > decisions, but I am not quite sure where they would fit in software -
        > > perhaps one could graph the load a service can handle? Although I agree
        > > that one should know all that can be known about the environment and
        > > preserve this knowledge, I am not sure that curves are the only way or
        > > necessarily the best way to convey this knowledge. I would like to ask -
        > > how do people remember what they have learned about a software system and
        > > preserve the knowledge in a permanent and effective manner?
        > >
        > >
        > >
        > > Mary Poppendieck
        > >
        > > Author of Lean Software Development, Implementing Lean Software Development,
        > > and Leading Lean Software Development
        > >
        > > <http://www.poppendieck.com> www.poppendieck.com
        > >
        > > 01-952-934-7998
        > >
        > >
        > >
        > > From: leandevelopment@yahoogroups.com
        > > [mailto:leandevelopment@yahoogroups.com] On Behalf Of Patrick Steyaert
        > > Sent: Monday, May 14, 2012 2:36 PM
        > > To: leandevelopment@yahoogroups.com
        > > Subject: [leandevelopment] Set-based concurrent eng in software (was: RE:
        > > Innovation in an Agile World)
        > >
        > >
        > >
        > >
        > >
        > > Mary,
        > >
        > > From my understanding of studying Alan Ward's and Micheal Kennedy's work,
        > > the use of Trade-off curves is a crucial element of Set-Base Concurrent
        > > Engineering. Evaluating multiple alternatives produces trade-off curves that
        > > show the limits of feasibility, even for designs that haven't been tested.
        > > The trade-off curve knowledge base allows to design for success. You seem to
        > > be omitting this part of SBCE, is that intentional?
        > >
        > > Patrick.
        > >
        > > --- In leandevelopment@yahoogroups.com
        > > <mailto:leandevelopment%40yahoogroups.com> , "Mary Poppendieck" <mary@>
        > > wrote:
        > > >
        > > > Right Adrian, Set Based Design develops multiple options to production
        > > quality side-by-side. You generally use set-based design for important
        > > decisions that are very expensive to change once made. Benefits include
        > > exploration of multiple design spaces (so better choices), always meet the
        > > schedule (one option will always work, even if "better" options are
        > > delayed), and ability to gather the most knowledge before making the
        > > decision (so more informed decisions).
        > > > Mary P
        > > > Sent via BlackBerry from T-Mobile
        > > >
        > > > -----Original Message-----
        > > > From: Adrian Howard <adrianh@>
        > > > Sender: leandevelopment@yahoogroups.com
        > > <mailto:leandevelopment%40yahoogroups.com>
        > > > Date: Mon, 30 Apr 2012 20:50:49
        > > > To: <leandevelopment@yahoogroups.com
        > > <mailto:leandevelopment%40yahoogroups.com> >
        > > > Reply-To: leandevelopment@yahoogroups.com
        > > <mailto:leandevelopment%40yahoogroups.com>
        > > > Subject: Re: [leandevelopment] Innovation in an Agile World
        > > >
        > > >
        > > > On 30 Apr 2012, at 20:07, RonJeffries wrote:
        > > >
        > > > > I don't know what a system team is. Otherwise, I totally agree. Set
        > > based design, in XP, is called "Spike", and it has been around since last
        > > century. :)
        > > >
        > > > As I understand it set based design and spikes are fairly different.... or
        > > possibly I'm confused...
        > > >
        > > > Spike is what you do when you have a tough decision and you don't know
        > > whether a particular solution will work or not. They're very brief
        > > explorations/experiments from the main path within an iteration, and they're
        > > often built with the expectation that they'll be thrown away - even if the
        > > solution they're exploring turns out to be okay.
        > > >
        > > > Ron - that fair?
        > > >
        > > > Set-based design is when you explore multiple options simultaneously at
        > > production quality. As you progress you may drop options, split them, cherry
        > > pick features from one into another, or decide to take multiple options all
        > > the way through production. The cost of extra development is outweighed by
        > > the ability to push the "last responsible moment" date into the future.
        > > >
        > > > Mary - that fair?
        > > >
        > > > For example:
        > > >
        > > > With set based design, I might simultaneously start developing desktop,
        > > Android, iPad & iPhone versions of FooApp. Three months in I might drop the
        > > desktop version based on the lack of non-mobile sales. Five months in we
        > > merge iPad and iPhone into a single iOS project. And so on.
        > > >
        > > > During the project I might have some spikes to answer short term questions
        > > ("Can we save Bob all the time exporting multiple resolution images for all
        > > the platforms from Photoshop? No freaking clue. Looks vaguely possible - but
        > > not tried it before. Run a spike")
        > > >
        > > > Spikes == short term tactical explorations. Set-based design == long term
        > > strategic options.
        > > >
        > > > That's how I've been using the terms... interested to figure out if I've
        > > been using 'em wrong :-)
        > > >
        > > > Cheers,
        > > >
        > > > Adrian
        > > > --
        > > > http://quietstars.com adrianh@ twitter.com/adrianh
        > > > t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh
        > > >
        > > >
        > > >
        > > >
        > > >
        > > > ------------------------------------
        > > >
        > > > Yahoo! Groups Links
        > > >
        > >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.