A Django site.
July 6, 2008
» Iterative and Incremental redefined redux

The agile community has written much about this in the past year or so:

Apologies in advance for being a "stick in the mud" on this one - I'm not particularly happy with the definitions so far. I searched around some more on the WWW and came across one I like a lot that I think better meets our needs.

It is from the paper What is Iterative Development? (part 1), by Ian Spence and Kurt Bittner,
Iterative and Incremental Development:
A style of development that involves the iterative application of a set of activities to evaluate a set of assertions, resolve a set of risks, accomplish a set of development objectives, and incrementally produce and refine an effective solution:
  • It is iterative in that it involves the successive refinement of the understanding of the problem, the solution's definition, and the solution's implementation by the repetitive application of the core development activities.2

  • It is incremental in that each pass through the iterative cycle grows the understanding of the problem and the capability offered by the solution.

  • Several or more applications of the iterative cycle are sequentially arranged to compose a project.
Sadly, development can be iterative without being incremental. For example, the activities can be applied over and over again in an iterative fashion without growing the understanding of the problem or the extent of the solution, in effect leaving the project where it was before the iteration started.

It can also be incremental without being truly iterative. For example, the development of a large solution can be broken up into a number of increments without the repetitive application of the core development activities.

To be truly effective the development must be both iterative and incremental. The need for iterative and incremental development arises out of the need to predictably deliver results in an uncertain world. Since we cannot wish the uncertainty away, we need a technique to master it. Iterative and incremental development provides us with a technique that enables us to master this uncertainty, or at least to systematically bring it sufficiently under control to achieve our desired results.

I like that this definition separated iterative from incremental and then defines them together. I would summarize it as follows (but I like the above better, even if it is longer):
Iterative development is the cyclical process of repeating a set of development activities to progressively elaborate and refine a complete solution. The “unit” of iterative development is an “iteration”, which represents one complete cycle through the set of activities.

Incremental development
is the process of developing and integrating the parts of a system in multiple stages, where each stage implements a working, executable subset of the final system. The “unit” of incremental development is an “increment”, which represents the executable subset of the system resulting form a particular stage

Iterative and Incremental development
is
therefore ...
the application of an iterative development lifecycle to successively develop and refine working, executable subsets (increments) of a solution that evolves incrementally (from iteration to iteration) into the final product.
  • Each iteration successively elaborates and refines the understanding of the problem, and of the solution's definition & implementation by learning and adapting to feedback from the previous iterations of the core development lifecycle (analysis, design, implementation & test).
  • Each increment successively elaborates and refines the capability offered by the solution in the form of tangible working results that can be demonstrated to stakeholders for evaluation.
An Agile Iteration is a planned, time-boxed interval (typically measured in weeks) whose output is a working result that can be demonstrated to stakeholders:
  • Agile Iterations focus the whole team on collaborating and communicating effectively for the purpose of rapidly delivering incremental value to stakeholders in a predictable fashion.
  • After each iteration, the resulting feedback and data can be examined, and project scope & priorities can be re-evaluated to adapt the project's overall performance and optimize its return-on-investment
So in addition to the non-agile-specific definitions above, we see that Agile iterations are adaptive, in that they use the previous results and feedback to learn, adjust and recalibrate for the next iteration. And Agile increments are tangible, in that they can be executed and made accessible to stakeholders for demonstration and evaluation.

That's my story and I'm sticking to it!

February 19, 2008
» BOOK: Lean Project Management

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

February 3, 2008
» The Majesty of the Mythical Man-Month

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.”


February 4, 2007
» The Cone of Uncertainty

I came across a great set of responses to an IEEE Software Article by Ted Little that seemed to question the cone of uncertainty. Among the respondents were Phillipe Kruchten and Steve McConnell. This prompted me on a search for resources about the cone of uncertainty. Here is what I came up with:


Does anyone know of others? I'm particularly interested in anything available online by Barry Boehm and also from Steve McConnell. [Updated 2/2/2007 - Steve McConnell emailed me himself with the URL to a recently available article on his website]

January 21, 2007
» Agile Tooling Survey Results

From Pete Behrens' Agile Executive Blog, the results to the Agile Tooling Survey they conducted in October are now available online at http://trailridgeconsulting.com/surveys.html:

    With over 500 survey responses from 39 countries, we feel this survey
    provides an excellent benchmark for where the agile movement is at
    today and how we are using project management tooling to assist our
    agile processes.

    This report builds a corporate profile of companies that are following
    agile processes today and then uses that profile to analyze how they
    are using project management tooling to support various aspects of
    their agile processes.

It's rather interesting to see what sorts of tools are being used for version-control, defect/issue/enhancement-tracking (DIET), and project planning & tracking, particularly when some high-profile Agilists would have us believe that (other than version control) Agile should "eschew" such tools.

I don't think the problem is the tools. I think the problem is most of them were/are made and used in a non-agile fashion that didn't have the agile way of working in mind. Now that there are some tools out there which do, it seems they are helpful after all :-)

November 12, 2006
» Scaling Agility: Agile Program Management

Over the past months I've come across a bunch of good links & papers on the topic of "Going Agile" at the program-level:

Michele Sliger (of Rally Software Development) has several good articles and presentations on Relating PMBOK Practices to Agile Practices


On using Agile methods in organizations with a stage/gate approach to program management, see some of Per Runeson's work in this area:
Murray Cantor has some good papers on Governance and Variance as it applies to Agility:
Some other papers & resources:

Those interested in some advanced agile planning concepts should look at Jeff Sutherland's paper on Scrum II - The Future of Scrum: Parallel Pipelining of Sprints in Complex Projects (and the presentation slides that go with it)

There are several REALLY GOOD whitepapers on Adopting & Scaling Agile at Rally's Agile Knowledge Portal, including the following in particular:

There's gotta be some other good stuff out there and Agile Portfolio, Program and Multi-Project Management! If you know of any - please add a comment and hyperlink or URL!

November 7, 2006
» Scaling Agility: Distributed Agile Development

Current issues of IEEE Software, CACM, and ACM Queue have articles related to agile distributed development and release management ...

The Sept/Oct 2006 issue of IEEE Software is about Global Software Development. It has several Agile-related articles (like A Practical Management and Engineering Approach to Offshore Collaboration)

This months CACM theme is "Flexible and Distributed Software Processes" with articles on distributed agile development (which are currently available online), including:


ACM Queue an article on Agile/Iterative Release Management entitled Breaking the Major Release Habit.

Other resources on Distributed Agile Development:

Also, although it's not specific to Agility, the book Software without Borders appears to have some good reviews by several folks who are well-respected in the Agile community (also check out the online references section of the book.

October 16, 2006
» Scaling Agility: Agile Systems Engineering

Over the past months I've come across a bunch of good links & papers on the topic of "Going Agile" at the program-level for large systems and systems of systems. Some of these relate to Agile program Management and others are more about Agile Systems Engineering (and some relate to both). I'll mention the ones on Agile Systems Engineering in this blog-entry and leave the ones on agile program management for a subsequent entry:


That's the best I came up with. If you know of other good links on this topic, please send me a comment!

» Scaling Agility: Seamless Agility across the Enterprise

David Anderson writes about the recent Agile2006 conference in his blog-entry Thoughts for Agile2006:

Scaling Agile. The BIG issue for this year is scaling agile across a whole organization. I see this as having three parts - program or multi-project management and the rollup of schedules and resource plans to a Director or VP level; architecture and enterprise level modeling of a domain and data center; and finally configuration management including build, integration, branch and merge strategies, and work-in-progress batching and related communication.

Ive been dealing with this topic a LOT lately in my own organization as part of efforts to spread amd adapt Agile methods across a large distributed enterprise working with large systems and teams. Ive been researching and collecting lots of resources, including some earlier blog-entries on Agile CMMI and Dancing Elephants and Agile Adoption across the industry.

My perceptions of where the "seams" of the enterprise are that are hardest to introduce Agility into are the close collaboration and alignment required across organizational (lifecycle discipline) boundaries and geographic boundaries (and I find the former to be more difficult to surmount than the latter.)

If I try to categorize them as different areas or aspects that each require the ability to be agile, I come up with something like:
  • Process - Adapting Agile to the Organization (making processes responsive to change)

  • Product - Agile Systems Engineering/Architecture (making the requirements & architecture be responsive to change)

  • Project - Agile Program Management & Governance (making the project be responsive to change)

  • People - Distributed Agile Development (collaborating across multiple sites, teams, and timezones)

  • Organization - Agile Metrics/Reporting, Governance, and Organizational Design

  • Environment - Agile CM, deployment, operation/support, etc.

I'll be blogging separately with lists of resources of found for several of the above.

» Scaling Agility: Adapting Agile to the Organization

Here is a list of resources I've found that I feel are applicable in figuring out how to scale Agility for a large organization and project. (On the subject of metrics and values, I personally find Sam Guckenheimers work to be of greatest interest):







Additions and corrections are welcome!