Archive for the ‘scrum’ Tag

The Over-Under on Process

As long as there has been a Software Development Life Cycle (SDLC), there have been efforts to devise processes to manage it.  From the excruciating waterfalls of the 1980s (e.g., Mil-Spec 2167), through the OO methodology wars of the 1990s (e.g., OMT, Booch), to the broader processes of the 2000s (RUP, Agile), these processes have evolved along with technologies and business demands.

Various process aspects may be more or less applicable to a particular reality and they are always adapted in some way from the published baseline.  In my last company, we embraced Scrum as being closest to our sensibilities out of the box.  We then augmented the notion of the Product Owner with multiple feature owners recognizing that no one person can expertly represent the constituencies of market trends, immediate customer requests, and the underlying technical issues.

We also had two teams, Application and Platform, each with interdependencies that couldn’t always be split by our full 3-week sprints.  So we concocted a process by which each team executed sprints separately; still 3 weeks, but offset by 1 week to give the Platform team a head-start.  Pros and cons with this, but that’s another post.

The point is that SDLC management processes along with their human and non-human components form complex systems.  Their selection and adaptation must be performed thoughtfully and nothing substitutes for experience here since to a large degree, human behavior will be the make or break factor.

Fundamental Objectives

Any SDLC process worth implementing must achieve certain fundamental objectives irrespective of the underlying technology, the experience of the team, someone’s favorite textbook, the phase of the moon, or the flavor of the month.  In my view, these are they.

  1. Measurability: Coining a famous maxim, you can’t manage what you don’t measure. Metrics may vary from one process to another, but fundamentally a well-defined process enables consistent and comparable measurement of activities so that they can be reviewed dispassionately, tuned, and reported.
  2. Repeatability & Predictability: As in most endeavors, practice makes perfect. The more releases, iterations, or other cycles a team executes, the more efficient that team can become, the closer estimates will align with reality, and the more the process itself can be tuned. With each cycle comes a new set of technical challenges. Procedural challenges should trend toward zero.
  3. Visibility & Transparency: One of the fundamentals of forging a team from a group of individuals is providing them with a fully connected view of the broader scope. Up a level, the Engineering department is a member of a team of departments many of which include direct stakeholders. A good process enables a comprehensible view to its inner workings and the impact of external forces, without which accountability will be a scarce resource.
  4. Decision Context: An urgent customer requirement comes in from left field. Can it be accommodated and what may be impacted (e.g., the release date, other tasks, which ones, etc.)? A good process provides a well-understood context for making hard choices without resorting to throwing food. Not everyone may leave happy, but everyone understands how the decision was made, why it was made, and the benefits and costs it carries.
  5. Comprehensibility: The team can’t execute what it can’t understand and none of these objectives will be realized if team members are following significantly different interpretations. The simpler the process, the more likely its compliance will be true to its intent. Furthermore, staff changes are inevitable. Shorter learning curves yield faster capacity availability.

Notice that I omitted rate of delivery and quality.  Clearly these are factors we all endeavor to maximize.  I would argue, however, that to achieve and sustain these without the foregoing is like trying to speed up a poker game by not looking at your cards.

Potential Pathologies

Processes can turn pathological; conditions where even good qualities are accidentally subverted by being out of balance with other important factors.  Even the most well-meaning process practitioners can find themselves spiraling down the rabbit hole.  Here are a few of my favorites.

  1. Responsibility Transference: Now that we have a process, why burden ourselves with common sense? Processes are like any other system with many moving parts; they need to be initially debugged and then tuned over time. They should never be assumed to be so perfect that the brains of the participants can be disabled. This is like blindly coding to a specification even when errors are suspected assuming that the spec writers must have known what they were doing.
  2. Rigor Mortis: Can’t – move – process – not – letting me. When the house is on fire, don’t wait for a ruling on procedure; just grab a hose. There’s a fine line between adhering to the process and elevating it beyond the product. The process is a tool to meet objectives; it is not the objective in and of itself. Similar to the previous, there are times when common sense really does need to prevail with a logjam review to follow.
  3. Exception Domination: An estimated 60-70% of most source code goes to handling exceptions leaving the minority for primary functionality. An SDLC process rarely anticipates every odd circumstance. If it does, it probably has so many paths as to be incomprehensible to those trying to execute it. Unlike CPU-executed software, missing process paths are a good tradeoff for simplicity. Human collaboration can fill in the gaps.
  4. Illusion of Competence: Certifications such as ISO-9000 and SEI-CMM can be useful when properly applied. Their principles embody years of best practices and refinements. However, these are process certifications, not product certifications. A software development shop can be CMM Level-5 and still produce junk. It is not uncommon, for example, to find offshore shops touting these credentials having only been in business for a year – run for the hills. These are cases where more energy is spent looking like a world-class operation rather than being one.
  5. Numerous Definitions of Done: Is it done? Yes; well, except for testing. Is it done? Yes; um, it just needs to be reviewed and there’s that other thing. Is it done? Yes. Great, so the press release can go out? Well, no it’s being held back a release so we can stress test it some more. The use of the word “done” should be outlawed until its unambiguous definition is signed up for in blood by every member of the team. I have a theory that more project management frustration stems from the misuse of this word than any other singular cause. Done is definitely a 4-letter word.


Process, good.  Process plus people using their brains and talking to each other, better.  Done.