RE: [agile-usability] Re: Real data
As you say CMMI-DEV V1.2 and Scrum (say) are orthogonal. One is a maturity
assessment process the other is a pro duct development method.
Agile software development lives in the Engineering Groups of CMMI. For ML
3, this includes Requirements Management (RM), Project Monitoring and
Control (PMC), Supplier Agreement Management (SAM), Integrated Project
Management (IPM), Risk Management (RSKM), and for ML 4, Quantitative Project
Management (QPM). There is no ML 5 Process Areas for Engineering.
The other Process Groups are: Process Management, Project Management, and
So when we compare Agile software development with CMMI Process Areas there
are compared in a matrix (orthogonal).
It seems to me the conversations are fail to recognize this distinction.
> -----Original Message-----
> From: email@example.com [mailto:agile-
> firstname.lastname@example.org] On Behalf Of davenicolette
> Sent: Sunday, January 31, 2010 5:21 PM
> To: email@example.com
> Subject: [agile-usability] Re: Real data
> - In firstname.lastname@example.org, "Larry Constantine"
> <lconstantine@...> wrote:
> Hello Larry,
> I hate to interrupt the entertaining exchange between George and Glen,
> both of whom I like and respect very much, but I'd like to offer a
> response to your questions, if I may.
> (1) "What if CMM level 5 and RUP practices actually worked
> significantly better than agile ones? Would that mean we should switch
> It seems as if the question presupposes people have to make a mutually-
> exclusive choice of one process or another. The phrasing of the
> question also appears to reflect an assumption that "agile" was
> invented out of whole cloth without any reference to other
> methodologies or real-world experience. In fact, the authors of the
> Agile Manifesto included individuals who had extensive experience in IT
> methodologies, RUP in particular, and their knowledge and experience in
> this area informed the results of the Snowbird meeting. There's no
> question of switching horses, because we're not on any particular
> Members of the agile community are familiar with the processes you
> mention, and we apply them as and where appropriate in our work. Some
> agile practitioners have been deeply involved in combining and
> complementing different methodologies and frameworks to try and achieve
> the best possible results for their clients. Jeff Sutherland, one of
> the creators of the popular agile process framework, Scrum, has
> combined Scrum with CMMI in large organizations, with good results.
> Hilel Glazer is another who has combined these two schools of thought
> successfully. David Anderson did some work in using general agile
> methods alongside CMMI before he turned his attention to adapting ideas
> from Lean Manufacturing to problems of software development and
> organizational improvement.
> The needs and the current reality in any given organization are
> unlikely to be identical to those of any other organization. There is
> no one-size-fits all version of "agile" that we try to impose on every
> situation. Even when we determine that agile is appropriate for a given
> client, we have to adapt agile methods to that client. It is also quite
> normal to incorporate elements of other processes and other schools of
> thought when crafting a process that works well in a given situation.
> There is no inherent conflict between any of these processes or
> approaches. There is no "contest" to be won or lost on the basis of
> published studies.
> I think we also have to keep in mind the particulars of each situation.
> A process that helps a team of 3 develop a quick-and-dirty web site is
> unlikely to be very useful in managing 200 subcontractors in a program
> to develop a new military aircraft. Conversely, a process appropriate
> to the latter situation would be needlessly formal for a team of three
> people who are building something with a very low cost of failure. A
> process that helps teams create business application software in an
> environment where the stakeholders aren't certain what they need, but
> just have a general idea for a business initiative, would probably
> include frequent and short feedback loops to enable everyone to try out
> interim results; that sort of process would be cumbersome in an
> environment where requirements are well-known and stable. Conversely, a
> process designed to build from well-known, stable requirements would be
> useless in the former case; it would cause very long lead times.
> So, what we need to do - and what we already do in the agile community
> - is to choose appropriate processes and adapt them to each situation.
> We don't have a cookbook.
> Here is a different angle on the same question. When you say that one
> process works "better" than another, I suspect there is an underlying
> misunderstanding. No process "works." A process is only a tool; a means
> to an end. People work; processes do not. Therefore, it is a non
> sequitur to say "Process X works better than Process Y." It is
> meaningless to say, for example, "CMM works better than agile," because
> neither CMM nor agile works at all.
> If a process is a tool, then what are the characteristics of a good
> tool? I would say there are two: (1) The tool is appropriate to the job
> at hand; and (2) the people using the tool use it properly.
> I have a very nice hammer in my toolbox, along with several other
> tools. The hammer does absolutely no work. It has no knowledge, skills,
> initiative, or ambition. However, it is available to help me do work,
> when I determine that it is the appropriate tool for a job. From that
> point forward, it's up to me to use the hammer properly so that the end
> result of my work will be satisfactory. If the end result is not
> satisfactory, I cannot blame the hammer. If I do a bad job with the
> hammer, I will not solve anything by buying a different one.
> I have an assortment of tools in my professional toolbox, as well. Some
> of them are conventionally associated with "agile." Some of them are
> not. The ability to judge when each tool is appropriate and then to use
> it properly are my professional skills.
> (2) "Or would it mean we should revise agile to incorporate the best
> parts of other practice traditions? (And maybe shed some baggage at the
> same time?)"
> This is already a fundamental aspect of the agile approach to work. A
> published study would not somehow trigger this behavior. Continuous
> improvement is a fundamental value of agile thinking, just as it is for
> Six Sigma, Lean Manufacturing, and CMM. Personally, I interpret that to
> mean that the ultimate goal of the agile community is to out-grow the
> need for the word, "agile;" to out-grow the need for a special buzzword
> to describe a certain way of thinking about problems, because that way
> of thinking has become ingrained and natural.
> I've noticed that in recent years most companies I visit are in a very
> different "place" than most companies were ten, fifteen, or twenty
> years ago. The methods we now refer to as "first-generation agile" were
> very effective at addressing organizational problems that were common
> ten years ago. Today, we often find a company is in much better shape
> than that, and their needs are different. Many companies are still
> operating in a 1980s style, too. We need to choose the appropriate
> tools from our toolbox for each situation, and we also need to keep our
> tools sharp and clean, and add useful new ones as we discover them.
> Agile is continuously being revised to incorporate newly-discovered
> useful practices and to improve the existing practices. On the
> technical side, consider the ways in which test-driven development has
> evolved in the past ten years. It is a far more mature practice than it
> was when the word "agile" was first coined. We now take a test-first
> approach to requirements, resulting in executable requirements
> developed collaboratively with non-technical stakeholders. At the unit
> level, the behavior-driven approach has superceded the original
> implementation-focused approach. I don't mean to suggest everyone does
> these things, but they are leading-edge practices.
> On the Process side, consider the changes in agile methods in the past
> ten years. RUP called for iterations of no particular length, but
> typical implementations set iteration length at about 3 to 4 months;
> sometimes longer. Scrum initially defined a 30-day iteration length, on
> the assumption that it would fit nicely with the typical monthly
> business cycle. As these methods were employed in more and more
> situations, we learned that shorter iterations tend to produce better
> outcomes (in cases when an iterative approach was appropriate to begin
> with). Five years ago, the canonical agile iteration length was 2
> weeks. Today, a one-week iteration is quite common. At the one-week
> iteration length we begin to find the traditional agile ceremonies are
> taking up too much time and not yielding the value they were originally
> intended to provide (for the best of reasons - the original problems
> that called for those ceremonies have been solved), and we move toward
> an iterationless process based on continuous flow rather than on time-
> boxing. I'm confident that as time goes on, smart people will continue
> to make improvements in agile practices. There is no end to
> improvement, and there shouldn't be.
> We have a wide range of approaches at our disposal, and we can apply
> them selectively depending on the needs of each organization and each
> team within an organization. I see it as a continuum of improvement.
> When we incorporate new approaches, we don't retire old ones; we don't
> "switch horses." Each agile practice is designed to solve specific
> problems. Each organization is different, with different problems and
> different degrees of readiness for change. So, as we have revised agile
> over the years, we have retained earlier flavors because they are still
> useful in selected situations.
> Similarly, we routinely combine selected agile practices and ideas with
> elements of CMM, RUP, Lean, Six Sigma, and other schools of thought.
> This is already part and parcel of agile practice.
> (3) "Or doe the agile community have the TRUE answers, regardless of
> the facts?"
> This doesn't sound like a sincere question. Instead, it implies you
> hold some negative assumptions about a large number of people you don't
> know, and whose work practices you don't understand. Rather than asking
> others whether they hold beliefs that contradict facts, I suggest you
> ask your own bathroom mirror.
> I see that you follow your name with an aphabet soup of credentials.
> Based on the substance of your questions, and particularly this final
> question, I'm not impressed.
> Yahoo! Groups Links
- Hi, Jon,
Jon Kern wrote:
> ok, maybe it is silly to debate the term...I've never found creating software to be a "one and only time" no matter
> George it's a free country, use method anytime you please :-)
> I personally will only use "method" when I want to describe some way
> that I achieve something over and over. Often in an abstract sense,
> often in a step-wise way. Often because the "something" is a desirous
> end goal, and one that I (or someone else) wants more than one time.
> I would not describe the /ad hoc/ "how" of the one and only time I will
> ever do something as a "method" if it is not.
how small the program. There's a lot of similarity between writing one
line of code and writing the next.
And I've observed, that people generally continue to do something
somewhat in the fashion they've done it before. Thoughtful people will
consider the result their achieving, and modify their actions to try to
improve some aspect.
I've never seen anyone continue to approach the work as if they'd never
done anything like it before, choosing some completely different way of
working. And I've never seen anyone carefully follow the recipe in a
process manual. At best, a process manual gives the worker some ideas.
It's the process people actually /do/ that has an effect. If you and
Scott and Glen want to reserve the word "method" for officially blessed
procedures, go right ahead. It won't change a thing.
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org