Hi again,

Some of you know that I have a book deal that I have been very much neglecting the value of due to work and family issues. Projected release of late this year is now *very* late this year. I hope. This is really a good thing, for a variety of reasons. Stay tuned. I know you can’t wait.

Josh Milane

A few years ago I was first exposed to some agile practices. A year and a half or two years ago I had confrontations with agile practitioners as well as exposure to and involvement with agile projects. I even led some, without having bought in. If you look back at my blog posts, as it was pointed out to me today, I didn’t always agree with some agile practices. In fact, I was very much against some of them. I think this makes me a better PM and a better manager, because I can truly see the value in a variety of approaches and can adapt my techniques to suit the client, the team, and the unique project.

It is interesting to me, because I can see how my opinion has changed. It is also embarassing that I did not figure out this earlier: PMI and RUP and MSF and the like are the immediately obvious methodologies with large use bases because they have been productized. They are nice little packages, complete with certification and just happen to work better if you buy this piece of software or join this organization. There is money behind these schools of thought. They have a lot of exposure. Clients have heard of them and I have seen “PMP desired” on job descriptions for shops that practice purely agile techniques. It is as much marketing as anything else. More, maybe. This is not to say that I think they are worthless. Truly. It is just to assert that sometimes answers are obsfucated by things that appear to being clarity. It is funny to me, in an odd way.

This took me some time to realize, some more time to process and struggle with, and then it all just clicked. Project Management is about managing tasks. It is about getting things done. Yes, there is budget and human interaction, but they are all a part of the effort. This stuff is not brain surgery. As much as I love the discipline and am as anal as anyone about the way my projects are run in regard to sticking to an (always custom) method, I recognize that fluidity is mandated, and agility is really more than the name of a kind of SDLC/PLC.

There is ScrumMaster certification, yes. But Scrum <> Agile. It is one form of Agile. It is one possible way to manifest Agile in a way that can be taught from a book (which are available in many titles). There is also ScrumWorks, a nice piece of software that there is a free version of, for a limited time, and then the Danube salespeople start calling.

I guess what I am trying to say is that sometimes, the most elegant and efficient paths are the simplest paths. IT is an industry, and that which supports IT is productized. It is only normal, truly. It just kind of sneaks up on you if you think the answer is out there more than it is within your team.

It is very simple, really, as laid out in the Agile Manifesto (and none of these things cost money):

Individuals and interactions OVER processes and tools

Working software OVER comprehensive documentation

Customer collaboration OVER contract negotiation

Responding to change OVER following a plan

That is, while there is value in the items on the right, we value the items on the left more.

These things simply require commitment, discipline, and quality people who care about what they do and share values. What do you value? What does your Client value? I bet, if it is not the above, it is at least results.

That’s all for today. Thanks for reading.

Best,

Josh

The classic model of inputs and outputs (as taught by PMI and just about every other PM school of thought in regard to larger project phases as opposed to a description of the environment of an SDLC) can be extended and simplified to allow for:

• initial assessment (There are unique and very different artifacts and such available at project “Initiation”.)
• followed by work (This is when people on the team start doing stuff; they can be PMs, BAs, or Developers.)
• followed by recursive directives (“What do we do now, from where we are?”) and stay close to the Agile model of rapid change. This not only allows for iterations (an uninformed iteration is useless,) but also the inclusion of discovery, User Acceptance Testing, or simple change (for instance, someone is hit by a bus). This model asks the PM to not just push forward but to look at what new evidence or information exists and make informed decisions.

Seems a lot like Scrum, I know, but in this scenario the Scrum Master would be better off with a PM background. At least, I can imagine that very useful… and I imagine that in practice, more than a few development shops have transitioned a PM into role of Scrum Master, and that the individual in question just just what is being detailed here.

Ambler’s Agile Unified Process absorbs this quite nicely. A quick glance will show that is is really just structured from a project level, just down to business at a day to day level. It provides the niceties like projected due dates, yet allows for malleability.

Ambler’s AUP:

So what is a directive? A dev task? A POC trial? A call to clarify requirements? Yep. All of those things.

You always have the ability to and should be thinking about what will be useful next in regard to the overall project, but you should also be thinking about recursive directives. We can codify and abstract all day long, but especially in small team environments, this all comes down to people doing stuff.

Best

Josh

User Stories are very alluring to a contemporary PM, because the impulse to break them down into requirements is almost unavoidable and provides immediate meat to sink teeth into. In the more Agile-minded PM’s mind, there is the impulse to break User Stoies down into tasks and estimate against those tasks. You can start off with Context Diagrams or any number of initiation documents, but User Stories are the most flexible and when beginning a task that will require flexibility, this makes sense to me. Previously, I detested the idea of User Stories. I still do, but the key is the context. What kind of Client is it and what kind of project is it?

Each task has an associated total number of hours (estimated, estimated with multiplier, actual, remaining, and others depending on the document). Each task is part of the feature that the User Story will deliver. You add all these task estimates up, and you have your total estimated hours for a given feature. Or so it seems.

On it’s own, this will go to Development and often be addressed task by task. With a traditional Development team, taught to code not with FDD or TDD in mind but instead to just “code”, each feature will be built by building the backend first, then probably the UI, and then the stuff in the middle (for example). It is all of this, then all of that, and then we are done if UAT goes well.

I believe in proof of concept. In the aforementioned routine, it is very possible that it will not be until this feature gets hooked up that some oversight is revealed or an issue rears it’s head. There is the concept of the Tracer Bullet. I did not come up with it. It is really a munitions term. It has been applied to sofware development by a gentleman named Dave Thomas as it relates to the Client engagement, but more academically, an early iteration – a working prototype. The point of iterative development, RAD, RIP, and client-involved JAD is to get feedback and really, have the client actively involved and correct issues before they are too costly to address.

Ideally, we would eliminate all risk of this on paper, through paper prototyping or UML or other (probably Visual) requirements techniques, but the quicker we can get feedback, the quicker we can augment or move forward. It can be very frustrating, especially with truly novel ideas, but this is where passion and development have a lovely and magical time together. Get a passionate Dev on a project with a passionate Client and have a passionate Manager in the middle and there is a really cool synergy that happens. People learn from each other, and they take those lessons with them after the project is over.

Instead of breaking features or functionality down into requirements, and then development tasks, sometimes you can just jump in and do work. This takes a team with good communication skills and a Client with real interest in the project. Formalities and ceremony take up a lot of time. They cost a lot of money. PMI has made a fortune on selling the idea that they are necessary. They are not.

What is necessary is momentum and guidance. If you are going to get from here to there, you have to start moving. Planning is great, but Plans (as in the GANTT prototype) are ephemeral. Software is not construction, though several methodologies have a “Construction” phase – maybe to give a warm fuzzy. Work does actually happen, but people are realizing that with something like software, where you start with nebulous action items, it is important to not assume too much about the Whole, and instead feel your way along as you go. Software is tactile as much as it is cerebral. People have to *use* it. Usage minimizes waste as well, because early feedback is feedback against minimal investment. Get users using the software. See what they say. Take a few well-informed risks (you are paid because you are an expert – remember that and don’t be afraid of it like some are) and let the Client tell you “no” if they don’t like it. At least you will know before the delivery date comes that something is horribly wrong with the way you built the Shopping Cart or whatnot.

Wireframe processes are a neat concept. The difficult part is not succumbing to the urge to fill in the gaps too early. At least, for me, that is the difficult part. I love to deliver. Part of delivering is getting there, but yeah, I really dig delivery.

Best,

Josh

<iteration 1>

The Just-In-Time philosophy minimizes waste. Championed by Toyota, the JIT approach aims to not only optimize process, but simultaneously reveal and strengthen weak links in the chain of process.

Polymorphic Process is something I made up just in time to write this (the phrase, anyhow). I am not sure that it makes sense. However, if you get what I mean, it is good enough and I didn’t think too hard about it. There was no waste here. Most authors would edit as they go. However, this is an exercise in singular iteration. Thereby, it is not an iteration at all. It is polymorphic process, manifested as I began typing or perhaps… as I began thinking that I would write tonight.

But that is not where Polymorphic Process stops. It doesn’t stop. It doesn’t start except for when we choose to call something Initiation. When is Just-In-Time? When are Processes and SubProcesses Initiated in a Polymorphic Process model?

Yeah. Then.

So what does this mean? In software development, you can think in terms of linear progress (and even particular ones, with particular names and certifications and cool initials to put in your Outlook signature), or you can think amorphously. Both will work. One requires faith, like church. The other requires faith, like Atheism.

I love this stuff. Sometimes. When I write these posts, I love it Just-In-Time. I realize that I lack discipline when I go three months without writing. The water in my little ocean has evaporated and the rocks are showing. So I dive in, because what else can you do but get involved, and I employ a polymorphic process.

Awkward endings are part of the game.

</ iteration 1>

Best,

Josh