Tim Bauer’s Running Thoughts

Not a running thoughts post … just a wandering side comment.

I was reviewing Joe Arnold’s post on why product companies, like Yahoo, don’t use CMMI. He raised an interesting point by basically saying CMMI works in operational models but NOT in innovation models. First he talked about the focus/application of CMMI:

“A high CMMI-level rating, while it decreases risk, also has overhead that adds to costs. The higher the level of certainty, the higher the cost.”

Who wants lower risk more than systems in an operational steady state? That is what people who buy based on CMMI rating are looking for. You don’t innovate on your mail server, your financial system, or your CRM app. You want stability with slow evolution on those. Stay at par w/ competitors. But, if you have aspects of technology that drives your competitive advantage, you aren’t looking for stability to be the watchword of how you deliver IT solutions. First and foremost you have to innovate. Joe points out (with Yahoo as his inferred backdrop) that innovation doesn’t come from CMMI … it is smothered:

“Competition [for companies that thrive on innovation] from startups and other internet companies is fierce. Time to market is critical. Persuing a CMMI level that would add any costs to product development isn’t acceptable.”

He then goes on to say how Agile and CMMI can co-exist (olive branch) but leaves on the table that innovation isn’t happening at the same pace in a CMMI shop (not compared to a non-CMMI shop).

All of the above is interesting, to me, in two ways:

1. You Need Dr. Jeckl and Mr. Hyde in Corporate Shops When you look at your operations you really need to think about two types of teams. One, A group of your “Rangers” that live to create innovation where you need it with management models, incentive plans, methodologies, and planning cycles that match that style. Surrounding the “Rangers” are your stable “core” resources. Players incented by stability and rigor with, again, matching methods, incentives, and methodologies. They need to both exist or you will end up being one but not the other.
2. The U.S. role in the global IT market As cost arbitrage continues the US IT worker should look to the role of (1) innovator or (2) lead in partially outsourced “core” apps. Being the innovator (finding the technologies that drive market advantage for the company and aligning with them) is a wiser play over time as full outsourcing of core apps to CMMI players is always an option.

Very interesting. Thanks for the insight Joe.

Paper prototypes … yawn

I know .. however this clip points out … to me .. a valid nuance of paper prototyping … how to be agile in its dissemination. And how to focus what its used for.

In short, by putting some expectation of any process getting a few ‘taping’ artifacts created around it (base flow, 2-3 core exception / design feature flows) I think you position yourself for better uptake by the current and future teams on what you were trying to achieve. People will check the tape. Documentation … if they can’t search for it … forget it.

** START OF RAW SCRIBBLE TAKEN WHILE RUNNING **

– Explaining goal … talking to developer via prototype
– Example of yahoo Brazil site
– Lo Fi (Joe is not a latent artist … at least in his fast scribble [wink]
– Its all in spanish (the prototype)
– He then tests with a Portuguese waitress
– Separate visual design from interaction design
– end (~3m)
** END RAW SCRIBBLE TAKEN WHILE RUNNING **

So I watched this webcast this morning.

Agile Project Management - Reliable Innovation

Recently (last 4 to 5 qtrs) we have been approached by clients that are trying to apply agile in thier environments. With that in mind I am beginning to be more curious on what the ‘pioneers’ in this space are doing.

At a high level I took this away:

1. Agile Doesn’t Mean Agile All the Time It was interesting how the speaker had a variety of points where he made sure to clarify Agile isn’t agile all the time. Its about being flexible in how you deliver primarily around the uncertainty in the project. More uncertainty more agile. Less uncertainty more classical (still pieces of agile). Good message.

2. They still avoid that budget thing The metrics quoted by this guy were about match to business goals … not about cost to achieve them. The unanswered question is … did we achieve 100% match but spend 80% of the budget (w/ overrung) to achieve the last 20%? Does that last 20% really drive the 80% of the value? Our estimating model does a better job (could be applied in agile structures) of showing the cost associated with various features. From which clients could assess lining out specific areas (lacking payback).

3. Liked Thier Parking Lot Status They showed an example of a parking lot status. If some watches snapshot it. Basically it was a 10,000 foot view of all the subject areas, activities in those, sub activites (metrics on stories that are ‘done done’) with stoplighting at the activity level. Could do that with process views as well.

Here are my detail notes for those inclined.