Silicon Valley State of Mind, a blog by John Weathington, "The Science of Success"
  • @SVSOM
    @SVSOM

    Welcome to a Silicon Valley State of Mind, thoughts tips and advice based on the consulting work of John Weathington, "Silicon Valley's Top Information Strategist."

  • bio
    bio

Silicon Valley State of Mind

Tips, thoughts, and advice based on the consulting work of John Weathington, "The Science of Success."

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that has been used in the blog.
  • Archives
    Archives Contains a list of blog posts that were created previously.
Subscribe to this list via RSS Blog posts tagged in agile

Posted by on in Program Management

Blackouts remind me why I’m not a devout agilist anymore. My block in San Ramon had another one if its infamous blackouts a few days back. And just like the last major blackout we had, my productivity only decreased a tiny bit; I was certainly able to accomplish all the critical things on my plate, including an important client deliverable that was due that day. At worst, blackouts are a nuisance for me; they don’t really slow me down because I’m prepared. However, that wasn’t the case in the early part of this century when I was a born-again agilist. When it comes to execution, Aristotle had it right with his golden mean—you must find a good balance between the two extremes of classical waterfall and agile.

The ideology of agile management proscribes advanced planning, even when it comes to risk management. The way agilists handle risk—like everything else—is very empirically. In agile execution, there’s the concept of yesterday’s weather wherein the belief is that today—for all intents and purposes—will be like yesterday. So, instead of formally analyzing risk, agilists just assume they’ll crank out as many widgets in this cycle as they did in the last cycle. Axioms like this allow them to forego much of the upfront planning that classic (i.e. waterfall) managers would necessarily undertake. That’s all fine and good—until it’s not fine and good.

The reality is this: Murphy is far too mischievous to be that consistent. Tuesday I had power all day long, just like Monday, Sunday, and Saturday. However, on Wednesday I had no power from about 6:00pm until about 3:00am the next morning. That’s nine long, dark hours if you’re not prepared. This is one big area where agile execution simply falls short—I don’t care how passionate you are about the ideas.

Fortunately for me—long before Wednesday—I stocked up on candles, lanterns, tap-lights, flashlights, portable light-bulbs, and most importantly batteries of all shapes and sizes. Kim and I actually had a pretty nice time that night after I finished up my work. The house was well lit, we ordered some food from a local restaurant, and we watched TV together on the iPad by candlelight (and battery-powered lanterns).

Don’t get me wrong; I’m still very much in the agile camp for most scenarios. However, like Aristotle would probably say today, you cannot be a die-hard fanatic on one style or methodology. That’s why the consultant’s standard answer to any question is, “it depends.”

Don’t let your zeal for agile put you in a blackout without batteries.

Tagged in: agile execution risk
Rate this blog entry:
0

Posted by on in Operational Excellence

For the second time this week, I’m typing this blog while the power is out. The last time came as quite a surprise; however, this time, I was more prepared as our electric company left a notice on the door yesterday stating that they would be doing planned maintenance at this time. I made a note on my calendar to that effect, and when planning my day last night, started considering how I would be impacted by the power outage. Not much came to mind, so I scheduled it like any other day. To be resilient, you must break dependencies.

In my practice, I’m not bound by continuous power. Even if my Uninterruptible Power Supply gives out, which keeps me 95% functional, I can still operate at close to 90% productivity for the rest of the day. I’m typing this entry on a MacBook Air which still has plenty of battery life, and I have a battery powered wi-fi device to get to the Internet if I need to. Most of my operational data is in the cloud, so as long as I have Internet access, I’m in business. My cell phone is fully charged, so no issues with calling people. The only thing I can’t really do right now is crunch large sets of data on my server—and fortunately that can wait.

There’s a concept in agile design called low coupling. This means, for your solution to be agile, it should not be bolted into other components of the system. This is what makes agile systems resilient, and it can make your business and your life resilient as well. If you like to play Jenga, you know exactly what I mean; removing one small block can bring the whole tower down. You don’t want or need these blocks in your organization or in your life.

When going through your improvement cycle, focus on decoupling strong dependencies. Don’t allow the power to go out on your business just because there’s no electricity.

Rate this blog entry:
0

Posted by on in Program Management

The Unites States Federal Bureau of Information (FBI) announced today that it spent $600 million to share files electronically. That seems silly doesn’t it?

To add insult to injury, this was the initiative that was spurred by the September 11th attacks back in 2001. That’s right, it took $600 million and 12 years to build a system that shares files electronically.

I know you may not be as experienced as I am in these matters, but in case there’s any doubt, no it does not take $600 million and 12 years to build a system to share files. At Sun Microsystems, it took me only $2 million and 1 year to build an entire compliance data system from scratch, that hooked into four disparate transactional systems including a massively customized Oracle ERP installation. This is at Sun Microsystems, the closest thing I’ve ever seen to a government operation in the private sector.

The obvious problems are bureaucracy and politics, but it’s worth mentioning to highlight just how insane costs can get when you don’t get this straight. Bureaucracy and politics go hand in hand to destroy a program. Bureaucracy happens when objectives don’t matter anymore and everyone’s just worried about following steps. This is what I call the project management trap. Politics happen when leaders protect their fiefdoms by any means possible, sustaining their position and the status-quo. In both cases, objectives are demoted in favor of artificial gods.

To prevent this in your organization, do three simple things:

  • Establish an Executive Sponsor who is clearly accountable for objectives. Give him/her the chair on a steering committee if you must, but there should be one, very high-level person accountable for nothing but results.
  • Establish a program/project charter, and assign full authority and responsibility to a competent program manager. Hire a good consultant of you don’t have the competence or availability in house, but avoid huge management agencies; it’s like hiring another bureaucracy. The FBI fired Lockheed Martin midstream on this project due to delays. I wonder why. The same thing will happen with any of the big consulting firms.
  • Setup tight-cycle (i.e. weeks, not months), functional deployments (i.e. something that can actually be used by the business), and reward everyone based on accomplishing small objectives to attain larger objectives.

Just like bureaucracy and politics work together to bloat program costs and timelines; these three practices work together as the Pepto-Bismol. By keeping the focus on objectives and actively fighting politics and bureaucracy, you can bring your project in far under $600 million and 12 years.

I mean, really? Give me a break!

Rate this blog entry:
0