Work with me! Our Dell team is hiring architects, engineers & open source gurus

If you’ve been watching my team’s progress at Dell on Crowbar, OpenStack and Hadoop and want a front row seat in these exciting open source projects then the ball is in our your court!   We are poised to take all three of these projects into new territories that I cannot reveal here, but, take my word for it, there has never been a better time to join our team.

Let me repeat: my team has a lot of open engineering and marketing positions.

Not only are we doing some really kick ass projects, we are also helping redefine how Dell delivers software.  Dell is investing significantly in building our software capabilities and focus.

Basically, we are looking for engineers with a passion for scale applications, devops and open source.   Experience in Hadoop and/or OpenStack will move you to the top of the pile.   These positions say Hadoop, but we’re also looking for OpenStack, DevOps and Chef.  We think like a start-up.

Ideally in Austin, Boston or the Bay.  We’ll also be happy to hear from you if you’ve got l33t chOps but are not as senior as these positions require.
If you are interested, the BEST NEXT  STEP IS TO APPLY ONLINE.
If you don’t want to click the links, I’m attaching the descriptions of the engineering positions after the split.

Continue reading

The Tao of Agile: focus on delivery while still dreaming BIG

This post is a continuation of the Agile Strategy post.

So, how do we get into the right frame of mind for roadmapping?

You must embrace the Tao of Planning.

There are two conflicting principles behind roadmapping: you must keep thinking out of the box while keeping work deliverable. Neither of these principles is difficult in isolation. The challenge is the keep them in balance and to make sure that the whole team is included.

For my team, we struggle to find group times when we can do some big thinking. The challenge is not the thinking – it’s the TEAM aspect of working on strategy together. Our sprint planning needs to focus on the “keeping work deliverable” objective; consequently, there is precious little time in planning to have big ideas. To make the meeting duration manageable, planning meetings should have a tactical focus. Unfortunately, that leaves a strategy gap.

So, where does a team go to dream?

I wish I had a clear answer to this problem. Ideally, sprint review meetings should extend into deep thinking about where things could go. Strategy during Review is a natural extension because a review mindset should be forward looking. Reviews help us think about how we’re going to use what we delivered and the audience should bring external perspectives. If we could do this then it would be very empowering and exciting during review.

That’s why it’s important to celebrate, play, reflect and pause. All work and no play leaves a team that makes very dull products

Note: the Agile decorations that I use are: Sprint Planning (commits that plan) -> Stand-up (daily sync meeting -> Review (demo/sprint close) -> Retrospective / Hats (team feedback, improvement).

Agile takes discipline: having a strategy means saying “no” more than saying “yes”

With the Crowbar release behind us, it’s time for my team at Dell to do some Capital “P” Planning. Planning for us includes both tactical (next release) and strategic (the releases beyond the one after next), but each type of planning looks very different. I’m going to call it “roadmapping” because planning means something specific and tactical in Agile.

I love roadmapping but I’m a pain to roadmap with because I’m a ruthless prioritizer.

When I sit down for roadmapping, I always do it from a 1 to N list without ties. That means that when marketing asks for a new feature (double the foo on the bar!) we put it on the list relative to other work that needs to get done. If you add something at the top then something else will fall off the bottom. Effectively, we’re using the list to say no to a lot of great ideas. This is essential because “the great is the enemy of the good (Voltaire).” It’s hard, but that’s the cold reality of delivering product.

The most important part of strategy is figuring out what to push down to make room for the precious few yes items.

Successful roadmapping is negotiating the splitting of big ideas into smaller ones. Decomposition is a circular process because one compromise may require another, but one change may force a cascading assumption fault. If you get too emotionally committed to one feature or subset then you’re going to slow down the process. It’s vital to approach roadmapping in free fall.

As always, my advice is to not mix meeting objectives. If you need more strategy then you’ve got to make time for it.

Interested in more…stay tuned for Agile Tao: balancing tactics & strategy

Avoid false agreements and saying no with a yes. #TeamDeath

caution

One of my favorite things about Agile is how it helps teams get committed toward a shared goal.  There are so many distractions and confusions, that we need to double down ways to help people get and then stay on the same page.  In some cases, it comes down to something as simple as word choice!

First, I feel like I need some explanation…

There comes a time in any disagreement when the team needs everyone to get on the same page even if they don’t agree.  As a rule, this should be a relatively small window (maybe 20 minutes max) because the team can defer issues by having a sprint long spike* or exploration story that collects more information to settle arguments down the road. 

Personal Experience Note: A team should NEVER spend much time arguing about the mid or long-term future!  It’s just not worth the time to convince someone that your vision is more compelling.  It’s more efficient to accept that there are MULTIPLE VALID FUTURES and that the team needs to watch to see which one(s) is  taking shape.  There is no need to be “right” about the future.

So, back to the fake agreement phrases that effective teams avoid.

#1 “Yes, but…”

This statement really means “Will you shut up already?  I don’t agree.”  The speaker says “yes” to acknowledge the first person has finished; however, it does not mean that they agree.  The confusing thing is the speaker typically does not even realize that they are sending you into a discussion death spiral. 

Anytime someone says “but” then they are disagreeing.   Just for fun, trying have discussions where people are not allowed to say but – it creates a whole new positive dynamic.

#2 “I don’t disagree”

This statement really means “You are full of shit and my opinion is more right.”  The speaker is trying to avoid addressing your points directly and refocus discussion on their opinion.  Agreement means that everyone believes the same thing.  There are many ways to not agree and only one way to agree.

This is one of my pet peeves because the speaker thinks they are rewarding you with some back-handed pat on the head.  In reality, they shutting your ideas down without validation or acknowledgement.

There are many such statements that waste team time and mask disagreement.  If you have some that bug you, please comment on this post and add to the dialog.  I’m sure that I won’t disagree with any of them!

* Spike stories are time bounded stories that have specific research or opinion deliverables.  They are intended to collect enough information that the team can take action and move forward.   Sometimes these are also called “time box” stories.

Rethinking Play and Work: gaming is good for us (discuss in ATX, Dell, Twitter?)

Brad Szollose’s Liquid Leadership piqued my interest in the idea that gaming teaches critical job skills for the information age.  This is a significant paradigm shift in how we learn, share and collaborate to solve problems together.

At first, I thought “games = skillz” was nonsense until I looked more carefully at what my kids are doing in games.

When my kids are gaming they are doing things that adults would classify as serious work:

  • Designing buildings and creating machines that work within their environment
  • Hosting communities and enforcing discipline within the group
  • Recruiting talent to collaborate on shared projects
  • Writing programs that improve their productivity
  • Solving challenging problems under demanding time pressures
  • Learning to perseverance through multiple trials and iterative learning
  • Memorizing complex sequences and facts

They seek out these challenges because they are interesting, social and fun.

Is playing collaborative Portal 2 (which totally rocks) with my 13 year old worse than a nice game of chess?  I think it may be better!  We worked side-by-side on puzzles, enjoyed victories together, and left with a shared experience.

On the flip side, I’ve observed that it takes my kids a while to “come back down” after they play games.  They seem more likely to be impatient, rude and argumentative immediately after playing.  This effect definitely varies depending on the game.

I don’t pretend that all games and gaming has medicinal benefits; rather that we need to rethink how we look at games.  This is the main theme from McGonigal’s Reality is Broken (link below).  I’m just at the beginning and my virtual high lighter is running out of ink!  Here are some of her observations that she supports with research and data:

  • Gaming provides an evolutionary advantage
  • The majority of US citizens are gamers
  • Gaming teaches flow (state of heightened awareness that is essential to creativity and health)
  • Gaming drives UI innovation (really from Szollose) (yeah, and so does the porn industry)

If you’re interested in discussing this more, then please read one of the books listed below and choose another in the field.

Please feel free to post additional suggestions for titles as comments!

If you’re interested, let me know by commenting to tweeting – I’ll post our meeting times here in the future.

Note: I do not consider myself to be a “gamer.”  Although I greatly enjoy games, my play is irregular.  I suspect this is because I can achieve flow from my normal daily activities (programming, writing, running).

Go read “Liquid Leadership” (@bradszollose, http://bit.ly/eaTWa6): gaming=job skillz, teams=privilege & coopetition

I like slow media that takes time to build and explain a point (aka books) and I have read plenty of business media that I think are important (Starfish & Spider, Peopleware, Coders At Work, Predictably Irrational) and fun to discuss; however, few have been as immediately practical as Brad Szollose’s Liquid Leadership.

On the surface, Liquid Leadership is about helping Boomers work better with Digital Natives (netizens).  Just below that surface, the book hits at the intersection of our brave new digital world and the workplace.  Szollose’s insights are smart, well supported and relevant.  Even better, I found that the deeper I penetrated into this ocean of insight, the more I got from it.

If you want to transform (or save) your company, read this book.

To whet your appetite, I will share the conversational points that have interested my peers at work, wife, friends and mother-in-law.

  • Membership on a team is a privilege: you have to earn it.  Not everyone shows up with trust, enthusiasm, humility and leadership needed.
  • Video games position digital natives for success.  It teaches risk taking, iterative attempts, remote social teaming and digital pacing.
  • Netizens leave organizations with hierarchal management.  Management in 2010 is about team leadership and facilitation.
  • Smart people are motivated by trust and autonomy not as much pay and status.
  • Relationship and social marketing puts to focus back on quality and innovation, not messaging and glossies.  Broadcast (uni-directional) marketing is dead.
  • Using speed of execution to manage risk. Szollose loves Agile (does not call it that) and mirrors the same concepts that I expound about Lean.
  • Being creative in business means working with your competitors.  My #1 project at Dell right now, OpenStack, requires this and it’s the best way to drive customer value.  The customers don’t care about your competitor – they just want good solutions.

PS: If you like reading books like this and are interested in a discussion group in Austin, please comment on this post.

Please (I’m begging here) consider the psychology of meetings!

It’s an occupational hazard that I go to a lot of meetings.  That’s not a bad thing because my job is a team sport.  Except for rare moments of programming bliss, my primary responsibility is to design, collaborate, and coordinate with other people.

The Problem

My problem with meetings is that we often forget about psychology when we are holding meetings.  I’m not going to go all B F Skinner or DeBono’s Hats on you, but I want to reinforce that we all have DIFFERENT MODES OF THINKING during meetings.  Some examples:

  • Listening to a presentation *
  • Giving/getting status *
  • Designing a product or presentation
  • Negotiating requirements
  • Making collaborative decisions
  • Celebrating success *
  • Giving subjective feedback

Let’s get concrete.  It is impossible to get people to  do design during a status meeting.  Even if you have the same people in the room, the way they behave (taking turns talking, rushing to finish, linear) during a status meeting is fundamentally different from how I would expect them to act during a design session (dynamic back and forth, pausing to reflect, circular)

It’s even worse when you factor in time bound meetings (I added * to them above) for open-ended activities like design, feedback, and collaboration.  If you want to kill ideas or suggestions then ask for them during the closing 2 minutes of a meeting. 

A big part of the solution is to remember how people are framing your meeting. 

  • If you want decisions but need to get people up speed then plan a clear end to the status part of the meeting
  • If you want feedback and discussion then don’t throw in a lot of status or one-way presentations.
  • remember:  Any meeting with a power point deck is a PRESENTATION.  It is not a discussion.

Agile Meetings

One of the things I like about Agile is that there is a lot of psychology in Agile!
 
The meetings in Agile are planned so that people are in the right frame of mind for the meeting. 
  • Stand-up (scrum) is a time bound status meeting.  It should be tight and focused.
  • Review is a FEEDBACK meeting and NOT a presentation meeting.  I like to have different people talking during the meeting so that it does not put people into a power point stupor. 
  • Retros are discussion meetings.  The must be open ended so people are not rushed. 
  • Planning is a design meeting where new ideas are formed.  People must be relaxed so they can be interact and collaborate.
It’s even more important to understand that the way iterations unwind is part of the magic
  • Reviews reinforce that team member have completed something.  It puts them in the frame of mind that they have closed something and are ready to start on new work.
  • Reviews give feedback to set priorities so that people feel like they know what’s important.  Their expectation is that they are working on what’s most important.
  • Retros build up team spirit.  They celebrate achievement and clear the air so the team can collaborate better. 
  • Retros establish team trust.  Trust is the single most essential ingredients for good design because people must take risks when they make design suggestions.
  • Planning brings together the feeling of accomplishment and purpose from reviews with the trust and collaboration from retros.
  • Planning should empower a team to be in control of their work and be confident that they are on the right track.
  • Stand-up, when planning works, becomes a quick reinforcement of priorities.
  • Stand-up should be status that the plan is on track or lead to a discussion (a new focus) for correction.

If meetings are getting you down then consider what type of meeting your are trying to create and focus your effort on that outcome. 

Oh, and my #1 tip for more effective meetings

Find ways to be collaborative by sharing screens, co-editing documents, or just rotating speakers.  It’s not a productive meeting when just one person has the conch.

Black Hat Feedback Essential For Cloud Success

It’s been too long since my “Agile in the Cloud” blog focused on the agile process side of the equation.  Since my theme for 2011 will be “Doing is Doing” (meaning, attending meetings and building powerpoint is NOT doing); it’s vital to embrace processes that are action and delivery focused.  Personally, I tend towards the Lean side (Poppendieck & Ries) of the Agile process spectrum.

Let’s start with something so obvious that most teams don’t bother with it:

The secret to improving your performance is to regularly work to improve your performance.

There is no further magic, no secret sauce, no superhero team member, and no silver process bullet that substitutes for working together to improve.  A team that commits to improving will ultimately transform into a high performing team.  Hmmm…that seems like a desirable result.  So why is it so uncommon?

Unfortunately, many teams skimp on improvement because:

  1. All that talking and listening and improving takes time and attention.
  2. Post mortem or “lessons learned” meetings that never make any difference because they happen after the work is done.  (well, duh).
  3. No one has a methodology that makes the meetings productive.
  4. Lists with more than 3 items on them have too many items to be productive for improvement activities because of reader’s limited attention spans.  Doh!

So #1 and #2 just take some resolve to resolve.  My (atypical) team at Dell spends 1 to 3+ hours every biweekly sprint talking about process improvement (aka retrospective).  That’s nearly half of our planning day and a pretty significant investment; however, it’s the one part of the meeting that no one is willing to shorten.  It just that damn productive, important, and enlightening.

If you’re committed to taking the time to improve then finding a methodology (#3) is a piece of cake by comparison.  I highly recommend De Bono’s Six Thinking Hats the framework for retrospectives.  Michael Klobe taught me this process and I’ve used it successfully on many teams.  Here are some guidelines to retrospectives (we call them “Hats Meetings”) using De Bono’s hats:

  1. Write everything down.  All our planning meetings are documented.  This is ESSENTIAL because we review our past notes.
  2. Start with “Yellow” hats from all team members.  Yellow hats are accolades, complements, thanks, generally positive news, and anything that the team can celebrate.  Yellow hats get the meeting opened on a positive note.
  3. Go until your team runs out of yellows.
  4. Write down and number the “Black” hats.   Black hats are things that impacted team performance.  Ideally, they are concrete and specific examples of a problem and a cost.  Black hats are NOT solutions or suggestions hidden as complaints.  If you’re frustrated that people are late to meeting then a good hat would be “people being late to meeting is costing us 10 minutes of productivity because we have to restart the meeting 3 times.”  Hats like “The vendor messed up” are not as helpful as “The vendor’s late delivery of the futz dinger caused us to work over the weekend.”  Good black hats are a learned skill and are essential to success.
  5. Do NOT record every detail when writing down a black hat.  You just need to capture the ending understanding of the person who brought up the item (not of the team).  I’ve seen many hats that would have been a huge HR problem if we wrote down the starting idea but the ending hat was perfectly ok.
  6. Go until your team runs out of blacks.  This may take a long time if you’re just starting out!
  7. Come up with a “Green” hat for each Black hat.  Green hats are ways that the team or individuals will solve the problem addressed by the Black hat.  Solutions should be practical and immediate.  The team must discuss the solution (free fall) – it cannot be imposed by one member.  In many cases, solutions will go in steps: “everyone will try to show up on time” would be a good hat for my example above.  If that does not work, then future hats may involve “the late person pays $1/minute late.”  The point is that the team agrees on how they will improve.
  8. Don’t worry about White (data), Blue (new ideas), or Red (frustration, issues beyond your control) hats for now.  They are not critical for retrospective meetings.  Sometimes our team has a black hat that is really red.  If you’re arguing over a hat, then it may be red.  Stop fighting and move on.
  9. At your next meeting, review your past Green hats.  This is where accountability and improvement happen.

Please don’t expect that these meetings will be easy – they are messy and potentially emotional.  Since we’re talking about teams of people, we have to expose and resolve issues.  Investing the time upfront allows for continuous improvement and prevents building up larger issues.

Hats provides a durable structure for getting issues on the table in a productive way.

DevOps: There’s a new sheriff in Cloudville

DevOps SherrifLately there’s a flurry of interest (and hiring demand) for DevOps gurus.  It’s obvious to me that there’s as much agreement between the ethical use of ground unicorn horn as there is about the job description of a DevOps tech.

I look at the world very simply:

  • Developers = generate revenue
  • Ops = control expenses
  • DevOps = write code, setup infrastructure, ??? IDK!

Before I risk my supply of ethically obtained unicorn powder by defining DevOps, I want to explore why DevOps is suddenly hot.  With cloud driving horizontal scale applications (see RAIN posts), there’s been a sea change in the type of expertise needed to manage an application.

Stereotypically, Ops teams get code over the transom from Dev teams.  They have the job of turning the code into a smoothly running application.  That requires rigid controls and safe guards.  Traditionally, Ops could manage most of the scale and security aspects of an application with traditional scale-up, reliability, and network security practices.  These practices naturally created some IT expense and policy rigidity; however, that’s what it takes to keep the lights on with 5 nines (or 5 nyets if you’re an IT customer).

Stereotypically, Dev teams live a carpe diem struggle to turn their latest code into deployed product with the least delay.  They have the job of capturing mercurial customer value by changing applications rapidly.  Traditionally, they have assumed that problems like scale, reliability, and security could be added after the fact or fixed as they are discovered.  These practices naturally created a need to constantly evolve.

In the go-go cloud world, Dev teams are by-passing Ops by getting infrastructure directly from an IaaS provider.  Meanwhile, IaaS does not provide Ops the tools, access, and controls that they have traditionally relied on for control and management.  Consequently, Dev teams have found themselves having to stage, manage and deploy applications with little expertise in operations.  Further, Ops teams have found themselves handed running cloud applications that they have to secure, scale and maintain applications without the tools they have historically relied on.

DevOps has emerged as the way to fill that gap.  The DevOps hero is comfortable flying blind on an outsourced virtualized cloud, dealing with Ops issues to tighten controls and talking shop with Dev to make needed changes to architecture.  It’s a very difficult job because of the scope of skills and the utter lack of proven best practices.

So what is a day in the life of a DevOp?   Here’s my list:

  • Design and deploy scale out architecture
  • Identify and solve performance bottlenecks
  • Interact with developers to leverage cloud services
  • Interact with operations to integrate with enterprise services
  • Audit and secure applications
  • Manage application footprint based on scale
  • Automate actions on managed infrastructure

This job is so difficult that I think the market cannot supply the needed experts.  That deficit is becoming a forcing function where the cloud industry is being driven to adopt technologies and architectures that reduce the dependence for DevOps skills.  Now, that’s the topic for a future post!

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.