Agile Jumpstart – so you want to do agile?

A friend of mine is part of a business that wants to use Agile and he was asking me how to introduce agile to a team that has never used it before.

Even before asking, he’s already well on his way because his team wants to drive it as a business process not just for development (win #1), has a committed product owner (win #2) and likes the Agile Manifesto (win #3).

My advice surprised him because it was pretty simple and did not include ANY REQUIRED MEETINGS.  Here’s what I suggested:

  1. Have the product owner create a 1 page advertisement for the product that you are working on.
  2. Create a prioritized feature list (1 to N, no ties) that covers immediate and longer term items.
  3. Meet (ok, that’s a meeting) regularly to argue about the priority list as a team. I omitted that these would be sprints or iteration – the team will figure that out itself.

That’s it.  I also strongly recommend including retrospectives but I always recommend retros and he knows that part of the team building subterfuge that is Agile.

His primary question after this was how to schedule and estimate work.  My suggestion was to use a date driven release plan because it’s easiest to estimate billing if you use a calendar – cost = time * rate.   To make that work, you must give frequent demos to the customer so they are on board with the deliverables.    That’s the “easy” way.

If you want to predict when features will complete then use “story point” estimates.  Basically, each feature is estimated on an exponential scale (1,2, 4, 8, etc).  Big scary features will get big scary estimates.  When you are closer to starting, then you can decompose the big scary estimate into smaller units.  Ideally, you can decouple the work so that parts of the larger feature get done earlier and proven in the market.  It all ties back into your ranked list.

Splitting large features into smaller component may create a very useful interweaving where high value parts of features get done quickly where “bonus” components never get done.  Of course, this will drive engineers crazy because the don’t get to add those extras that create bloatware.

Overall, the goal of Agile is to create product the sells.  Now, that’s not too hard to understand is it?

Rethinking the “private cloud” as revealed by the Magic 8 Cube

The Magic 8 Cube

This is the first part of 3 posts that look into the real future for “private clouds.”

This concept is something that was initially developed with Greg Althaus, my colleague at Dell and then further refined in discussions with by our broader team.  It grew from my frustration with the widely referenced predictions by the Gartner Group of a private cloud explosion.  Their prognostication did not ring true to me because the economics of “public cloud” are so compelling that going private seems to be like fighting your way out of a black hole.

We’ll get to the gravity well (post 3 of 3) in due time.  For now, we need to look into the all knowing magic 8 cube.

Our breakthrough was seeing cloud hosting as a 3 dimensional problem.  We realized that we could cover all the practical cloud scenarios with these 8 cases.  Showing in the picture (right).

Here are the axis:

  1. X: Hosted vs. On-site – where are the servers running?  On-site means that they are running at your facility or in a co-lo cage that is basically an extended extraterritorial boundary of your company.
  2. Y: Shared vs. Dedicated – are other people mixing with your solution?  Shared means that your bytes are secretly nuzzling up to someone else’s bytes because you’re using a multi-tenant infrastructure.
  3. Z: Managed vs. Unmanaged – do you’re Ops people (if you have any) able to access the infrastructure that runs your applications?  Unmanaged means that you’re responsible for keeping the system operating.

With 3 axis, we have a 8 point cube.

  1. MSH – a PaaS offering in which every aspect of your application is managed and controlled.  GAE or Heroku.
  2. MSO – remember when people used to buy a mainframe and them lease off-hours extra cycles back to kids like Bill Gates?  That’s pretty much what this model means.
  3. MDH – a “mini-cloud” run by a cloud provider by dedicated to just one customer.  Dr. Evil thinks this costs one milllllllllion dollars.
  4. MDO – a cloud appliance.  You install the hardware but someone else does all the management for you.
  5. USH – IaaS.  I think that Amazon EC2 is providing USH.  It may be a service, but you’ve got to do a lot of Ops work to make your application successful.
  6. USO – OpenStack or other open source cloud DYI frameworks let a hosting provider create a shared, hosted model if they have the Ops chops to run it.
  7. UDH – Co Lo.
  8. UDO – The mythical “private cloud.”  Mine, mine, all mine.

In thinking this over, we realized that cloud customers were not likely to jump randomly around this cube.  If they were using MSH then they may want to consider MDH or MSO.  It seemed unlikely that they would go directly from MSH to UDO as Mr. Bittman suggests; however, the market is clearly willing to move directly from UDO to MSH.

We had a good old-fashioned mystery on our hands… the answer will have to wait until my next post.

Alert the villagers, it’s Frankencloud!

I’m growing more and more concerned about the preponderance of Frankencloud offerings that I see being foisted into the market place (no, my employer, Dell, is not guiltless).  Frankenclouds are “cloud solutions” that are created by using duct tape, twine, wishful marketing brochures, and at least 4 marginally cloud enabled products.

The official Frankencloud recipe goes like this:

  • Take 1 product that includes server virtualization (substitutions to VMware at your own risk)
  • Take 1 product that does storage virtualization (substitutions to SAN at your own risk)
  • Take 1 product that does network virtualization (substitutions to VLANs at your own risk)
  • Take 1 product that does IT orchestration (your guess is as good as any)
  • Take 1 product that does IT monitoring
  • Take 1 product that does Virtualization monitoring
  • Recommended: an unlimited Pizza budget for your IT Ops team

Combine the ingredients at high voltage in a climate conditioned environment.  Stir in a seriously large amounts of consulting services, training, and Red Bull.  At the end of this process, you will have your very own Frankencloud!

Frankenclouds are notoriously difficult to maintain because each part has its own version life cycle.  More critically, they also lack a brain.

Unfortunately, there are few alternatives to the Frankencloud today.  I think that the alternatives will rewrite the rules that Ops uses to create clouds.  Here are the rules that I think help drive a wooden stake through the heart of the Frankencloud (yeah, I mixed monsters):

  • not assume that server virtualization == cloud. 
  • simple, simple and simpler than that
  • focus on applications (need to write more about DevOps)
  • start with networking, not computation
  • assume that software containers are replaced, not upgraded

What do you think we can do to defeat Frankenclouds?

Juxtaposition: Dave McCrory joins Dell Cloud Team & Quest acquires Surgient

Rarely in my life have I seen true juxtaposition as in the last few weeks.  Mearly hours after my long time friend and cloud conspirator, Dave McCrory, joined our team at Dell; the company that we founded, Surgient, was aquired by Quest software.  Neither of us had been there for years and had been looking for ways to work together again.  Apparently the cosmos required that we could not join forces while our first effort together was still standing.

Cloud Walker

Our cloud team at Dell is full of people who like to both dream and do.  Now that we added Dave, I am expecting BIGGER things.  We’re actively planning coordinated blogging about some of the issues and inspirations that are driving our plans.   Those topics include Dev-Ops, PaaSvsIaaS, and the real “private” cloud.

Dave, welcome back to the party!

Here’s what Dave posted:

A lot has occurred since my last blog post. I am continuing the development of my technology and working in the Cloud, however I have chosen to do this with a great team at Dell. I was approached a while back about this opportunity and as I dug deeper and saw the potential I began to buy in. Finally after meeting the great team of experts involved behind the scenes I decided to join them.
I have worked with some of the team members before including Rob Hirschfeld. Rob and I founded both ProTier (note that PODS ran on VMware’s ESX) and co-founded Surgient together (interestingly Surgient announced its acquisition by Quest Software last week). Rob and I have created a great deal of IP (Intellectual Property) in the past together, including the First Patent around Cloud Computing (This was filed as a Provisional Patent in 2001 and a Full Patent in 2002). Our time at Dell should produce some new and great work in the Applied Architectures and Intellectual Property sides.

Austin Cloud User Group, Tuesday 7/27 6pm

Many thanks to Bill Jacaruso @ Pervasive.com (DataCloud2) for keeping the cloud camp fever burning.  Sadly, I can’t make it on Tuesday.

Here’s what Bill said:cloud networking

We were so encouraged by the participation in CloudCamp Austin here at our office a couple of weeks ago that we’re kicking off an Austin Cloud User Group!  CloudCamp showed us that there’s a smart, engaged, passionate community of cloud technologists in Austin and we’d like to give folks a chance to get together F2F on a regular basis to swap ideas, showcase innovative cloud initiatives, and build connections. 

Here’s the proposed agenda for a kickoff session on Tuesday, July 27:

Agenda

  • 6:00 – 6:20 : Meet and greet with pizza and soft drinks
  • 6:20 – 6:40 :  Round-the-room – introduce yourself, what you’re doing and plan to do on the cloud
  • 6:40 – 7:20 : Organizational discussion – how often to meet?  When?  What format?

Interested?  Register at http://austincloudusergroup.eventbrite.com/

http://groups.google.com/group/austin-cug

Shared Nothing Virtual Cluster

A while back (2004), Dave McCrory and Patent can protect or trap good ideasI patented an interesting curosity that we called the Shared Nothing Virtual Cluster.  Basically, the idea is to use OS RAID 1 on a VM but to have the VHDs split between physical hosts.  If the host died, the VM could be restarted on a the second host using the RAID mirror.

It was an interesting idea, but seemed less than ideal because everyone was running to SAN storage and falling madly (insanely?) in love with vMotion.

Now that we’re looking towards clouds that beyond SAN scale, the idea of mixing DAS and NAS to create instant redundancy for VMs may suddenly have more value.

Of course, Sugient owns the patent now…

Microsoft & Dell partner for Azure hosting

Vacation rental in Fort Walton Beach, FLA

Interesting juxtaposition, last week I was vacationing at the Azure condos in Florida and this week Dell is making a strategic announcement to develop a Dell-powered Microsoft Windows Azure Platform Appliance, as well as Azure based services delivered by Dell Services.

Press Release: http://content.dell.com/us/en/corp/d/press-releases/2010-07-12-dell-microsoft-cloud-azure-appliance.aspx

This is a project that I’m involved in, so watch for updates as details emerge.

Annual Performance reviews hazardous for team performance

Performance Review Game

You don’t have to go farther than your own personal experience to know that annual reviews completely fail to motivate, inform, or protect people.  If you’re own experience is not enough try comparing notes with peers, reading JoelOnSoftware, and PeopleWare by DeMarco.

If you’ve got a great performance from an individual, a review is likely to hamper it.  If you’ve got a great team then individual reviews are likely to sabotage it.  Really.  This is 100% true and there’s plenty of research to back it up.

Managers – if you are relying on performance reviews to create great employees and teams then you’re feedback is way way way (way) too late.  If you are relying on inventive pay to build your feedback is not only too slow but likely to cause more problems then you imagine.  Most of these systems only show employees that they are not valuable and build up your (the manager’s) ego.  If that’s not intuitive to you then you need to educate yourself.  Read and learn.  It’s not too late!

Here’s an NPR article supporting the evidence:  Annual Job Review Is ‘Total Baloney,’ Expert Says.  Employee performance reviews should be eliminated, according to Samuel Culbert: “First, they’re dishonest and fraudulent. And second, they’re just plain bad management.” The UCLA business professor has written a new book expanding on that view.