The Path Less Traveled

by Robert Frost – another part time NHerite, just like me!

Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth.

Then took the other, as just as fair,
And having perhaps the better claim,
Because it was grassy and wanted wear;
Though as for that the passing there
Had worn them really about the same.

And both that morning equally lay
In leaves no step had trodden black.
Oh, I kept the first for another day!
Yet knowing how way leads on to way,
I doubted if I should ever come back.

I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I --
I took the one less traveled by,
And that has made all the difference.

In Tom DeMarco’s book “Deadline” he tells the tale of a kidnapped Program Manager, and interesting tale, but a tale none the less. In it, the protagonist is given the opportunity to run a project multiple times simultaneously. Nowhere but in a novel do you get to travel both paths. Indeed, it is hard except in a poem to take the path less traveled because of the nuances and the mores of the establishment.

Agile used to be the path less traveled. Many individuals and groups can attest to the difficulties in breaking from established patterns sufficiently to try a new methodology and others can tell you how easy it is/was to ground a transformation in mid-flight. Never the less, ultimately it will be the agile path that makes all the difference.

What does Done Mean?

What does Done mean?

Yesterday in the parking lot two related questions were asked and I offered to give an answer that would relate them. The questions were What does “Done” mean? and What constitutes potentially shippable code?

First, let me address the easy one: What does “Done” mean?

Well, the literalist in me wants to point out that “done” is merely the past participle of the verb to do, and as such indicates the completed action of the active verb. Dictionary.com defines “done” nicely as accomplished. When we consider “done” in relation to our development efforts, there is really only one way to define it: No milestone has been accomplished until the product owner acknowledges it as such.

Since the Product Owner is responsible for the creation of any particular story, only they can determine whether or not their intent has been accomplished. Procedurally, we drive to eliminate a bulk of the subjectivity by defining acceptance criteria while we write the initial story. This approach is consistent with TDDevelopment as it concretely defines the finish line for the team before they start.

Potentially Shippable refers to a state of the system from whence it is actually presentable for General Availability (GA). Clearly there are a bunch of details that need to be completed in order to move stories from “done” as accepted by product owners to GA and accessible to external customers. Examples of these details are the compilation of printer ready pdfs from completed user documents – clearly this needs to be done once all the documentation updates are “done”, but before the product can be considered shippable.

Often, teams utilize one or more hardening sprints during which these final details are completed and while system level performance testing and training can be undertaken. Additionally, during these hardening sprints, the teams are able to address lingering issues such as defects that have not been completed or even take on a couple additional stories, as long as all changes are staged prior to being integrated into the release candidate.

So, granting these definitions, teams frequently have difficulty in applying the abstracts concretely to their projects. Specifically, what are we talking about?

1) High level stories are written by the PMs. These are narratives that walk the reader through a scenario that is obviously testable: when a scenario is run, a predetermine result can be perceived. Depending upon the complexity of this story it may be broken down into more manageable chunks, each with their own results based acceptance criteria. When the work is verified, it is verified at the lowest level – typically a task of 1-3 days duration. When the work is validated, it is validated at the highest level – typically the larger story’s scenario. The theory here is that if all the low level pieces are verified and the story can be validated at the abstract level, then by induction all is complete.

2) Similarly if we are going to verify at the lowest level, we must ensure that we have all the component packages identified at the task level so that the work it self can be inclusive. If we need end-user documentation for a particular high-level story, then there should be stories and tasks associated that cover these activities. If we have an end-user, we need to incorporate useability stories and tasks. Ideally, a check-list should be created to help the teams ensure they have included tasks which cover the entire spectrum of activities that are necessary. There is a caveat however; the spectrum of activities must correspond directly with the acceptance criteria put forward by the PM when the story was initially written. If they don’t feel a certain aspect needs to be incorporate, then don’t. On the other hand, if the team really feels it does, they should initiate a dialog with PM to determine whether they have discovered an omission, purposeful or not.

Thus, Done means the stories are verified by QA against their acceptance criteria and there are no lapses. Potentially Shippable means that all high level stories are validated by the PMs and demonstrable to the organization as complete.

Tying Release Planning to the Critical Chain

Another conversation with my friend Tom Looy caused me to start thinking about project networks and how they relate to Release Planning. A project network is a construct of tasks or work products (which are groups of tasks) that link together to form a mathematical graph representing a logistical map of the project. Ok, what does this really mean and how do MMFs and IFMs work in to this (as you know they must or I would not have brought them up!)

Well, first a bit of background – a project network is used to identify a project’s Critical Chain. As initially defined by Eli Goldratt, a project’s critical chain is its manifestation of the Rope from the Theory of Constraints’ Drum-Buffer-Rope concept. It is what is tying all the operations centers together with their dependencies and precedences such that the “right thing” will pop out the back when the project is over.

In most undertakings where TOC or CCPM are utilized, the “right thing” is pretty well defined. In many of the projects where agile methods are used, the “right thing” is generally understood, but not defined. However, there are a couple of valuable things we can take from the project network, if we can figure out how to integrate it into our concept of Agile Planning. First, we get the concept of buffers for our schedules. The buffers provide us with the ability to project out our actual releases early on in the planning and give us some flexibility in statistically committing to firm dates. Second, we get the actual critical chain. The critical chain is valuable because it focuses us on everything we need to do to achieve the objective we are setting out with, it also offers us a view of all the dependencies that need to be completed so as to allow us to achieve our real goal. Though this sounds reasonable, it is somewhat striking to suggest because the only way to establish the critical chain is to identify all the tasks we believe we need to accomplish, which is rather antithetical in agile approaches.

True though, when we create a project network what we are actually doing is creating a future reality tree for the project: if the project were completed successfully, we would have …; therefore, in order have that, we need to have … and so on back to “today we start the project by doing …”. Now certainly this does not mean that we need to identify every single action we are going to take. When CCPMers talk of identifying tasks they typically do not mean the same low level tasks we refer to: i.e. those building blocks of stories or features that tend to be chunks of work no more than 1-3 days long. What they refer to are basic components of the project that must be completed to support the implementation of the next level of the tree.

The exercise of creating the tree is more than a planning exercise – it is designed to ensure the important dependents and precedences are identified and understood so that the complete book of work can be defined, the critical chain specified and the constraint(s) illuminated. Once done, ROIs and value props can be determined and project viability understood.

Clearly this is more ‘ahead’ work than we do in an agile project, but consider if you will, the opportunity that we create if we were to take a leaf from this book: During release planning, as part of my chartering exercise, let’s say we create a high level project network. In doing so, I identify a lot more detail about the entire project than I might other wise do. However, I also produce a dependency chart and identify a critical path such that should the customer desire a change later on, we can reference it back to the network and understand what it impacts, and if so, how far back in the tree we need to start accommodating it before it adversely affects the critical chain.

All of a sudden, we can do both cost/value derivations on features as well as put in place an incremental funding model for both features and the project. If I know that “A” is in my set of MMFs, then it is probably also in the critical chain. If my customer asks to reprioritize, deprioritize it or even eliminate it, we can quickly and clearly see how the value proposition for the entire project changes. Equally, if other features are added to or removed from either the project or the set of MMFs we can understand what the impact may be. Once we start seeing the project network as a future reality tree, then the project itself becomes less abstract and more concrete both as an entity and as part of the holistic value stream of the organization.

MMFs and the IFM

There is a concept called minimal marketable features (MMF) popularized by the book Software by Numbers that looks at project/product viability in terms of return on investment. The thinking goes, at a very high level, implement those features that have a high value payback first, get them into production quickly, and they will act as an incremental funding model* for the rest of the program. The difficulty with the model, however, is with getting to critical mass.

For products that are not in new spaces, particularly if they are replacing systems already installed, there must be enough features present to not necessitate running the two systems (old and new) in parallel. For new product, there must be enough features present to make a compelling sales story. In both of these situations, this number is the set of MMF and truth be told it is always smaller than anyone is comfortable admitting to.

Think about MS Word. Hey no! That is unfair, everyone picks on Microsoft and this blog is a Google hosted blog. Let’s pick on Google! Blogspot is a great equalizer. It has allowed every Tom, Dick, and Matt to become published bloggers wherever they want in the world wide blogsphere. That alone has great value to some of us. The html editor here on Blogspot does not have all the features I use on my word processor of choice (MS Word). I can not do foot notes easily, for one. However, I can easily publish a blog that other people can read and where I can store ideas until later without fear of losing them. I can get other folk’s comments on them and do some rudimentary collaborating. These are the highest value features to me. I am actually glad that they did not wait until they had footnotes working before they made this much of the system available to me. And, as you can see, I have found a perfectly viable way of doing foot notes without any additional special editing tools.

If you needed to create a list of the MMFs for a blog editing and posting tool, most of us would have put down a word processing capability. What we really meant was text editing. Using the MMF model, the team could implement text processing capability, gotten the site live, then come back later and upgraded the system to a word processor (or not, maybe it is not actually ever needed).

The one drawback to MMFs that causes them not to be used as much as they should is exactly what they were designed to support. Laying out the MMFs both encourages and enforces some rigor about the value proposition of your features. Often times this is hard to make objective. Think about Blogspot again. If their goal was to corner the market on bloggers, what would be the most important feature? It actually is not any of the functional features of the site, but rather the ease and cost of entry into the entire concept. In the early days of blogging, you had to both buy blog software and sign up with a hosting entity upon which you could blog. This took money and commitment. Now, on blogspot, it takes seconds to create a blog and thusly the ease is high and the cost is zero. There are now literally millions of blogs out there that get started and never updated because it is free and simple to initiate.

I wonder, though, did anyone sit down and define the value to the organization of this feature? Monetization of Blogspot is similar to the rest of Google – ad revenue. If there are Billions of blogs that are never updated and consequently never looked at, their ad revenue is going to be negligible, but they still take disk space and infrastructure. Thus, ease of entry allows them to capture the market, but it may also have a negative impact on the organizations costs. These intangibles are much harder to equate to specific numbers and so quite challenging to integrate into the MMF model.

In the early days, before Google bought Blogspot, you can imagine the strategy sessions they might have had**:
“We need to take a commanding percentage of the consumer blog market. If we do, we will further our cause for blogs for the proletariat and creation of a world wide stage for every closet politician and every person of strong moral position.”
“True to that! Therefore the most important feature must be ease of initiation closely followed by a simple approach to rubbernecking on other people’s blogs so that inherent curiosity will keep people on the Blogspot site for longer and longer visits!”
“Guys, wait!”
“We will also need to keep it simple so that the common man can use it without a lot of training or documentation.”
“Without doubt, cause I hate writing documentation!”
“Guys, wait, listen!”
“What….”
“Yeah, what?”
“If everyone signs up and everyone uses this, how are we going to create enough space for them? Where are we going to put them? I only have this one server here….”
Silence.
More Silence.
“I know, if we get it up and running fast enough and take enough of the market quickly enough, someone big will become worried and will buy us to make sure they are in the market before someone else buys us. It can be their problem!”
“Great. Ease of use and Low cost of entry! Get as many people to sign up as fast as possible and demonstrate potential and hope Scotty here can hold her together long enough!”







* I love footnotes. I wish the blog software would support them though! The increment funding model is basically an accountant friendly approach to undertaking a project whose stakeholders know how important it is, but can not necessarily express it with discrete numbers. At a basic level, it says “spot me some cash and I will show you some value. As we progress towards our final product, I am happy to take little bits of funding at a time”. It is hard to do long term planning in this way, but the idea is that you will win your CFO’s heart (and pocket book with the healthy returns) and he will release the grip he has on the purse. This is a common model for startup funding.

** This is all fiction. I have never talked to the Blogspot guys, I am only imaging what might have happened in their executive offices.

Release Planning

While using agile methods, we advocate defining a vision for the project that will align everyone and help them focus on the right underlying concepts and point them towards a shared product vision. This product vision is championed by the product owner and defines the “right thing”. When done right, we don’t need to define the vision in great detail, because everyone on the team understands* what is being targeted. The high level plan is then: develop towards the goal – undertaking only what is needed to realize the goal state, but remaining flexible enough to tune our progress as we better understand convergence towards the PO’s vision.

The draw back to this comes in the form of a question I hear far too often: How will I know when we will be done? Planning a release is critical for most organizations. There are always many costs and impacts that will are borne by tangential or ancillary groups within and without the organizations actually doing the development. These must be both planned and budgeted and can’t be taken lightly. The failure of many projects can be traced purely to the inability to integrate them into an operational environment, which can’t be done without planning and scheduling.

So, how do we ensure success? Clearly, it is simple if we timebox the release. When we get close to the end of the timebox, we move the sprints from releaseable to release and ensure that whatever we have done is hardened enough to go into production. However, how do we do it when there is a minimum number of features that need to be complete in order to create a viable release? That is a great question!




* Quick test for your team – ask any two people for their 30 second understanding of the vision / goal for the project. If the two elevator pitches agree, your team is spot on and your PO has done their job well; if not …. my guess is that you will also have problems achieving “done” on the project.

on Mura, Muri, and Muda

(specifically, from Jim Womack’s e-letter )

My first reaction is that he is pretty much right on, particularly since his name is Womack.
Second reaction is to suggest that there would have been a much simpler way to come to the same conclusion, 20 years ago as well. (much simpler way)

Remember our favorite equation: P=T-OE (from Goldratt's Theory of Constraints in the Goal). You can drive OE to its limit (0), but that causes P to reach a max at T. If we assume that the effort is spent driving OE to 0, then we probably do not have cycles to increase T at the same time. Therefore, P's max value becomes T.

Comparing to the 3Ms, driving OE to its limit is the same as eliminating waste. Most of what everyone sees as "waste" falls in the OE category and so, it makes sense. Eliminating waste therefore logically stagnates profit at what ever level the organization optimally can achieve given whatever its throughput currently is. To release frozen capacity for profit (my new byline, I think), ignore the Muda, focus on increasing the Throughput. Mura and Muri, in their combination, are the constraints of the system. True, you can't optimize the organization by focusing on the T alone, you must address unnecessary OE, but focus first on the other two and once they are converging where you want them to, you will have plenty of time to focus on Muda.

And besides, any parent knows, muda always happens last.

April Fool's ........ Not!

In an interesting flip, where as we always look at the world from a US centric point of view (IT or otherwise), with the fall of the value of the dollar around the world, there are many places with higher costs of living than the US. Check this out: Harvy-Nash Survey (use the link to download the survey - the tell-tale graph is on page 24). In case the link goes stale or you don't want to bother downloading the whole document, what it says is:

Figure 29. Top ten offshore destinations

1. India
2. China
3. USA
4. Malaysia
5. Brazil
6. Philippines
7. Vietnam
8. Poland
9. Romania
10. South Africa

India dominates the offshore league table for another year, capturing over half the market for offshore services of the respondents to the Harvey Nash survey. China and the USA are now very evenly matched in the eyes of the survey respondents but South Africa drops from fourth favoured destination last year to tenth this year. Canada drops just outside the top ten to 11th after occupying the fifth spot last year. Vietnam continues to perform strongly, maintaining 7th spot amongst much larger and more established outsourcing peers.

We may be the next decade’s Vietnam!