A colleague of mine had a question for me about Distributed Versions Control Systems (or DVCS). There are a growing number of such systems these days: Mercurial, Bazaar, git, svk, BitKeeper, Gnu Arch, darcs, Monotone, Codeville, Arx, just to name a few. I referred them to a good essay by David Wheeler that talks about the fundamental differences between distributed vs centralized VCS (among other things).
I also Googled on the topic and came across some interesting links:
Anyone else have any links they recommend on the topic? (please, no spam/marketing)
Peter Eeles and I must be subconsciously on the same page. Because at the same time I was blogging about Software Architecture Views and Perspectives and Software Architecture Quality Attributes and their direct applicability to SCM/ALM solution architecture (and software process in general), Peter was working on an article for IBM developerworks entitled The Rise of the Development Environment Architect:[Development] environments present challenges; and, interestingly, these challenges are similar to those of the systems they support. For example, development environments have to deliver against the required functionality and properties (such as performance and usability), often have to coexist with legacy systems (such as, in the case of a development environment, existing methods and tools), and have to acknowledge other constraints (such as the distributed nature of development teams, and existing skills and infrastructure).
All in all, creating a well-oiled development environment that accelerates, rather than hinders, project performance is a science unto itself. This is why IBM® Rational® has spent many years specifically developing a services capability that understands the challenges faced by organizations that 1) want to improve developer productivity, and 2) regard their development organization as a strategic differentiator, rather than simply a cost center.
Our experience has led the Rational team to define a role within the software development lifecycle called the "development environment architect." In October 2007, one hundred of Rational's most experienced development environment architects from across the globe gathered together in the first conference dedicated to this role to share their experiences. This article is a result of that conference and the discussions that took place.
As you read the concepts presented here, you may well question whether the development environment architect should be a role itself, or whether the individual or team who normally functions in the software or systems architect role should simply add consideration of the development environment to their list of architectural concerns. I believe that both propositions are valid. Furthermore, whenever the role of the "architect" is discussed, it is always qualified with the domain under consideration; thus we speak of a "building architect," "software architect," "systems architect," "enterprise architect," etc. The development environment is simply one of these domains, and one that is not traditionally a concern for the "software architect" role. I therefore believe that the "development environment architect" role is one that hasn't been emphasized before -- hence this article.
This article has several audiences and objectives. It is relevant to organizations undertaking an improvement to their development environment and who need to understand the value of a development environment architect to help guide their initiative. It is also relevant to those who are responsible for the technical content of the development environment -- i.e., development environment architects -- because this article introduces this responsibility as a role not previously defined. Finally, this article may supplement material contained within a development environment, in helping communicate its content, the role of its architect, and the benefits of having such a role in place.
Read the full article here. I may blog later about the similarities and differences between the sort of architecture that Eeles describes versus my 4+2 Views Model of SCM/ALM Solution Architecture
I just received an advance copy of Programming Groovy from the Pragmatic Programmer's Bookshelf. This complements their work that came out last month on Groovy Recipes.
From the Programming Groovy book webpage:Groovy brings you the best of both worlds: a flexible, highly productive, agile, dynamic language that runs on the rich framework of the Java Platform. Groovy preserves the Java semantics and extends the JDK to give you true dynamic language capabilities?programming in Groovy feels like you’re using an augmented Java. Programming Groovy will help you learn and take advantage of the latest version of this rich dynamic language, so you can be a more productive Java Platform developer.
From the Groovy Recipes book webpage:If you’re a busy Java professional who needs quick solutions to everyday problems, then Groovy Recipes is for you. The Groovy language and Grails web framework give you seamless integration with your legacy Java code while adding the flexibility and dynamism of a scripting language and giving you modern, agile, time-saving techniques. Groovy allows you to write code the way you always thought you should—you’ll never look at Java the same way again.
For those who like Ruby and Rails and the ability to access other Java frameworks and APIs, but also really want their Java-like syntax (and hence more than just JRuby), these are the books to read. Groovy even has its own answer to Rails called "Grails"
See also:
My review of Outside-In Software Development is in this month's edition of The Agile Journal. Kessler and Sweitzer's Outside-in Software Development should resonate deeply with all those who genuinely value the principle of customer collaboration in the Agile Manifesto, and with anyone who has played the role of Product Manager for a software project. This 2008 Jolt award Finalist is not a book about eliciting or prioritizing requirements (or "user stories") for an Agile project. This book goes beyond mere user-stories and their ranking or velocity to focus on uncovering the underlying needs and goals of your stakeholders and understanding what truly adds value for the customer and the business.
... I think Outside-in Software Development is a profoundly important book for anyone in the Agile or Lean "camps" because it addresses and embraces the often neglected pieces of the customer-relationship puzzle that emerge from the stakeholders' perspective, often after the software is released. It shows us how many of those same Lean and Agile values of collaboration, responsiveness, waste-elimination, and respect for people can be successfully applied to the users' experience with our software, and to the stakeholders' experience with ourselves in the service of realizing the very business value we strive to deliver.
Read the full review.
Extending the analogy of software architecture views and quality attributes for software process architecture, I'd like to spend some time discussing how software product lines relate to software process architecture and "common processes" across an enterprise.
Many organizations strive for standard common processes, often as part of a CMM/CMMI-based process improvement. All too often I have seen the mantra of "common process" misused and abused to make the practitioners serve the process instead of the other way around.Processes don't create great software. People and Teams do!
And while the process needs to meet the needs of the business and the needs of the customer, it has to first and foremost serve the needs of the practitioners so that they in turn may better serve the needs of the business to deliver operational business value.
Many in management seem to have the mis-impression that "common process" means "no tailoring" and everyone does everything the same way across products and projects throughout the organization. Process variation across products and projects is regarded as something to eschewed and stamped out, beating the offenders into compliance with top-down dictates and mandates and sanctions. If everyone does everything the same way then the people are more or less "plug-and-play replaceable" and can quickly and easily be reallocated to another project or product with zero learning-curve and associated start-up costs.
This is a dangerous myth that causes irreparable harm to process improvement and common/standard process efforts. Anything that focuses on individuals and interactions as subservient to common processes and standard tools is doomed to fail, and those organizations often end-up with the processes they deserve (along with many disgruntled, frustrated workers).
The purpose of such common processes and tools is not to be a rigid restrictive straightjacket for replaceable people. The intended purpose is to recognize that such people are irreplaceable and to provide a flexible knowledge framework to guide and enable them as the help each other collaborate to learn, grow, and lead in the discovery, practical application and effective execution of practices and improvements that are the best fit for a particular product, product, community and business-environment.
The intended purpose common software processes is quite simply that of process and knowledge reuse! And as such it shares many of the same fundamental problems and solutions as that of software reuse. Indeed it could even be argued that software process reuse is but a special case of software reuse. And current prevailing industry wisdom on the subject suggests that software product-lines show the greatest promise of leveraging software reuse for greatest business value.
In software reuse, we seem to recognize that "one size does not fit all." We acknowledge that even though different products, components, and platforms may share common features, that each one may have different project parameters and environments with different quality attributes and engineering-tradeoffs that need to be "preferred" and optimized that particular application: dynamic versus static, performance versus memory, storage versus latency, throughput versus bandwidth, single versus multi processing, optimistic versus pessimistic concurrency, security versus availability, and on and on.
Software process reuse is no different. Different products and projects have their own uniquely differentiating value proposition (if not there would be no business-need to attempt them in the first place). And those differentiating aspects warrant many kinds of process variation across projects, products, technologies and teams.
Those coming from a SixSigma background may point out how SixSigma strives for reducing process variation. But it's all too easy to forget the context for that is when repeatably reproducing the same output from the same inputs for the same desired set of quality attributes and tradeoffs (not to mention the "kinds" of variation SigSigma is appropriate for trying to eliminate).
So I would advocate the translation and application of software product-line practices to software processes (software "Process-Lines" or "Process Families" if you will) and the treatment of such common processes as first class architectures that need to accommodate the views and perspectives of ALL their critical stakeholders, and which should identify their essential quality attributes and tradeoffs, approaches to managing commonality and variability, and apply appropriate patterns and tactics (such as modifiability tactics for software processes and projects) to meet those objectives.
In light of the above, Lean & Agile software development define an architectural style for such process families and their architecture. Lean and Agile principles identify some of the critical process-quality attributes for such efforts. And the corresponding enterprise and its product offerings and their market segments may identify additional quality attributes that needs to met (such as security, regulatory auditability/compliance, large-scale and/or distributed projects and teams, etc.)
Continuing the previous discussion on software product-lines ...
Central to the notion of product-lines and product-families are tracking and managing three different kinds of software assets:
Architecture for such product-lines is all about managing commonality and variability, and easing their evolution to achieve a diverse family of products to achieve economies of scale from reusing common assets. Change/Configuration Management for SPLs is a very challenging problem. And variability management techniques often come down to a matter of binding-times. There are also more advanced strategies (some involving mathematical models).
A few resources on the subject of Commonality and Variability are as follows:
In July 2006 I presented at the Dr Dobbs' Architecture & Design World conference about SCM Patterns for Agile Architectures, which included a section on managing variations. I summarized that portion of the presentation as follows:Use Late-Binding instead of Branching:
Think about which of the following needs to "vary" and what needs to stay the same:
Commonality & Variability analysis helps identify the core dimensions of variation for your project
Use a combination of strategies based on the different types of needed variation and the "dimension" in which each one operates
Extending the analogy of software architecture views and quality attributes for software process architecture, I'd like to spend some time discussing software product lines. According to the SEI website on software product-lines, A Software Product-Line is defines as follows:A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.
At SoftwareProductsLines.com, Charles Krueger defines them as follows:Software product lines refers to engineering techniques for creating a portfolio of similar software systems from a shared set of software assets using a common means of production.
The key objectives of software product lines are: to capitalize on commonality and manage variation in order to reduce the time, effort, cost and complexity of creating and maintaining a product line of similar software systems.
Closely related to software product lines is the notion of software product families and Product Family Engineering. In many cases the terms product-line and product-family are used interchangeably. Sometimes a product-family is slightly more general in that a product-family may comprise one or more product-lines. The SEI has established a Framework for Software Product-Line Practices that encompasses topics such as architecture, organization, patterns, business-case, and even a section on configuration management for software product-lines.
After my previous postings on Software Architecture Views and Perspectives, Software Architecture Quality Attributes and Software Modifiability Tactics, the question remains as to what all this has to do with Agile processes or with CM.
Well, about a year ago I wrote that Software CM is NOT a Process! ...Software CM creates the medium through which software development changes & activities must flow. Therefore, Software CM is the intentional architecture of software development change-flow.
The elements of this Software CM architecture include practices, tools & technology, teams & organizations, valued deliverables & intermediate work-products, changes to and assemblies of these deliverables & work-products, and the set of needed status/tracking reports & measures.
So now I want to take the perspective of Software CM as an architecture, and I want to consider questions like:
I think I answered the first of these questions in my Dimensions and Views of SCM Architecture. I take the perspective of a 4+2 views model comprising Product, Project, Evolution, Environment, Process (+1), and Enterprise (+2). These views straddle the conceptual and physical aspect of both the content and context of the different kinds of "containers" that are to be managed and interrelated. And the dimensions of SCM complexity that prove most challenging are those of scale and diversity, and of differences between artifact change/creation time and decision binding-time.
The next question involves translating what Availability, Modifiability, Performance, Security, Testability, and Usability mean for a "process" architecture. I'll make an initial stab at that (feedback is encouraged):
What are the "quality" attributes of an "agile" process? Do they include ALL of the above? what about: adaptive? lean? result-driven (i.e. "working software")? self-organization? iterative? collaborative?
How about some of the traditional "quality" attributes of a CM system: traceability (vs. transparency?), reproduceability? repeatability?
After my previous postings on Software Architecture Views and Perspectives, Software Architecture Quality Attributes and Software Modifiability Tactics, the question remains as to what all this has to do with Agile processes or with CM.
Well, about a year ago I wrote that Software CM is NOT a Process! ...Software CM creates the medium through which software development changes & activities must flow. Therefore, Software CM is the intentional architecture of software development change-flow.
The elements of this Software CM architecture include practices, tools & technology, teams & organizations, valued deliverables & intermediate work-products, changes to and assemblies of these deliverables & work-products, and the set of needed status/tracking reports & measures.
So now I want to take the perspective of Software CM as an architecture, and I want to consider questions like:
I think I answered the first of these questions in my Dimensions and Views of SCM Architecture. I take the perspective of a 4+2 views model comprising Product, Project, Evolution, Environment, Process (+1), and Enterprise (+2). These views straddle the conceptual and physical aspect of both the content and context of the different kinds of "containers" that are to be managed and interrelated. And the dimensions of SCM complexity that prove most challenging are those of scale and diversity, and of differences between artifact change/creation time and decision binding-time.
The next question involves translating what Availability, Modifiability, Performance, Security, Testability, and Usability mean for a "process" architecture. I'll make an initial stab at that (feedback is encouraged):
What are the "quality" attributes of an "agile" process? Do they include ALL of the above? what about: adaptive? lean? result-driven (i.e. "working software")? self-organization? iterative? collaborative?
How about some of the traditional "quality" attributes of a CM system: traceability (vs. transparency?), reproduceability? repeatability?
After my previous postings on Software Architecture Views and Perspectives, Software Architecture Quality Attributes and Software Modifiability Tactics, the question remains as to what all this has to do with Agile processes or with CM.
Well, about a year ago I wrote that Software CM is NOT a Process! ...Software CM creates the medium through which software development changes & activities must flow. Therefore, Software CM is the intentional architecture of software development change-flow.
The elements of this Software CM architecture include practices, tools & technology, teams & organizations, valued deliverables & intermediate work-products, changes to and assemblies of these deliverables & work-products, and the set of needed status/tracking reports & measures.
So now I want to take the perspective of Software CM as an architecture, and I want to consider questions like:
I think I answered the first of these questions in my Dimensions and Views of SCM Architecture. I take the perspective of a 4+2 views model comprising Product, Project, Evolution, Environment, Process (+1), and Enterprise (+2). These views straddle the conceptual and physical aspect of both the content and context of the different kinds of "containers" that are to be managed and interrelated. And the dimensions of SCM complexity that prove must challenging are those of scale and diversity, and of differences between artifact change/creation time and decision binding-time.
The next question involves translating what Availability, Modifiability, Performance, Security, Testability, and Usability mean for a "process" architecture. I'll make an initial stab at that (feedback is encouraged):
What are the "quality" attributes of an "agile" process? Do they include ALL of the above? what about: adaptive? lean? result-driven (i.e. "working software")? self-organization? iterative? collaborative?
How about some of the traditional "quality" attributes of a CM system: traceability (vs. transparency?), reproduceability? repeatability?
I'm fairly interested in the literature on Software Architecture Views and Perspectives. Folks here may remember by work on Dimensions and Views of SCM Architecture as one of the reasons why ...
The text of the entire 2nd edition of the "Software Architecture in Practice" textbook is available online as one source fo information on the subject (among others). I found another good link (& book reference) at http://www.viewpoints-and-perspectives.info/
It's the website for the book "Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives" by Nick Rozanski and Eoin Woods. They classify/use "Viewpoints" and "Perspectives" as follows:
Viewpoints:
Perspectives:
Found a few other links too:
Getting back to the subject of my previous blog-entries on Software Architecture Views and Perspectives and Software Architecture Quality Attributes, I wanted to talk more specifically about the quality attribute of Modifiability.
The Modifiability of a software system is related to how minimal is the cost/effort to develop and deploy changes to the software. This relates to well known concepts and principles of coupling, cohesion, maintainability, etc. and is the basis for many of the elements of object-oriented, component-based, and aspect-oriented design ("reuse" is a close cousin for all these as well).
Software Modifiability Tactics are presented in section 5.3 of Software Architecture in Practice. A taxonomy is given which relates architectural tactics to architectural patterns ("styles") and the design patterns which are largely concerned with achieving the attribute (in this case "modifiability") for various types of products and contexts. The article Understanding Architectural Patterns in Terms of Tactics and Models even has a nice matrix that maps architectural patterns or styles to the various kinds of modifiability tactics.
The taxonomy for software modifiability tactics is broken down as follows:
In September 2007, an SEI Technical Report on Software Modifiability Tactics was published that provides a comprehensive discussion of these modifiability tactics and the architecture/design patterns that can be used to implement them (and some of the tradeoffs involved).
Links and Resources on Software Modifiability Tactics:
In a subsequent blog-entry I will muse about how Modifiability relates to Agility in both software architecture/design and in software process architecture/design.
My review of Lean Project Management is in the February 2008 issue of the Agile Journal.Lean Project Management: Eight Principles for Success, is actually a second edition of the eBook Eight Secrets to Supercharge your Project with CCPM. It is available both in hardcopy and eBook formats. Lawrence Leach (www.advanced-projects.com) is perhaps best known as author of one of the most comprehensive texts on the subject of Critical Chain Project Management (CCPM). In this book, subtitled "Combining CCPM and Lean tools to accelerate project results," the author essentially integrates Lean Thinking into CCPM, along with elements from the Theory of Constraints (TOC) and PMBoK/PMI. Leach calls the result Lean Project Management or LPM.
... All in all, I found Lean Project Management to be a fairly quick read providing a good overview of some TOC and CCPM fundamentals and how they align with Lean thinking, as well as how Lean thinking can be applied to some of more traditional PMBoK methods. Someone looking for a more comprehensive reference on TOC thinking processes and CCPM would probably be better off reading Goldratt's books, the work of William H. Dettmer, and the 2nd edition of Leach's Critical Chain Project Management. But for those wanting the bird's eye overview with a brief "zoom in" on some of the details, along with how Lean thinking helps tie it all together with some of the more traditional project management methods, Lawrence Leach's Lean Project Management is a nice overview text describing some of the most powerful aspects of TOC and CCPM through "Lean eyes for the PM guy!"
Read the full review
Following on to my previous blog-entry about Software Architecture Views and Perspectives, the book "Software Architecture in Practice" also describes a method called Attribute-Driven Design or ADD. This is not yet-another-design-method like BDD or TDD. ADD is concerned software architectural design (so it's at the "architecture-level" rather than what we might normally think of as the "design-level").
ADD is concerned with explicitly identifying the desired quality attributes of an architecture. Many of us know that simply implementing the (functional) requirements correctly is just the beginning of any good design, and possibly not even the most important attribute of the design. In addition to other attributes like security or availability, there are also attributes like modifiability of an architecture. And it is often these attributes that, if attained, are the true indication of whether or not we've done a good job.
Some of the more commonly desired quality attributes are:
- Availability
- Modifiability
- Performance
- Security
- Testability
- Usability
ADD also explicitly mentions the use of patterns and tactics as part of its methodology for achieving quality attributes and making design tradeoffs (quality attributes are often the "forces" for a pattern). For each of the common quality attributes above, it identifies a taxonomy of common tactics and patterns used to make good tradeoff decisions for particular aspects of the design.
Although it look s a bit heavyweight, ADD looks promising in its use of patterns and tactics and recursive/iterative nature. But what I look most about it is that fact that it makes explicit the kinds of quality attributes and their non-functional use-cases or "stories" which can then have business value/priority associated with it, and thereby justify the existence of activities that help realize those attributes of the system.
For some more information on ADD, see the following:
- Software Architecture in Practice
- The SEI webpage on Attribute-Driven Design
- The paper Quality Attribute Design Primitives and ADD
- Introduction to the ADD Method
- A Practical Example of Applying ADD (SEI Technical Report)
- Links from Real-world Software Architecture in .NET Developer's Journal
- Presentation from Paul Clements on Designing Software Architectures
- The paper Generalizing a Model of Software Architecture Design from Five Industrial Approaches (by a star-studded list of authors in the field)
Regarding my previous posting about Software KanBan, much as I really do like it and have nothing but the utmost respect for the likes of Corey Ladas and David Anderson, there is one major quibble I have with some of the stuff being said ...
I think all the stuff saying it is Iteration-less and Iteration-free is a bunch of hooey! I don't agree at all and I think it is extremely misleading to say that Software KanBan doesn't use or need iterative development.
Don't get me wrong - I think I understand where they are coming from. There is often a great deal of recurring and heated discussion on numerous Agile forums about "Ideal" iteration length. I understand how folks can be sick and tired of that (to be honest, I myself never really paid too much attention to those particular discussion threads about ideal iteration-size).
The idea that is new or revolutionary for some is that release/feature content is decoupled from development! One or more features/requests are being worked in parallel, and every two weeks (or however long) some combination of newly developed functionality from those that are ready is selected to be released (rather than before development is underway).
But it seems to me that this is just an application of Agile-style development iterations applied to multi-project management. It is Releases that are decoupled from iterations (and hence iteration-free). But as I see it, the iterations are still present: they are where the development is, on the various feature "projects" that are being developed in an incremental and iterative manner, each at their own rhythm (some might be every two weeks, others might be less frequent, but they all find their pace).
I don't believe for one second that each of those features/requests are specifying and elaborating 100% of their requirements before they start coding anything. Looks to me like, for all but the smallest of requests, they may flesh out a certain amount of requirements up-front (be it lightweight use-cases, or even something a bit more formal), but only to a high-level or medium-level of detail. And from that point on through, the detailed requirements, implementation, and feature-level testing and integration-testing they are proceeding in a VERY MUCH iterative fashion.
It may not be a strict fixed length, in that the rhythm may fluctuate and readjust from time-to-time, but it definitely does have a regular rhythm! The length of any given "iteration" is fixed to the cadence of the feature-team (even if it is a team of 1 or 2). Not all iterations may be the same length, but any given iteration is working to a fixed due-date rather than letting that cycle stretch out until the "scope" is complete.
So don't let anyone tell you that Agile development need not require working in an iterative manner. It most definitely does (and at multiple levels of scale). Just don't assume it means that iterations must always be a property of a "release" as opposed to some other related chunk of work (possibly multiple ones proceeding in parallel).
It is not the releasing that needs to be iterative, it is the development. And if the releases are decoupled form development (which I think is a GREAT idea), then the development of any non-trivial sized feature or request still will need to proceed in an iterative manner according to some regular cadence that gets established.
For those who haven't been keeping up with "Agile 2.0" or "Post-Agile", one of the more recent developments has been KanBan for Software Development. I first heard about it from David Anderson in a presentation he gave at about a KanBan System for Sustaining Software Engineering. Then I heard David and some others saying how they did away completely with iterations and simply release every two weeks, and shortly thereafter David started a KanBan Development YahooGroup.
Anyway, I think it looks extremely interesting and promising, particularly for folks in an internal IT or tool development group where much (if not all) of their work is sustaining engineering of existing tools and not so much major new feature/product development.
So I thought I would roundup several resources on the subject for folks who might be interested in learning more:
I am still amazed at the number of software managers who are unfamiliar with "The Mythical man-month" lesson that says (paraphrasing here) adding more people to a late project makes it even later. So I decided to round-up some resources on the subject. Here they are:
Several of the materials I found were course lectures from various Universities:
I like the classic quotes! Among my favorites ...“Adding manpower to a late software project makes it later.”
“How does a project get to be a year late?... One day at a time.”
“Nine women cannot deliver a baby in one month”
“Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.”
“Plan to throw one away; you will, anyhow.”
“Conceptual integrity is the most important consideration in system design.”
“If a system is to have conceptual integrity, someone must control the concepts. This is an aristocracy that needs no apology.”
“The purpose of organization is to reduce the amount of communication and coordination necessary.”
“Build a performance simulator, outside in, top down. Start it very early. Listen when it speaks.”
“The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself... One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be... It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time.”
“The computer resembles the magic of legend in this respect, too. If one character, one pause, of the incantation is not strictly in proper form, the magic doesn't work. Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program.”
A couple months ago I stumbled across the MIT Lean Advancement Initiative (LAI) website at http://lean.mit.edu
It is a veritable goldmine of papers and research relating to lean product development and lean systems engineering. You can search through the publications yourself. I took an initial pass thru and found the following couple dozen papers whose abstracts caught my eye:
Happy reading!
Marry Poppendieck gave a keynote at SQE's Agile Development Practices Conference during the last months of 2007. The slides for that presentation are now available online. The presentation is entitled Welcome to the Mainstream (and How to Fail with Agile)
An interesting read!!!