Technology

Broken Field Running

lean and agile

Now that we’re in the thick of another US college football season, it occurs to me that IT application developers might benefit from having a different mental model to represent the work they do.

Process, Projects and Customers: The Unholy Trinity

lean and agile

One of the statements I regularly hear from IT developers that always surprises me is the assertion that: “Our customers dictate our process to us.”

I’m even further astonished when I hear developers justify this position by quoting an alleged lean principle to the effect that “if our customer is not willing to pay for something [an activity or interim deliverable], then it is waste, and should be eliminated.”

Really…?

An Agile Acid Test

lean and agile

One of the problems with Agile Software Development is the lack of any rigorous tool or method for determining any given project’s agility. To some extent, this can be considered a “feature” of Agile (and not a bug) since one of the core [Agile values][agile-manifesto] is a preference for “individuals and interactions over processes and tools.” At the same time, when managing a large-scale agile deployment at an organizational level, or providing consulting help to a number of different teams, there arises a legitimate need to distinguish between projects that can be fairly classified as Agile vs. others that may only be aspiring to this state.

CMMI Take 2

process improvement

I received a fair amount of feedback on my last post about the CMMI® — all of which I very much appreciated — and I thought I would take another run at this subject in order to clarify some of my thoughts in this area.

Let me break this down a little differently than I did last time, and talk about five different areas.

1. The Content of the CMMI

My Position on the CMMI

process improvement

As someone engaged in software development process improvement, I often get challenged, directly or indirectly, to state my position on the Capability Maturity Model® Integration, otherwise known as the CMMI®. While this is a complex subject, and an emotional one for many, I think it is worth addressing. So here goes.

The Watery Ketchup Stops Here

organizational change

Entrepreneurs sometimes get a bad rap.

Anybody recognize this gentleman?

A few years before the iPod, he developed and marketed a portable computer about the size and heft of a sewing machine, and sold it under his own name. It ran what was then the most popular operating system for home computers, and came with a slew of software, including a Basic compiler from what was then a relatively small startup in the great Northwest.

Take the Agile Train

I noticed this week that jazz trumpeter and composer Wynton Marsalis was awarded an honorary Doctor of Music degree from Harvard University.

Wynton Marsalis

This got me thinking about some of the notable messages from his and Geoffrey Ward’s recent book Moving to Higher Ground: How Jazz Can Change Your Life.

The Requirements Problem

requirements

One of the great myths of software development is that we can ask our customers to give us their requirements, that they will write them down for us, and we can then successfully build software based on those documents.

Watts Humphrey, the father of the Software CMM, puts it this way, in his seminal work, Managing the Software Process:

The 12 Secrets to Application Development Nirvana

software development

As I wing my way back to Seattle, returning from an IT conference in Las Vegas, I find myself reflecting, not on all the latest and greatest IT trends that were discussed over the past week, but on some of the basics I’ve learned during several decades in applications development. Although these practices manifest themselves differently at different times, as technologies and methodology movements come and go, they seem to me to have remained fundamentally constant over all these many years.

So here it is: my 12-Step Program to App Dev Nirvana.

The Process Prescription Polarity

process improvement

I talked in a recent post about the concepts of Polarity Management and what I called the Progress Polarity.

Another polarity often encountered in Software Process Improvement is what might be called that of Process Prescription. In other words:

Search

Blogroll