Software Project Management and Agility, Agility. Of course.

PMI has a term for it:

Progressive Elaboration

MSF, Martin Fowler (this guy is amazing), and XP have a term for it:

Continuous Integration

George has a term for it:

Iterative Refinement

It reduces Risk!

It prevents Scope Creep!

It keeps your application fresh!

It is a license to toss BUF requirements!

It makes User Stories a viable alternative to Use Cases!

It obviates the antiquity of the conceptual Waterfall Lifecycle!

What is it? Well, there are three names for it above. What’s so complicated? We have the terminology… we have some of the benefits… it is clear that something very distinct is rue:

Project Managers are Ninjas of the IT world. They are the herders of cats, the keepers of the wind, and the snake oil salesmen that transfix small camps of people.

These terms are a way of describing the obvious; a project at inception is not the same project at delivery. In fact, the need is often not known until the solution is explored.

I am reminded of the law which states that you cannot observe a thing without affecting that thing. I am reminded of Pandora, and her box. I think it inevitable that in order to prove it’s own validity, any discipline will attempt to wrap it’s tenets in terms that roll off of your tongue as naturally as a drip of drool as you stare at The Delicious Answer. It is enticing, no? Progressive Elaboration. Iterative Refinement. Continuous Integration.

We’ll figure this stuff out as we go, because we can’t do it all now. Doesn’t even make sense to try.

Indeed, as projects unfold, the initial scope and even specifications will morph into something else. You’ll have iterations, Scope Change Request or simply Scope Changes. There will be pieces of javascript left dangling until someone sweeps them away. There are a variety of forces acting on your embryonic solution. There are people: people with opinions, and titles like Chief Operations Officer or Lead Architect or Doctor. There are technological issues, such as compatibility or expense. These are generally the elements of the classic Tripe Constraint. It all boils down to:

Time

Scope

Cost

At least, that’s the way it is generally presented. I have issues with codification of the dynamic - but it is more a philosophical one than a practical one, and we must be practical.

And no matter what you call it, the fact that projects have elements as mercurial as the face of a madman, and facets that shift like the tectonic plates, the fact is that the world is a malleable place, and we cannot herd cats, capture the wind, or disappear in a cloud of smoke. We have to work like a sonuvagun to be reasonably accurate, until we are almost done. We have to draw the target before we can hit it, and f the target is moved, we need to realign. We cannot shift direction at right angles in mid-air, like a UFO. We are required to Progressively Elaborate. Each project is a new land and with each effort we both accomplish the completion of a task and fail to explore an alternative. We Continuously Integrate, because as we go along the world goes along with us and we become aware of where we are and even what we are doing. We gain a momentum, and as scientists discover that photons will scatter in a way they can codify and use as an imaging tool called Ramen Scattering, delving deeper and deeper into the nanoworld, wrapping real phenomenon in ever-changing definitions - Project Managers Progressively Elaborate just like technology and the rest of the world does.

You need a new feature? File a Scope Change Request.

You have exhausted your budget? Get more money, move some money around, expect less, or expect inferior quality.

It’s not so much about the trees as it is about the forest. If you have a forest that you like, the trees are okay.

What I am saying is that among all the ceremonious PHASES and TRACKS and KNOWLEDGE AREAS, there is a fundamental truth; ceremony is created for a reason. When something happens naturally, or according to plan, there is usually a notable lack of ceremony. You can call it the Define Phase - it is figuring out what you are going to build. You can call it Monitoring and Controlling - it is babysitting the build. You can call it Deployment - it is turning the stuff on and making sure it works.

I submit that the execution of an IT project is a succession of discreet steps, named for sake of conversation and generalization. We speak in Universals, but the world is made of particulars. Projects have Phases, but they exist as discreet movements towards an end. Agility allows for this, but isn’t Agility just a way of supporting what we already knew?

We don’t know everything. Definitions change.

Look at the world of real science. First, space was made of ether. We used to have humours in our blood and in the air. The smallest particle of matter was the atom…no wait - the electron… no wait - the quark… no wait - the so on and yet to be so forth…

But do not waste your time thinking about that. You should be studying for your PMP. It is worth money to you, and you need those checkpoints and milestones and exit gates to CYA. As project managers, we have to be able to point towards something that says we know what we are doing. People don’t want to hire you or put you in charge of their projects unless you can demonstrate in some definitive way that you have a good understanding of how to manage a project and make it happen, keep it controlled, deliver with no cataclysmic surprises. You are to be a practioner of the discipline of measured progress, the keeper of the key to delivery and the guide for the blind amorphous beast.

DON’T FORGET TO HAVE A RISK MANAGEMENT PLAN! Wink

When I worked construction, in my early teens (Dad was the company owner, so I worked since I could hold a wrench), all the guys would come to the shop before the sun was up and make sure their trucks were loaded before heading off to their job sites. The overhead doors stayed open - even in the dead of winter - while the same little huddle took place every morning. There was no place to sit in that shop, unless you wanted to get a metal burr in your bum. We stood. In the biting cold. We went over what we needed for the day, where we were going, what issues we anticipated, and swore at each other. It was a brief meeting, to the point, and we did it for a reason.

Minus the coffee and cursing, this was a scrum. Imagine that. It strikes me funny. We didn’t even call it Extreme Construction (XC).

With measured discipline and a good degree of mirthful abandon, you can enjoy corralling the ambiguous need and forging a hard coded solution. You can be an illusionist, making ideas manifest as reality and capturing the wind while defining those very elements that you demonstrate mastery of. It is an awesome thing to do, and it is impossible to be certified in any meaningful way in regard to this. There are tools and there are best practices, but there is also the x factor - and there is no training for that. There is only the ability to change, shift, adjust, and learn. It is a very human thing: Agility.

Best,

Josh

Bookmark and Share

2 Responses to “Software Project Management and Agility, Agility. Of course.”

  1. Josh says:

    This is a bit tongue-in-cheek, so please, no hate mail for the Agile crowd. I’m with you.

    - Josh

  2. H. B. says:

    Cheers again, Josh. I just subscribed to your Atom feed.

    - H.B.

Leave a Reply