Derail?

So what is the cause? Again, the miracle really didn’t occur.
In agile transformations, we have noted that one pebble can derail the process. Think of a big round rock at the top of a hill. The rock is the transformation. The hill is the organization. It takes an amount of effort to begin to move the rock down the hill to start with, but one you over come the transition from potential to kinetic and get it rolling, usually momentum will take over and the process will continue to flow. However, to be successful, we must continually sweep the path like the sweepers on a curling team. What we find is that if our rolling rock of change hits even the littlest pebble remaining on the path it will deflect off the path and the transformation will at best continue forward but with an unknown trajectory.

Acknowledging that it is far easier to derail the transformation than it is to instantiate and maintain, what can we do to increase and maintain our probability of success?

Change Agent

I have been a change agent and a process consultant and I have stood before well-dressed executives and stated clearly and with conviction: If you achieve this goal state, all forms of frankincense and myrrh will come to you. And they have believed me.

The cost to paint the As-Is was low – it is a paint by number. The cost to portray the To-Be vision was higher – we consultants are paid for our insight and experience. The expense to connect these dots is exorbitant, not because it is where the money would be made, but because it also required that certain guarantees could be stated: principally that the transformation could happen. Business Process Reengineering always seemed to happen, but unfortunately the To-Be never seemed to achieve its promise to anyone other than the consultancy. They made their margin and then some, but few clients ever really reached their desired outcomes.

Itsa Miracle!

We so desperately like to focus on the As Is – To Be transformation that we minimize the piece in the middle, the actual transformation. The current situation is manifest through its problems and through its inability to allow the organizations to achieve the goals set out for them by their management. It is often easy and straight forward to speak the To-Be – the transformed state. We look at our problems and imagine them solved, simply and directly, and there we are. Indeed, many a consultancy has prided themselves on the speed through which they can identify the exact resultant state to which the client should aspire and change. Unfortunately, the rub is that, when asked, the aforementioned miracle rarely happens.

Ch-ch-changes

What if everything you assumed about how and why organizations worked was wrong?

What if everything you knew about how and why organizations transformed was also wrong?

Hybrid matrix approach can take the best of both flat and hierarchical and perhaps leave out the worst

This approach can produce a self sustaining nurturing organization that is both self healing and strongly mentoring supporting both rebuilding and strong growth environments.

The agile hybrid is established by the creation of a matrix organization where there is a flat discipline-based groups that are loosely structured on “guilds”. Instead of a manager for the group, you have a Guild Master who is responsible for the technical competence of the individuals in the group (specifically their hiring and maturation as technical gurus). The masters ‘review’ all of the individuals in their team, even though there may be well over 10. They do this by outsourcing the responsibility of 360 degree reviews to the projects that the individuals worked on. In an agile organization, this becomes an ideal model because you match the review cycle to the release cycle and do the reviews every quarter.

Projects in this type of organization become the verticals and they have full time masters of their own – project managers (scrum masters with delivery responsibility) and product owners. As part of the project chartering activity, a team is derived and then shopped to the guilds for fulfillment. When there are conflicts in desired talents or capacities, a portfolio manager will be needed to adjudicate disputes. The product and product managers are responsible for the day to day operations of the project and though the people assigned are not really part of the project, they report to the projects for the duration of their assignments. There is no multi-tasking between project as this dilutes the effort even worse than trying to get organizational managers to do real work.

This third model allows a minimization of overhead in the organization and a maximization of skill-based throughput. There is still a degree of finesse necessary to manage and maintain the organization. One interesting point is that the guild masters are typically the most technically advanced people in the org and yet they do not actively work on any project. Their success is the creation of journeymen who are every bit as good as they are and who can do the work with the level of expertise that reflects the guild master, yet giving the master more reach by extending his capacities. If the master’s 2nds are not operating in the same order of magnitude, the guild masters are not doing their job and the organization will never be able to scale.

More on Guilds

OK, great. Whatever. Even in BF Skinner’s Walden Two, neither society nor society are this open. This is a great ideal, but it dissolves the corporate veil. The organization exists to serve it’s constituents and in most organizations, guidelines, guardrails, and limits are placed. OK. So how do we reign this in and still be true to the vision?

A flat organization is managed as a guild based organization. Guilds are mean cruel and archaic structures. They rose to power in the medieval era and are alternatively seen as the epitome of Adam Smith and Karl Marx. It is argued that guilds stifled trade, inhibited innovation, and distorted the distribution of wealth; or completely the opposite. In fact, all craft guilds pursued pious goals. In addition to the regulations governing their crafts, guilds were both benevolent and religious societies governed by strict rules for mutual aid, arbitration and the procuring of spiritual benefits*.

Even granted the separation of Church and State and there is much that we can take from the guilds. There is also much we can leave. There are also some things that rise from the operation of guilds that is worth noting, but only so that we can recognize bad behaviors and nip them in the bud. One such behavior is the way guild masters both poached promising upstarts and colluded against others masters in the same guild**. So, leaving out organized religion and collusion and some other practices that were frankly reproachable, what do we actually have left that is not so left of center that we end up with technical communes (though these may actually not be a bad idea – think Semler***)?

The guilds saw achievement of mastery in their craft as a means of achieving piety. In the Medieval eras the piety was to a deity. Though much has been written in western literature about the Christian based guilds, the Eastern religions used the same construct and organization. If we translate the piety into reverence to a product or technology vision instead, we immediately have a solid relationship to our businesses.



* Gary Richardson, “Craft Guilds and Christianity” and Sylvia Thrupp, “The Merchant Class of Medieval London”

** From Craft and Christianity, p155:
As long as the masters maintained a solid front, all of them profited from the pact. Journeymen were forced to accept lower wages. Journeymen had few other options. But, masters had trouble maintaining the pact. Collusion was in the collective interest of all masters but not in the personal interest of an individual master. One of the masters – perhaps bit smarter or greedier than the others – would realize he could cheat his colleagues just as he could cheat his subordinates. After the other masters had lowered wages, he could offer remuneration or working conditions slightly more attractive than the collusive level and hire the most talented journeymen. His shop would be productive and profitable. Other masters would observe his success, and then try to outbid him for the worthiest workers. Bidding would escalate until the cabal broke down and wages returned to the market clearing level. In other words, the masters could not carry out their self-serving plot unless they could (a) determine who was adhering to the pact and who was not and (b) reward the former or punish the later, so that all masters had an incentive to maintain the cartel.

*** Ricardo Semler – See his books Maverick or The 7 Day Weekend.

Flat organizations tend to be more skilled and more able to foster innovation

But flat Organizations rely heavily on srong self-motivated and self-regulating individuals – basically a primadonna culture.

If an organization has one level – i.e. it has a flat organizational model, individuals use capability to distinguish themselves. They become more adept at focusing on developing their skills and advertising their capabilities, giving them (at least the successful ones) more clear stature in the company and industry. For companies that require innovation and the circulation of new ideas in their product development operations, this enhances their competitiveness in the market. Additionally, since one’s prestige and stature in the organization becomes driven by their skills, capabilities, and the advertisement of this both internally and externally; these organizations tend to be able to recruit considerable top-notch talent.

Equally, flat organizations are harder to oversee and more complex to maneuver through. They require a broader approach to management as well as a lighter touch so as to not stifle creativity. In a flat organization, the only way to keep a control on direction and activity is through mutual respect and alignment to a common vision. Otherwise, pockets will develop that may have fascinating results, but dissipated strength and local optima will develop. If these are neither harvested nor eliminated, precious resources will be spent without furthering achievement towards the organizational objective. In a research based organization, this is ideal as it allows the individuals (or teams) to explore venues through to their natural conclusion. DEKA’s production of the Segway is a great example of this

Management in a flat organization needs to be done with thorough peer review and mentorship. Everyone, regardless of their seniority should either choose or be assigned a mentor. As individuals gain capability, they may choose their way through continuous learning with different masters – stay with each mentor long enough to gain what they feel as their appropriate level of awareness in a field. As people excel in one direction or another, it is the role of the mentor to encourage the individual to stay with the discipline and continue their journey. Frequently, people will make poor decisions in other’s eyes, but as soon as fences are constructed, hypocrisy becomes established.

Hierarchical organizations are recursive and lead to command and control behaviors

This is certainly not my first choice for a transforming agile company.

In a hierarchical organization, small groups tend to be calved off the larger organization until there is an entire tree structure of pods of people with like backgrounds and objectives. Modern management theory suggests that one person can adequately control/manage no more than 10 individuals, so for larger organizations, trees are built such that each has about 10 people and an manager, who is themselves an individual in someone else’s group.

These pods are typically like talents because the approach to management has evolved to be a high touch interface where the manager has frequent interaction with the direct reports or both status and planning of both their activities and their growth (we must note that growth usually takes a back seat unless the individuals do it on their own. Given the high touch, it is equally unrealistic for the organization to assume that the individual will participate much in actual work. Granted this, we tend to note about a 25% drop in productivity for every level of hierarchy that a manager has to manage – A first line manager will have a maximum throughput of 75%, second line: 56%, and so on. After this, it is really silly to expect that a manager will really be able to be productive at anything other than management or control.

Based upon this, it is clear that the flatter the organization and the stronger your self organization and management capability is the more productive you will be as an organization. When you couple the fact that managers tend to make more than their staff, and 3rd line and above do not do productive work, becomes clear that you lose economical edge to the flatter org as well.

Organizational Changes: from Command for Control to Agile

Most organizations tend to adopt a standard hierarchical organization structure. This is one where there is a CEO who has an executive leadership team reporting to him, each individual on that team themselves have a duplicate of this structure for their teams and so on down to the bottom. In addition, there is typically another set of structures for project within programs within product lines, all recursively reflecting the structure. Regardless of the goals and the objectives of the organizations, or the products that they build, the goal of most individuals in these organizational pyramids is to rise to the top so that they can jump off into the next level. Imagine, if you will, any large organization being an inverse Mario Brothers dungeon – with perils increasing as you jump up, from level to level rather than the reverse (but the same theme music blaring in your ears as you run!).

People in the organization are subsumed by this goal – that of reaching the pinnacle, assuming that the princess is there somewhere – rather than achieving the goal of product or project release. Basically, their goals and the corporation’s goals are not aligned. Those that have wanted to innovate or create or even release have left to go other places where it is easier. Those who are interested in accession have remained. I find it mildly humorous the number of principals in the organization who will state that their desire is to become a manager, even though they dislike dealing with people and would prefer to contribute more “wholesomely”.

Clearly, an alternative is to eliminate the prize at the top of the pyramid. That is hard, because America and its capitalism is all about the rewards of the powerful. But, once we acknowledge that this is what we are all about, we can basically help people find power in niches in which they both excel and that align with the overt goals of the organization. Reward people for contributing rather than only managing. Create an organization where power is represented through disciplinary leaders rather than controlling directors.

OK, so let’s recognize the differences between organizational structure options and then define a hybrid that works here.

Where to go next

The objective would be to eliminate the friction between the organizational layers so as to remove as many of the pebbles as possible. The two changes I would make first and foremost would be aligning the organization reporting structure to the agile values of the division with the elimination of the command and control hierarchy that we currently rely on and second the establishment of an agile portfolio management structure to emphasize the concepts of transparency and eliminate the perceived need for the current task forces with their attempt to “drive” projects to completion by the perennial death marches.

Post Sisyphus

Another analogy worth thinking about here is that of a rock (a really large one) rolling down hill. If that rock is our agile transformation, its momentum is what we are most interested in. At the beginning, it was standing still, stuck in the dirt on the top of the hill. It took a considerable force to get it unstuck and moving (in the right direction); however, once it was, common wisdom suggests that it is not easily stopped. Unfortunately, the reality of the situation is that it actually takes fairly little to derail the change. Imagine, as our rock is rolling down, picking up more and more speed (and therefore momentum), it hits a little pebble. Depending upon the momentum we have at the time, the three possibilities are:

1. Our rock stops, lodged on the pebble
2. We roll right over it as if it was not there
   
3. We hit the pebble and go bounding off course
   

What happens in each individual case is completely dependent upon the momentum the transformation has achieved at the time hit hits the bump – too little and we stop altogether; more than enough (the process is well institutionalized) and we pay no notice to it; everywhere in between and the unpredictable (and unpleasant) happens.

Most organizations undertake transformation as result of unacceptable performance. Rarely can you justify perturbing a machine that is adequately delivering ‘stuff’, so it follows that for anyone undertaking a transformation there are enough issues that arise so that their rocks appear to be rolling through a bed of gravel. My strenuous recommendation at this point is to first push for organizational alignment between the layers as that tends to reduce or eliminate most of the immediate irritants and will allow us to purge the resentment and re-establish trust from individuals and create teams. From there, regaining momentum on the transformation will be much simpler and indeed internalization of the agile methods at both the operational and the organizational levels will dramatically increase throughput of the teams and collaboration between the teams in all of your ‘current flows’

Phase and Harmony

In most organizations, the teams themselves are functioning relatively well as agile entities. They have the overall concepts and practices understood and internalized. Every iteration, they go through a number of motions following the patterns they have been taught. Unfortunately, they also carry a degree of cynicism that permeates their activities, some more than others. Mostly, this cynicism rises from the desire to bring about changes we (the individuals on the teams) feel need to happen in order to optimize our efforts. I have seen indication that attempts had been made initially but since the desired actions were felt to be outside of the individual spheres of influence, the they have given up trying to achieve the change and, worse yet, believing that the organization’s desire for change is only lip-service.

Basically, the teams have tentatively pushed out of their flow and into that of the enterprise above them and some of those irritating turbulent eddies have formed. There seems to be little attempt to understand the irritants in the next higher flow and so a defeatism has developed and fostered the cynicism. The result here is that the teams go through the motions with the agile approach, but no one is really embracing it as a way of doing work. Evidence of this is the total disinterest in improving their execution of the art, the value of transparency and the unwillingness to seek goal alignment between products and organization. Instead a resentment has been born between one group and the next as well between one layer and the next. From this dysfunction, mistrust becomes more and more entrenched and it becomes impossible to reach phase and harmony, forcing the teams to always operate well below their potential.

To add to this, the resentment tends to be redirected towards the change undertaken and redirected towards agile methods themselves. Since titles and responsibilities tend to be changed without specific care given to the roles themselves, middle management feels as if much of their power and ability to affect direction has been lost. Rather than retrenching and establishing leadership from mutual respect, most of the folks again tend to rely on position and title to direct the actions of their teams and people. Clearly a left over command and control trait, but it is one that seems to be more well respected by senior management (the next flow up) than the collaborative structures that we try to base the methodology on.

Your Agile transformation is stuck

An associate of mine also in the transformation field noted that agile transformations are extremely fragile. Truth be told, all transformations are fragile, but agile ones appear more so because we celebrate collaboration and transparency and so everyone’s contribution becomes more obvious and the collective’s progress more clearly visible – or not.

Any transformation relies on establishing sufficient momentum under the new processes so that the level of effort needed by the teams to keep them moving becomes minimal and sustainable. Once organizations get over the initial hump of learning, they should become fueled by the benefits: energy put in to use the new approach is dwarfed by the value received from using it. At least this is what we hope and expect will happen.

Occasionally, the change agent gets it all wrong and the local culture will not sustain the new methodology. More frequently the methodology used at one level of the organization is enough out of phase with the governance of the organization and the resulting discord does not allow the new methodology to ‘adhere’. A good analogy here are the stratified layers in any moving currents, such as layers of water or air. Wholly within the current the flow is smooth, but where the layers touch, there is a fair amount of turbulence. Indeed, experimenting with water or air where the different currents are colored shows that whenever a random stray from one flow gets ’loose,’ eddies form infectious pockets of turbulence that swell, fester, and eventually dissipate – but only after the currents in that area are well disturbed.

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!