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

Re: Innovation in an Agile World

Expand Messages
  • marling633
    Hi Mary, Relegating developers to order takers is exactly what I am desribing. This is basically what the developers are saying, they have no room/time for
    Message 1 of 110 , Apr 30, 2012
      Hi Mary,

      Relegating developers to 'order takers' is exactly what I am desribing. This is basically what the developers are saying, they have no room/time for creative thinking. That is at the root of my question. How do we achieve this balance? The dev team is on pretty strict 2 week sprint schedule, but it seems the 2 weeks has no time built in for anything other than getting the specific requirement developed. Where is the 'alternate' solutioning, or outiside the box thinking achieved?? I agree with you that to use the developers as mere robots, churning out code is a terrible waste, that is at the heart of this issue. I think the 'whole' team should be utilized to produce the 'best' solution. Having said that it does seem to me that Agile breaks large requirement blocks down to such manageable sizes that at it's difficult at the developer level to have any room for creative thinking. It does seem pretty obvious that if any problem is distilled down eventually there is only one (or very few) ways of solving that problem.

      The more I think about it the more it sounds like reinventing the wheel. If I outlined the requirement for a wheel type issue how many innovative solutions would I get back? The big BUT here is hopefully we are talking about solving 'a' wheel problem, not 'the' wheel problem. The wheel we are talking about has not yet been invented and we would like to develop the first one. The problem is we would like to develop the best one possible. The guy who developed the square wheel was probably totally happy until some swine came along with the round version.

      So where do we assign time for innovation without excluding any memebers of the team?

      Cheers,
      John.

      --- In leandevelopment@yahoogroups.com, "Mary Poppendieck" <mary@...> wrote:
      >
      > Seems to me that most disruptive innovation these days has software at its core. The automotive industry expects 90 percent of innovation in vehicles to come from software and electronics. Creative use of smart phones has brought everything from banking to intelligent farm apps to remote corners of the world. A vast number of startups use software as their main ingredient.
      >
      > Seems to me that software systems are the basis for a vast amount of innovation, and if we think of whole systems, instead of just "working software", then the development team can (and should) be co-conspirators in a huge number of innovations. To miss out on this opportunity is to relegate developers to "order takers" rather than creative thinkers. What a waste that would be!
      >
      > Mary Poppendieck
      > Sent via BlackBerry from T-Mobile
      >
      > -----Original Message-----
      > From: "MarvinToll.com" <MarvinToll@...>
      > Sender: leandevelopment@yahoogroups.com
      > Date: Mon, 30 Apr 2012 12:59:47
      > To: <leandevelopment@yahoogroups.com>
      > Reply-To: leandevelopment@yahoogroups.com
      > Subject: [leandevelopment] Re: Innovation in an Agile World
      >
      > hmmm...
      >
      > Perhaps, there is another perspective that could be rendered.
      >
      > That is... the majority of computing systems don't need innovation.
      >
      > Aren't many applications simply the automation of tasks... isn't calling that innovation after over 50 years of IT a bit of a stretch?
      >
      > Would it be like saying we need a new road from St. Louis to Chicago... so let's make sure there is plenty of time for innovation along the way?
      >
      > Perhaps effort expended on innovation should be targetted when/where innovation is truely needed... and avoid re-inventing what has occured over the last five decades?
      >
      > I've started a blog post to capture "Innovation Anti-Patterns"...
      >
      > http://wp.me/P1FU3L-rA
      >
      > _Marvin
      >
      >
      > --- In leandevelopment@yahoogroups.com, "marling633" <johnnie.herbert@> wrote:
      > >
      > > I had a very interesting discussion yesterday about the 'perceived' lack of room/time for innovation for a development team under a two week sprint cycle.
      >
    • 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 12:38 PM
        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.