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

Names of companies that have adopted agile software development in a CMM environ

Expand Messages
  • purtygirl101
    Does anyone know the names of companies that have adopted agile software development in a CMM environment and have been successful. They can be large or small
    Message 1 of 9 , Feb 24, 2005
    • 0 Attachment
      Does anyone know the names of companies that have adopted agile
      software development in a CMM environment and have been successful.
      They can be large or small companies, I am just trying to find real
      examples or proof that agile and cmm can be combined.
    • Ray Rupinski
      Just what is CMM ? Please enlighten us. ... successful. ... real
      Message 2 of 9 , Feb 24, 2005
      • 0 Attachment
        Just what is "CMM"? Please enlighten us.

        --- In agile-usability@yahoogroups.com, "purtygirl101"
        <Purtygirl101@y...> wrote:
        >
        >
        > Does anyone know the names of companies that have adopted agile
        > software development in a CMM environment and have been
        successful.
        > They can be large or small companies, I am just trying to find
        real
        > examples or proof that agile and cmm can be combined.
      • Desilets, Alain
        There was a paper about this in the proceedings of the XPAgile2004 conference. But I forget the name of the company. If I remember correctly, they were able to
        Message 3 of 9 , Feb 24, 2005
        • 0 Attachment
          There was a paper about this in the proceedings of the XPAgile2004
          conference. But I forget the name of the company. If I remember correctly,
          they were able to achieve CMM level 3. Note that it is dubious whether you
          can achieve higher than level 3 without doing a lot of not-coding-related
          work. The XP wisdom (and this is also true for most Agile approaches) says
          that you should not invest too much time into things that do not contribute
          directly to working code.

          Alain Désilets

          -----Original Message-----
          From: purtygirl101 [mailto:Purtygirl101@...]
          Sent: Thursday, February 24, 2005 8:29 AM
          To: agile-usability@yahoogroups.com
          Subject: [agile-usability] Names of companies that have adopted agile
          software development in a CMM environ





          Does anyone know the names of companies that have adopted agile
          software development in a CMM environment and have been successful.
          They can be large or small companies, I am just trying to find real
          examples or proof that agile and cmm can be combined.









          Yahoo! Groups Links
        • Jeff Fedor
          Capability Maturity Model See http://www.sei.cmu.edu/cmm/ ... agile
          Message 4 of 9 , Feb 24, 2005
          • 0 Attachment
            Capability Maturity Model

            See http://www.sei.cmu.edu/cmm/

            > -----Original Message-----
            > From: Ray Rupinski [mailto:ray_rupinski@...]
            > Sent: Thursday, February 24, 2005 10:17 AM
            > To: agile-usability@yahoogroups.com
            > Subject: [agile-usability] Re: Names of companies that have adopted
            agile
            > software development in a CMM environ
            >
            >
            >
            > Just what is "CMM"? Please enlighten us.
            >
            > --- In agile-usability@yahoogroups.com, "purtygirl101"
            > <Purtygirl101@y...> wrote:
            > >
            > >
            > > Does anyone know the names of companies that have adopted agile
            > > software development in a CMM environment and have been
            > successful.
            > > They can be large or small companies, I am just trying to find
            > real
            > > examples or proof that agile and cmm can be combined.
            >
            >
            >
            >
            >
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
          • Larry Constantine
            Alain, Having developers spend time on the other side of the user interface is a good idea. However, two cautionary notes need to be kept in mind. (1)
            Message 5 of 9 , Feb 24, 2005
            • 0 Attachment
              Alain,

              Having developers spend time on the other side of the user interface is a
              good idea. However, two cautionary notes need to be kept in mind.

              (1) Developers' inside-out knowledge of how the user interface was
              constructed and how it functions handicaps them in actually experiencing the
              user experience.

              (2) "Playing around with" is not using.

              More payoff can be obtained if someone independent creates realistic and
              challenging usage scenarios for the developers to carry out with
              representative volume and complexity ("complete the following 28 new patient
              admissions and correct the following 12 billing errors while intermittently
              interrupting each other"). An application that can feel just fine when you
              are freely exploring it without pressure and with no particular goal in mind
              can turn out to be completely unacceptable under realistic and repetitive
              conditions.

              This sort of trial use is less fun than a "celebration" but more useful in
              gaining insight into user needs. Over time, developers who do this will find
              their design and development practices gradually morph. For example, some
              developers tend to see modal dialogs as the solution to every interaction
              problem. Only when they experience them popping up in their faces at every
              turn and having to launch-act-and-close 28 times in a row do they start
              thinking about within-context alternatives.

              --Larry Constantine, IDSA [mailto:lconstantine@...]
                Chief Scientist
                Constantine & Lockwood, Ltd.
                58 Kathleen Circle | Rowley, MA 01969
                tel: +1 978 948 5012 | fax: +1 978 948 5036 | www.foruse.com


              > -----Original Message-----
              > From: Desilets, Alain [mailto:alain.desilets@...]
              > Sent: Thursday, 27 January 2005 11:45 AM
              > To: 'agile-usability@yahoogroups.com'
              > Subject: RE: [agile-usability] Re: Craftmanship doesn't scale... hence
              usability?
              >
              >
              > I reviewed a workshop proposal for XP Agile 2004 (I forget who it was
              from)
              > which was describing a process whereby at the end of each iteration, the
              > whole team "celebrates" by spending half a day playing around with the
              > system and eating their own dog food. That struck me as a really good way
              to
              > put developpers in the shoes of users so that they can take better design
              > decisions. Something like this might just turn developpers into craftmans.
              >
              > Unfortunately, the proposal for the workshop was turned down (I gave it
              > thumbs up myself). I would have liked to attend it.
              >
              > Alain Désilets, MASc
              > Agent de recherches/Research Officer
              > Institut de technologie de l'information du CNRC /
              > NRC Institute for Information Technology
              >
              > alain.desilets@...
              > Tél/Tel (613) 990-2813
              > Facsimile/télécopieur: (613) 952-7151
              >
              > Conseil national de recherches Canada, M50, 1200 chemin Montréal,
              > Ottawa (Ontario) K1A 0R6
              > National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
              > K1A 0R6
              >
              > Gouvernement du Canada | Government of Canada
            • Larry Constantine
              Agustin, Marc, Jeff, I regret that I have not had more time to devote to following these threads and helping to clarify some of the issues regarding
              Message 6 of 9 , Feb 24, 2005
              • 0 Attachment
                Agustin, Marc, Jeff,

                I regret that I have not had more time to devote to following these threads
                and helping to clarify some of the issues regarding usage-centered design
                and essential use cases.

                As experienced designers well know, really good visual and interaction
                design can be enormously complex and involves myriad subtle tradeoffs in
                details of appearance and behavior. The real payoff of the abstract modeling
                approaches employed in usage-centered design is that they enable designers
                to separate one big hairy mess of intricately interwoven issues into several
                simpler and somewhat separate decision-making processes. Ultimately, every
                design has to resolve a number of questions:

                What must the user interface enable users to do? This is addressed by task
                cases (essential use cases).

                How should the user interface be organized? This is worked out through task
                clustering and expressed with a navigation map.

                What information and capabilities in what layout need to be presented to the
                user? This is addressed through abstract prototyping using canonical
                abstract components, which are identified directly from task cases.

                What does the user interface look like and how does it work? This is the
                realm of detail visual and interaction design and is addressed through
                figurative prototyping with paper prototypes or mockups.

                Each model focuses the designer's attention on a particular class of issues
                and decisions and enables the fairly clean resolution of these more or less
                independently of other design decisions. The transition from one model to
                the next is in each case a fairly straightforward mapping or translation
                process. The successive derivations from a robust and fine-grained task
                model make it easier to ensure that the final design closely fits genuine
                user needs.

                As Jeff says, essential use cases do not stand on their own but are part of
                a suite of mental tools and series of decision process leading to a sound
                design.

                --Larry Constantine, IDSA [mailto:lconstantine@...]
                  Chief Scientist | Constantine & Lockwood, Ltd. | www.foruse.com

                > -----Original Message-----
                > From: news [mailto:news@...] On Behalf Of Agustín Villena
                > Sent: Wednesday, 15 December 2004 5:19 AM
                > To: agile-usability@yahoogroups.com
                > Subject: [agile-usability] Re: Task model => User Interface ... Through
                task (esential use)
                > cases?
                >
                >
                > jeff:
                >
                > Alistair wrote in a past message that you have documented some real
                examples
                > about this process
                > Any link?
                >
                > Thanks
                > Agustin
                >
                > "Jeff Patton" <jpatton@...> escribió en el mensaje
                > news:cpoiji+m6q9@......
                >
                >
                > --- In agile-usability@yahoogroups.com, "Agustín
                > Villena"
                > <agustin.villena@g...> wrote:
                > > Hi!
                > > Conantine & Loockwood proposes that tasks must be described
                > as "essetial
                > > use cases". Well... when I try to apply this format of use cases, I
                > was
                > > quickly involved in an endless loop of refining the redaction of
                > this use
                > > cases... Thinking about it, I realized that he problem is that I
                > really
                > > don't have a good understanding about when an esential use case is
                > good
                > > enough to begin the user interface design based on it
                >
                > The essential use-case is a handy variation of a conventional use
                > case. The two column format limits the use case to a discussion
                > between a single user and the system - ideal for considering the
                > user's interaction with the system. The column headings "user
                > intention" and "system responsibility" suggest thinking about what
                > the user intends to do with the software rather than specific UI
                > solutions to the problem. But, moving from the abstract nature of an
                > essential use case to UI design is an act of design. The essential
                > use case indicates what the user intends to do - it's up to you to
                > determine what user interface might best help the user accomplish
                > their goals - and the system accomplish its responsibilities.
                >
                > The EUC is only a small part of the picture though. The EUC
                > describes, abstractly, the interactions. The use case is executed by
                > a user role with a specific goal and operating from a specific
                > context of use. Information about that role helps.
                >
                > The EUC describes interactions for a user task. I've found
                > clustering tasks by affinity [in a task model] helpful for finding
                > interaction contexts. Task performed by like people at similar
                > points in time cluster close together. This usually suggests a place
                > in the UI where several tasks might be performed. Knowing the
                > interaction contexts lets you think about navigation from context to
                > context.
                >
                > Constantine & other's approach using canonical components
                > [http://foruse.com/articles/abstract.htm%5d helps to bridge the gap
                > between a the EUC and a paper prototype. Paper protyping [I like
                > Carolyn Synder's book on the subject] is critical for validating a
                > proposed user interface. Try using the essential use case as a
                > script for validating the UI.
                >
                > If I had a point in all this rambling it would be that the essential
                > use case doesn't stand alone. You need all the models from usage
                > centered design to help, along with lots of other techniques worth
                > borrowing from other UCD approaches. The Cooper people talk
                > about "jumping the spark gap." Basically crossing from the essential
                > use case and all the other models you prepare to an appropriate user
                > interface is a jump - like a spark crossing a spark gap in a spark
                > plug. You need a concise useful set of models expressing your
                > understanding of the user, their goals, context of use and tasks to
                > help close that gap - make the jumping easier.
                >
                > Have you combined the essential use case with some of these other
                > techniques? If you're interested in working through a specific
                > situation, consider posting an essential use case here. I and the
                > group might likely be able to ask you questions to fill in the
                > context needed to suggest appropriate user interface.
                >
                > Thanks for your post,
                >
                > -Jeff
                >
                > > Well, is the "esential use cases" the only way to map tasks to
                > UI
                > >
                > > Any advice?
                > >
                > > Agustin
                >
                >
                >
                >
                >
                >
                >
                > Yahoo! Groups Links
                >
                >
                >
                >
                >
                >
                >
                >
                >
                >
                >
                >
                >
                >
                > Yahoo! Groups Links
                >
                >
                >
                >
                >
              • Larry Constantine
                Josh et al., Ux (user experience) design does seem to be winning the branding race, in part because it is so wonderfully fuzzy and capable of covering almost
                Message 7 of 9 , Feb 24, 2005
                • 0 Attachment
                  Josh et al.,

                  Ux (user experience) design does seem to be winning the branding race, in
                  part because it is so wonderfully fuzzy and capable of covering almost
                  anything and everything--the entire "experience" of the user. Aside from the
                  philosophical and semantic issue of whether anyone can ever design another's
                  experience (and this from someone who wrote a classic article on
                  psychotherapy training titled "Designed Experience"), it is precisely the
                  enormous potential purview of UxD that is worrisome.

                  Ultimately what gives users a good experience is their ability to do what
                  they need to do efficiently and dependably. Supporting effective user
                  performance is 90% of the story, which is why we make that the centerpiece
                  of USAGE-centered design. The problem with so much of user-experience design
                  and user-centered approaches in practice, is that they spend so much time
                  and attention on matters that may be fun and interesting and help make users
                  feel appreciated and attended to while promoting full employment for Ux
                  designers but that have little if anything to do with the really important
                  stuff in visual and interaction design.

                  (Would you believe, for example, a forthcoming book on personas argues that
                  clipart headshots or stock photos are not "real" enough and should not be
                  used to illustrate personas. Instead, each team should go out and do its own
                  photo shoots of real people based on careful research on how best to embody
                  each persona. Somebody, methinks, has too much time on their hands.)

                  We use small, simple, scaled-down abstract models to focus on the bare
                  essentials with the greatest impact because we want to use our limited time
                  for designing a user interface that really works for users, rather than for
                  shooting and editing compelling videotapes, compiling and categorizing great
                  heaps of stick-notes, or concocting believable biographies for fictitious
                  users whose profiles can be turned into large-format color posters to grace
                  the walls of the development facility.

                  Okay, I know I am a minority voice here (and when or where has it been
                  otherwise?), but I have seen too many loftily user-centered projects miss
                  the boat completely because they missed the central point of good design. It
                  is not about users, it is about uses (or usage, if you prefer).

                  --Larry Constantine, IDSA [mailto:lconstantine@...]
                    Chief Scientist | Constantine & Lockwood, Ltd. | www.foruse.com

                  > -----Original Message-----
                  > From: Josh Seiden [mailto:joshseiden@...]
                  > Sent: Tuesday, 01 February 2005 6:10 PM
                  > To: agile-usability@yahoogroups.com
                  > Subject: [agile-usability] Naming the thing (was "user centered design
                  overlaps with
                  > traditional analysis?)
                  >
                  >
                  > Since this has come up a lot recently, I thought I'd
                  > chime in.
                  >
                  > There is a growing movement to call the larger
                  > practice of user-centered-design by the name "User
                  > Experience Design", "Experience Design" or simply,
                  > "UX", and to consider the word "usability" in it's
                  > narrow meaning.
                  >
                  > This naming convention is based on a couple of ideas:
                  >
                  > 1. That as products and services become more complex,
                  > they require people who practice a variety of
                  > disciplines to get the product/service built.
                  >
                  > An e-commerce site might need interaction design,
                  > information architecture, usability evaluation graphic
                  > design, service design, corporate identity design,
                  > etc.
                  >
                  > 2. Some of these people have titles that identify the
                  > single discipline they practice (graphic design) and
                  > other do not. (As noted, "usability people" might
                  > practice a variety of disciplines.)
                  >
                  > 3. That there is value in identifying the common
                  > thread and methods, and value in developing the
                  > various disciplines with greater rigor.
                  >
                  > Thus, we're starting to see some umbrella
                  > organizations emerge to represent the larger practice
                  > of User Experience Design. These organizations include
                  > AIGA-ED and UXnet.net.
                  >
                  > We're also starting to see some new discipline-focused
                  > organizations like AIFIA and IxDG that advocate for
                  > more narrow definitions of their respective
                  > disciplines.
                  >
                  > And of course, as with all naming exercises, this one
                  > had plenty of politics and controversy too. ;-)
                  >
                  > JS
                  >
                  >
                  >
                  > --- Kay Burnett <kayburnett2002@...> wrote:
                  >
                  > > I have
                  > > thought for some time that the title or topic of
                  > > "usability" needs to either be defined narrowly or
                  > > be expanded
                  >
                  >
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >
                  >
                • Jamie Nettles
                  I would paraphrase CMM level 5 as a team that adjusts what they do on a day-to-day basis so that they always do the optimum thing for a given set of
                  Message 8 of 9 , Feb 24, 2005
                  • 0 Attachment
                    I would paraphrase CMM level 5 as a team that adjusts what they do on a day-to-day basis so that they always do the optimum thing for a given set of circumstances, based on intimate knowledge of what is going on and what is needed. To me this means that a well-running agile team is operating at CMM Level 5. So agility is a shortcut to level 5. I suspect however, that most CMM gurus would violently disagree with me. In practice I think that CMM and agility are probably antithetical, but theoretically I see no incompatibility.

                    > -----Original Message-----
                    > From: Desilets, Alain [mailto:alain.desilets@...]
                    > Sent: Thursday, February 24, 2005 9:26 AM
                    > To: 'agile-usability@yahoogroups.com'
                    > Subject: RE: [agile-usability] Re: Names of companies that
                    > have adopted agile software development in a CMM environ
                    >
                    >
                    > CMM stands for Capacity Maturity Model. This is a model
                    > proposed by the Software Engineering Institute at Carnegie
                    > Mellon, which was inspired by a manufacturing model called
                    > MMM (Manufacturing Maturity Model). It's in the line of Total
                    > Quality Management and related things (ex: ISO200x).
                    >
                    > There are 5 levels of CMM. At level 1, you are essentially
                    > using ad-hoc, slash-and-burn programming (no methodology or
                    > process at all). At level 5, you are using a number of
                    > standardized processes to build software, and measuring how
                    > each processes work in different circumstances, so that you
                    > can apply the correct process in the correct circumstances.
                    >
                    > CMM is sort of the antithesis of Agile methods in many
                    > respects. It emphasises processes, documentation and even
                    > meta-processes and meta-documentation (i.e. have
                    > documentation and a process to evaluate how well your S/W
                    > processes are working). In contrast, Agile methods tend to
                    > emphasize working code and people.
                    >
                    > But I would say that the two approaches are compatible up to
                    > CMM level 3.
                    > After that, CMM requires more meta-documentation and
                    > meta-process than would be palatable to most people in the
                    > Agile community.
                    >
                    >
                    > Alain Désilets
                    >
                    > -----Original Message-----
                    > From: Ray Rupinski [mailto:ray_rupinski@...]
                    > Sent: Thursday, February 24, 2005 10:17 AM
                    > To: agile-usability@yahoogroups.com
                    > Subject: [agile-usability] Re: Names of companies that have
                    > adopted agile software development in a CMM environ
                    >
                    >
                    >
                    >
                    > Just what is "CMM"? Please enlighten us.
                    >
                    > --- In agile-usability@yahoogroups.com, "purtygirl101"
                    > <Purtygirl101@y...> wrote:
                    > >
                    > >
                    > > Does anyone know the names of companies that have adopted agile
                    > > software development in a CMM environment and have been
                    > successful.
                    > > They can be large or small companies, I am just trying to find
                    > real
                    > > examples or proof that agile and cmm can be combined.
                    >
                    >
                    >
                    >
                    >
                    >
                    > Yahoo! Groups Links
                    >
                    >
                    >
                    >
                    >
                    >
                    >
                    >
                    >
                    > Yahoo! Groups Links
                    >
                    >
                    >
                    >
                    >
                    >
                    >
                    >
                  • Henry
                    Why CMM? Though the intention of CMM is for process improvement, today it is just used as a marketing tool and promoted by few management consultants, who make
                    Message 9 of 9 , Feb 25, 2005
                    • 0 Attachment

                      Why CMM?

                       

                      Though the intention of CMM is for process improvement,

                      today it is just used as a marketing tool and promoted by few management consultants,

                      who make money in name of CMM auditing. I seen people work on back dated documents,

                      that too on a selected project (mostly in-house) and train the people to answer specific questions

                      without following any process.

                       

                      In contrast, Agile is a value based system, comes out of problems and

                      impracticality of traditional process like CMM.

                       

                      I won’t say that agile is the process for all kind of projects, still we need experiment Agile with larger projects.

                      However the core values and principles will remain same.

                       

                      An agile organization is something which doesn’t waste time

                      and money on unpractical processes.

                       

                      Henry

                      Bangalore

                      INDIA

                      Blog: www.henryjacob.com

                       

                      *** Some of the world's greatest feats were accomplished by people not smart enough to know they were impossible. ***
                      ----- Original Message -----
                      Sent: Thursday, February 24, 2005 6:59 PM
                      Subject: [agile-usability] Names of companies that have adopted agile software development in a CMM environ



                      Does anyone know the names of companies that have adopted agile
                      software development in a CMM environment and have been successful.
                      They can be large or small companies, I am just trying to find real
                      examples or proof that agile and cmm can be combined.







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