Author: neopragma

An IT professional since 1977, I’ve served in a variety of technical and managerial roles. I’ve worked mainly as a consultant since 1984, keeping one foot in the technical camp and one in the management camp. A lifelong learner, I’ve always been interested in exploring better ways to deliver business value through information technology. I’m currently working as an independent consultant, trainer, and coach with an interest in bringing together the best of tried-and-true methods and the best of leading-edge methods to help businesses realize the maximum return on their IT investments and efforts.
Posted on by — 2 Comments

Delivery mode

This is the third of three posts dealing with aspects of management that I consider significant in choosing management techniques and metrics for software development and support:

  1. Iron Triangle management
  2. Process models
  3. Delivery mode (this post)

Despite the many complexities of software work, we are always working in one of two modes:

  • Discrete project
  • Continuous support

By discrete project mode I mean a mode of operation in which an organization creates a special initiative that exists for a defined period of time whenever it needs to achieve a set of related objectives, such as creating a new software application or upgrading the routers on the corporate network.

In contrast, with the continuous support mode of operation, the organization maintains a stable team to support each technical asset (such as the corporate network, a business rules engine, a COTS CRM package, or an ETL product) or suite of applications (such as the suite of applications that support consumer lending in a financial institution) throughout its lifetime. The size of the team may grow or shrink depending on the level of work needed to support the asset or applications at any given time, but the organization does not start a new project for every set of objectives pertaining to the asset or applications.
Continue reading Delivery mode

Posted on by — 8 Comments

Process models

This is the second of three posts dealing with aspects of management that I consider significant in choosing management techniques and metrics for software development and support:

  1. Iron Triangle management
  2. Process model (this post)
  3. Delivery mode

In my experience, no two organizations, and no two teams within the same organization, use exactly the same process model for software delivery; nor do they keep the same process intact forever. Everyone tailors their process to their own needs and to the realities of their own situation. In addition, most organizations use more than one process, depending on the nature of each particular initiative or work stream.

That is as it should be. Yet, despite the many variations, there are common patterns that can help us understand how we might plan and track the progress of software development initiatives and support activities in ways that help us make management decisions, as opposed to merely following a published guideline for planning and tracking.
Continue reading Process models

Posted on by — 5 Comments

Iron Triangle management

This is the first of three posts dealing with aspects of management that I consider important:

  1. Iron Triangle management
  2. Process model
  3. Delivery mode

The reason I think these aspects are important is that they affect the way we handle various management issues, particularly our choice of metrics. Metrics that apply to one option in one of these areas may be meaningless or misleading when applied to a different option.

As George Box famously wrote, all models are wrong but some models are useful. The model I present here is based on my own experience and observation. It is wrong by definition by virtue of the fact it is a model; but hopefully it is useful, as well.

The order in which the aspects are listed reflects their relative effect on our choices, in my opinion. The strongest effect comes from our approach to managing the Iron Triangle. That is the subject of this post.
Continue reading Iron Triangle management

Posted on by — 3 Comments

The problem with success (and failure)

This morning I noticed a copy of the good old Cone of Uncertainty on the wall of a cubicle at a client’s office. It reminded me of Laurent Bossavit’s ebook-in-progress, The Leprechauns of Software Engineering, in which he challenges several of the myths or assumptions that have become traditional lore in the software industry, including that one.

Laurent writes,

What is odd, to any experienced software engineer, is that the Cone diagram is symmetrical, meaning that it is equally possible for an early estimate to be an over-estimate or an underestimate. This does not really square with widespread experience of software projects, which are much more often late than they are early.

Er…wait a second. Isn’t that very assertion an example of “anecdotal evidence?” Is it another Leprechaun? Who says projects are more often late than early?

Silly Dave! Everyone knows who said that. It was the Standish Group, in their famous Chaos Report of 1994. Slightly more than 70% of IT projects fail. That’s why every office building in the industrialized world is on fire, and white-collar refugees are streaming from the cities, leaving their belongings behind except for whatever personal electronic devices they can carry.

Only…they aren’t.
Continue reading The problem with success (and failure)

Posted on by

Small is beautiful

There’s an old saying that the more things change, the more they stay the same. The saying certainly applies to the field of software development. Things change all the time, and the things that change tend to change for the same reasons: Changing business priorities, changing costs, changing understanding of needs, changing actual needs, changing competitive pressures, changing technologies, changing availability of resources. Change occurs at all levels from the enterprise strategic plan all the way down to individual technical tasks. The details of all these changes may be very different, but there is one basic idea that can help us handle change effectively, wherever and whenever it occurs: Keep things small.
Continue reading Small is beautiful

Posted on by — 2 Comments

Death is optional

In The Collapse of Complex Societies (ISBN 978-0521386739), Joseph Tainter observes that societies adapt to meet the challenges of growth by increasing their complexity. Over time, societies receive diminishing marginal returns on their investment in complexity. When they reach the stage that the demands of the complex organizational structure exceed the capacity of the resources available to support it, they collapse. It seems as if established, complex societies cannot respond to this challenge by simplifying their own structure. Instead, they collapse into smaller, simpler societal groups that may then begin the process of growth and increasing complexity all over again. The author examines the collapse of notable, successful, complex societies such as the Mayan and Roman empires and the Anasazi civilization centered on Chaco Canyon.

I can’t help noticing the resemblance between the pattern of growth and collapse in historical states and empires and the pattern of growth and collapse in corporations. It seems as if corporations, like states and empires, undergo a process of increasing complexity as they learn to deal with competitive challenges and as they increase their market share, their size, and the scope and range of their business activities. Historian Arnold Toynbee famously described the pattern of ascendance and decline of civilizations in terms of internal moral decay. The anonymous author of a Wikipedia article on Societal Decay put it quite nicely when he or she wrote, "societies that develop great expertise in problem solving become incapable of solving new problems by overdeveloping their structures for solving old ones."

Continue reading Death is optional

Posted on by — 1 Comment

Utilization thinking vs. throughput thinking

In helping organizations achieve their goals for process improvement, I have found the single most prevalent conceptual barrier to be the notion of throughput as opposed to resource utilization. Many, and possibly most organizations hinder their own process improvement efforts when they try to maximize individual resource utilization rather than trying to maximize throughput. Once they are able to move beyond utilization thinking, many other challenges fall away naturally.
Continue reading Utilization thinking vs. throughput thinking

Posted on by

Get out of your own way!

This is a re-issue of a post from my old blog dating from December 17, 2006. It is a review of a session I attended at XP Days Germany 2006. I think it is still relevant today.

One of the most interesting sessions I attended at XP Days Germany was Developer Awareness, given by Shamsuddin Butt. Butt has a dual background in software development and psychology, which gives him a unique perspective on issues of organizational culture change, team dynamics, individual performance, and coaching.

In this session, Butt applied concepts from Timothy Gallwey’s book The Inner Game of Tennis to the question of individual and team performance in software development. In the book, Gallwey describes the “inner game” within a player between his/her Self 1, who is judgmental and controlling, and Self 2, who can realize the individual’s potential for high performance if only Self 1 would get out of his/her way. The basic idea is to feel what you’re doing and just let yourself do it, rather than trying to monitor, control, and criticize yourself from an internally-imposed third-party viewpoint.
Continue reading Get out of your own way!

Posted on by

Pair programming and lean software development

I have learned quite a lot from reading Lean Software Engineering, a website authored by Corey Ladas. Although I am not personally acquainted with him, I have gained a great deal of respect for his thinking and his experiences in applying lean principles to software development.

My growing respect for him may be the reason I was struck by a comment of his that I came across recently while browsing the site. In a response to a reader’s comment dated January 7, 2008, he wrote: “Pair programming is antithetical to Lean” It was just a flat assertion with no explanation.

I was puzzled. Lean software development doesn’t speak to particular development practices, as far as I know. What might cause a practice to be antithetical to lean or, for that matter, to support lean? The only basis I could think of on which to reach such a conclusion was that the practice either hinders or helps us in applying lean principles to software development. Corey did not provide the same level of careful analysis and explanation as he does with most of the useful material on his site, so I decided to reason through the question myself.

Continue reading Pair programming and lean software development