Balancing Agility and Discipline

Barry Boehm and Richard Turner wrote an interesting book a few years ago, entitled "Balancing Agility and Discipline: A guide for the perplexed". 

Boehm, of course, is the author of an early, agile risk management strategy and practice called the Spiral Method.  The neat thing about the spiral is that it is like the wind-up of a discus thrower: it can be used as the launching method to a methodology, like one of the agile methods. 

So, it is fitting that Boehm and Turner would write a book on agile--though no one would mistake Boehm for an agilist--since the spiral and any of the agile methods actually fit together.

Boehm and Turner's theme in the book is that discipline works in any methodology, and is essential to predictable performance.  Agile is no exception.  In an interesting twist, there are three endorsements for the book in the form of forwards: Grady Booch, the guru of object oriented practices and a proponent of methods that are arguable not too agile, says he understand's Boehm's point; Alistair Cockburn, author of perhaps the least disciplined of the agile methods is on board also; and Authur Pyster, the CIO at the FAA at the time, certainly no source for agile methods, says FAA is trying to be agile where they can, even though they have truly mission critical software.

For me, the interesting part of the book is the appendices.  Check out appendix E which is metric comparison of performance expectations.

Are you on LinkedIn? Share this article with your network by clicking on the link.

Project Management the Agile Way

It's almost here! "It" is my new book, "Project Management the Agile Way...Makng it work in the enterprise", most likely in Amazon by January 2010 if everything continues on the path with the publisher-Gods.

In this book, I expound on my top-five for agile, and actually blow it out to 12 major themes, from a quick overview of 4 agile methodologies, through a business case, test strategy, and eventually ending with benefit capture.

You know, on this last point, the NPV of the typical agile project is better than the traditional plan-driven methodology, at least for a few periods where the early deliveries start earning benefits early.

If you work in a business environment where the executives need to be persuaded to do projects, and a business case becomes a contract for performance, this may be the book for you. This is about agile in a business situation where projects may not be a core competency, but simply a means to an end.

I hope you enjoy the read as much as enjoyed the write!

Are you on LinkedIn? Share this article with your network by clicking on the link.

Test Driven Development -- TDD

New to the agile scene? Curious about XP -- Extreme Programming? One practice born in XP and now widely dispersed in the agile community is Test Driven Development, TDD.

The main idea
Here are the main ideas of TDD, and they are a mind-bender for the traditionalist: Requirements are documented in the form of test scripts, and test scripts are the beginning point for product design.

TDD works this way: detailed design and development, after consideration for architecture, is a matter of three big steps:

Step 1: document development requirements with test scripts. Beginning with functional requirements in the iteration backlog, and in collaboration with users, the developer writes technical design requirements in the form of a test script, and writes the script in a form to be run with test-automating tools. Automated tools enable quick turnaround. Automated tests run fast, run on-demand, run repeatedly the same way, and run under various data and system conditions.

Step 2: run the test, modifying the object design until it passes. If the test fails, as it often will, the developer implements the quickest and simplest solution that will likely pass. Step 2 is repeated until the test passes.

Step 3: refine the detail design of the object. After the solution passes the test, the developer iterates the detail design to be compliant with quality standards. In doing so, only the internal detail is changed and improved; no change is made to the object’s external characteristics. To verify no external changes and continued functionality, the modified solution is retested internally.

A project management tip: TDD, unit tests, and acceptance tests

• TDD was invented as a design practice; it is commonly applied to the lowest level design units
• “TDD's origins were a desire to get strong automatic regression testing that supported evolutionary design.”4
• Unit tests, distinct from TDD tests, are postimplementation design verification tests. In most respects, unit tests and TDD tests are very similar, but the purposes are very different: one drives design and the other verifies implementation.
• The concept of automated tests is also applicable to higher-level tests, such as product integration tests and user acceptance tests, but these are not for the purpose of driving design.
• At higher levels, designs that pass unit tests are being tested in a larger context and by independent testers, including end users.

Are you on LinkedIn? If so, share this article with your network by clicking on the link!

What is this thing called Agile?

I've been working on a book about agile project management for enterprise projects. My publisher just gave me a title! "Project Management the Agile Way -- Making It Work in the Enterprise". Look for it in January, 2010.

Until then, the article below is a petty good introduction to some of the top-level ideas. You can down load "What is this Thing Called Agile" from my library at slideshare.com

There are some other materials there you may find interesting. Let me know!

Click here to share this article with your network on LinkedIn!