Agile Development and the CMM


Agile development and the CMM can co-exist. Since the CMM specifies the what (in terms of the KPAs) and is methodology neutral, agile development methods can be used as the method (the how) to achieve much of CMM process maturity. Also, if you've gotten this far in this book, it should be obvious that the claim that agile development does not require discipline is very much false. Agile development is hard work and requires a great deal of discipline.

The practices of extreme programming have been contrasted with the CMM KPAs in various articles [Glazer 2001] [Paulk 2001] [Bandaru 2004]. If you are interested, I highly recommend reading them. The conclusion reached by all these sources is that the extreme programming practices do offer a solution to most of the KPAs. Of the eighteen KPAs, six are largely addressed in XP, and five are partially addressed. In this book, I have consciously added practices such as configuration management, professional development, and business knowledge because they are implied in the agile literature, but required for sustainable development. As a bonus, they happen to also be called out as KPAs. Likewise, the principles of continual refinement and defect prevention turn out to be level 5 KPAs, and are thus of extremely high value to software organizations.

What I find particularly intriguing with agile development and the CMM is the role of the agile mindset in the implementation of development processes. As I have personally discovered, an organization can only be as agile as its least agile part. Furthermore, since software teams must by their nature be cross-functional, if one functional part of the team is not agile, then the entire team will feel the effects. Here are some examples that I have personally seen:

  • Product management and/or engineering management that wants to completely specify all the features that make up the next software release before any code is written. Sometimes it is really hard for people to accept that they can't predict what the next release will contain, even if that release date is a year out or more. If these feature lists are followed religiously, there is no room for agility.

  • A marketing department that needs a large amount of lead time to write the marketing material for the next release. This means it will be hard to add features that are important to users late in a release cycle, and this limits agility.

  • A documentation group that is used to working on documentation after all the features are done. If it takes a long time to write the documentation, then documentation is going to continually lag development and slow it down.

  • A software testing team that is heavily relied upon by developers to find defects (i.e., a defect detection culture). Invariably, the testing group will become a bottleneck and will also be frustrated by the poor quality of the product given to them to test.

  • Bizarre manufacturing policies that dictate, for example, that physical CDs must be produced for all releases, that a minimum inventory must be maintained, and that every new release must involve new CDs for example, electronic distribution and the Internet are not utilized or are thought of as secondary to the CDs. Agile products must ship regularly; if each shipment costs money, it may be easier to question the frequent releases than to question the silly practices that cause the high costs . . .

Each of above examples illustrates the problem with process improvement in an organization. If you choose to become an agile organization, then agile can start in software teams, but it had better spread, or overall the positive effects of agile development will not be as noticeable as they should be. This is where the principles of agile development come in because they must be applied across the entire organization. The practices will largely differ depending on the function (i.e., software developers will have different practices than documentation people or marketing people), but the mindset must be similar to maximize overall agility.

The topic of an agile enterprise is one that could easily occupy a book of its own. As an exercise to interested readers, I would recommend that you read through the principles in the Agile Manifesto (www.agilemanifesto.org) and reflect on the role of each in all the functional areas of your software teams. In terms of the principles of sustainability outlined in this book and some of the select practices, I believe that there is a great deal of applicability to CMM maturity:

  • Continual refinement in how the team works through frequent retrospectives and tuning of processes is a level 5 KPA.

  • Having a working product every day, even if it is not functionally complete, makes Software Quality Management (a level 4 KPA) attainable. The goals of SQM are to plan the SQM goals (in this case: it works), make them measurable, and to quantify and manage the goals.

  • Defect prevention is a level 5 KPA.

  • The notion of minimal documentation applies to many of the KPAs. However, most notable is how it applies to Organization Process Definition (a level 3 KPA). There's nothing wrong with creating a diagram and short description of your agile process as is done in [Highsmith 2004a] and accompanying that with a list of best practices and lessons learned. Such a document would be useful in a large organization, especially if it's continually updated and it's only as long as it needs to be. A 50-page document can often convey the same information as a 500-page document. Besides, in the agile way, what's wrong with leaving some things open to experimentation as long as teams are using the agile principles?




Sustainable Software Development. An Agile Perspective
Sustainable Software Development: An Agile Perspective
ISBN: 0321286081
EAN: 2147483647
Year: 2005
Pages: 125
Authors: Kevin Tate

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net