I'm in the middle of two writing assignments, besides my day job on a remote site, and my office job (mostly business development). Both are around "agile" topics. One for "agile" Earned Value Management for the PMI Earned Value Management Practice guide and the other "connecting the dots between EV and Agile" for NDIA. I've become aware of an important issue when speaking about agile.
In our domain, being agile requires knowing a lot more about the project than you would in other domains.
I'm going to use a PMI PM Network article as an example. Jesse Fewell writes How Much? He states there are three options for agile efficiency: (1) Just enough, (2) Just in Time, and sometimes, (3) Just Because. It's a good piece, but like all advice in magazines, there is little advice on what domain and context this advice can be applied.
Just Enough
So how do you know how much is "enough?" The answer is likely domain and context sensitive. Is "just enough" documentation testing an upgrade to the Accounts Payable system the same as "just enough" documentation for the testing of an emergency shutdown system to an offshore platform gas compressor? Just enough requires a deep and broad understanding of the problem domain.
Knowing what "just enough" means that you know what "too much" means. "Just enough" is a relative term, requiring a basis of comparison. This means you've had to have seen "too much" and can recognize it when you see it again. This means you've been on projects where there was "too much," and the project that you're on now is "close enough" to the project that had "too much" and you can recognize it as the same domain and context.
Just in Time
Next comes the problem of "just in time." This has a similar "precognition" problem - knowing it before you see it. If I know what is needed "just in time," I likely need to know what comes next if I'm not going to have to spend time developing the next item that I didn't know about, since I only looked forward to the "next" thing.
When teaching in grad school - something all physics majors dread, including me - I was advised by a professor - "you'll do fine in this course, just stay one chapter ahead of the class." Great advise. But there were chapters in the book that could be read ahead. I didn't have to write those chapters. I only had to read them.
So "just in time," requires that the next steps - the book chapters, the training materials, the "road map" is in place, but not yet needed. The development of this "coming soon" material needs to be planned, so when it is needed, it can be put to work "just in time." The JIT concept requires that the replacement inventory - the needed materials - can be provided "on demand" and need not be stocked. But what does this mean to product development and project management? An "on demand" model - one observed by Taiichi Ohno - was the drink dispenser. When the customer wanted a drink, he took one. That drink was then replace by another. What is not discussed in the article is that the replacement drink was already in place, just waiting to "become available."
It's not clear the Agile PM folks have this understanding of JIT, but that is certaintly the underlying principle of JIT at Toyota and anyother place where JIT is used as a principle not just a "buzz word." In the end JIT is a pull paradigm. But pull means there is material to be pulled. The holders of the material, assure the "puller" when a request is made, they can respond. So when we look at the system aspect of a project, we must define our needs in terms of the ability to pull and have that pulled satisfied.
Just Because
The last item in the article is "just because." The example says "I know the 40 page template violates 'just enough documentation'" But how does Jesse know this? Is Jesse an expert in the content in that template? If so, the 40 pages can be assessed as "too much." But what if you're a PM on a new domain project. Or maybe a new context in that domain? How do you know that "too much," is too much?
As an aside, I know of no place where an "open ended" budget is the normal way of doing business. So the notion that I know forecasting the full project cost up-front violates 'just-in-time-planning,' but we're going to do it, just because we won't get funding without it.
Yea, that'd be normal. If it's someone else's money, they probably want to know how much you plan to spend to deliver the outcomes from the project. This statement can't really be the approach proposed for good project management. Incremental funding is the norm in government, but we still have to tell the government what we need for the Total Authorized Budget (TAB). I'd think internal project funding would have the same concern as the government or an external funding source. Open ended budgets seem illogical to me. Why would any "funding source" give a project team a blank check?
The notion of "writing software" for money in a agile environment can't possiblly ignore the concept of Total Allocated Budget. Please tell me this isn't true.
The Fundamental Flaw in Agile Project Management
The article mentiones "road maps," avoiding detailed planning for future activities, planning down to the hourly resources in that future activity. All good generic advice, IIF (if and only if) you know enough about the domain, the context in that domain, and the activities of the project and especially the future, to be able to see with credibility "I can recognize enough and just in time." When I see it.
Otherwise you may be surprised when your "just enough" or "just in time" isn't enough or isn't in time.
Now the article is limited to a page in a general purpose magazine, so Jesse's words are great advice to the reader to establish and orientation to the topic.
So What's the Solution?
When we encounter processes, activities, and situations that are clearly "too much" - Too much planning, too many keyboarding steps, too much documentation - we should take Covey's approach "seek first to understand."
Are these "too much" activities there for a reason? Maybe not the reason you'd come up with. But a reason none the less. Could even be a bad reason.
A core process for process improvement is to "understand" the AS IS environment before proposing the TO BE environment. With this understanding knowing what "just enough" looks like can be a goal.
The solution to "just in time," means you must know what happens after the activities that you want to perform "just in time." This means you must know what comes next in "enough" detail to be assured you've prepared to provide "what comes next" when it becomes "just in time."
In our aerospace and defense world this is called Integrated Master Planning and the associated Integrated Master Schedule. This is described in IMP / IMS Preparation and Use Guide. This of course is not applicable - in detail -to all domains. But the notion of describing the Event, Accomplishment, and Criteria for all the deliverables of the project is applicable to ALL project domains.
This is how you answer the question "how do I know what is enough, what is needed now and what is needed later, and maybe even what do I have to do even though it looks like a waste."
A Final Thought
Isn't Agile Project Management (rather than agile software development) just "doing the right things?" Or more importantly, our Rocky Flats banner says the inverse...
Don't do stupid things on purpose
Of course not doing stupid things on purpose, means you know what stupid things look like. Knowing that double entering time card data has a better solution, might be one. Knowing that planning resources at the task level 8 months from now does not provide any increased visibility into the labor demand. But what if I do need to enter the time numbers three times (OK maybe twice) because the current time card system requires I separate billable from non-billable time. It's dumb but we don't want to invest in a system that fixes this. Or that I really do need to know the names of the people I need 8 months from now. because those people are booked for the next 6 months and they are the only ones on the planet that can do the job.
Try to get into to see a world class knee surgeon for your torn ALC in Vail with a few weeks notice.
It's Domain, Context, deep understanding, experience. Without these, your approach to agile project management following the three rules of the article may be disappointing.
