Tag Archives: Agile

IEEE “Pragmatic Clouds” Presentation (2/24/10)

Posted on by
Reply

Tonight I presentated “Pragmatic Clouds” to the IEEE Central Texas Consultants Network Meeting.

The abstract was, “Cloud computing seems to mean everything! We’ll talk in specifics about how application development and delivery models are changing based on new “cloud” commercial models. We’ll also explore how the plumbing behind the curtains is changing to reflect these new models.”

In the presentation, I covered drivers for cloud business models and how it impacts creating applications for clouds. I also described how to write a future-proof application that can work for IaaS clouds today and PaaS clouds tomorrow.

Won to End (1..N) Ranking

Posted on by
Reply

Or I can buy a new toothbrush in Newark

Our team had a breakthrough moment last week, we changed our MRD* into a prioritized (1 to N, no ties) list and immediately identified some artificial work grouping that would have jeopardized the whole release.  Within 5 minutes, we’d done more to rescue our release than the 4 weeks prior.

Working on a traditional MRD is packing to go on a vacation.  You’ve made great plans, you’ve read all the brochures, and you can visualize yourself on the sparkling white sand surrounded beach chair relaxing next to your partner under gently swaying palms. 

Paradise sounds great, but the cold fact of today is that you’re late for your flight and you have to pack everything into a single suit case. 

Remember the McCallister household in Home Alone?   They were so busy packing and rushing out that they left behind sweet defenseless Macaulay Culkin.  Treating an MRD like a suitcase makes you so focused on the little details and the deadlines that you and your team will likely miss the big picture.  And once you’ve started your team may not react to market changes because they’ve already packed their mental bags:  “honey, we can’t have dinner with the President tonight because you promised that we’d play tennis.”

Another frustration I have with MRDs is that they are classically adversarial.  “Why did you pack that?  If you’re bringing that yoga matt then I’ll need a polo helmet!”  The fault is not in the people, the very nature of the document creates antagonism because the document is considered a monolithic whole.

It does not have to be like this.

Creating product direction should be more like planning a road trip than preparing for a transoceanic flight.  We know where we want to go, the essential things we need and who’s in the car: that’s enough to get started.  We’ll discuss the roadmaps as we go so we can explore the interesting sites (“geysers, cool!”) and toss out the bone headed detritus (“infrared beachcombing metal detector?”) along the way.

It takes trust and discipline to free fall into this type of planning.

When my team ranked our traditional MRD items into a 1 to N list, the conversation immediately became more focused, birds began to sing, and we each lost 5 pounds.  Several things happened when we changed the list. 

First, we looked at the deliverable as a system, not just a collection of features.   “Yeah, mayo is not much good without the bread, keep those together”

Then we started talking about what the customer needed (not what we had to deliver).  “Rob, we know you like sweet hot banana peppers but those are really optional compared to slicing the bread.”

Finally, we found it much easier to compare items against each other (“yeah, the ham feature is more important than tofu move that higher” instead of “we can’t ship this product without both ham and tofu!”)

Once we had the list ranked, it was obvious to everyone which features were required for the release.   Our discussion focused on the top priorities and engineering was able to focus on the most import items first.

Spoonful of Zietgiest

Posted on by
3

Do you want to have a winning team?  Bring a spoonful of zietgiest to your next meeting!

For me, Zietgiest is about how group dynamics influence how we feel about technology and make decisions.  It’s like meme, but I like Zeitgiest more because of its lower vowel ratio (Hirschfeld = 2:10).

Yesterday, my release team meeting had negative Zeitgiest.  Locally everyone was checking email while the remote speaker flipped through dense powerpoint slides.  It was like watching my divorced aunt’s family vacation slides via Webex.  We needed a spoonful of zietgiest!  That’s how I found myself explaining some of our challenges with the phrase “turd in the punchbowl” and getting people paying more attention to the real work.  A small positive spark and faked enthusiasm changed the momentum.  Yeah, it was fake at first and then become real zeitgiest when the other attendees picked up on the positive vibe.

The idea of seeding zietgiest is critical for everyone on teams.  It’s like the William James expression,feeling follows action: if you act happy then you’ll shake off the blues and start to feel happy.  Yes, this is 100% real.  The same applies for groups.  We can choose to ride or steer the zietgiests.

There’s no reason to endure low energy meetings when you can get out your spoon and stir things up.

Free Fall

Posted on by
2

Or elimination of pre-discussion bias

Learning Free Fall was the hardest of all the Agile comeuppance meted out to me.  Of course, it was not called free fall by the team teaching me about it.  Instead, it was the sinking feeling that I was always arguing the wrong side of every issue.  I was supposed to be the hot architect but my ideas kept getting shot down by the team.  They weren’t wrong per se, but they were not as good as the team could figure out during a discussion.

Meetings went like this:

Rob: “Hey guys, I’ve got this great idea that all of our SQL queries should leverage the zeitgeist feature because it will improve performance 25%.”

Team: “Um, yeah but zeitgeist requires us to perform green joins on the red data.”

Rob: “That’s a good point.  I thought that most of the data was yellow.”

Team: “That’s true.  What about meme queries?  They’re like zeitgeist but work for yellow and red data.”

Rob: “I really thought that zeitgeist was the way to go.  I think we can make that work if we limit the red data.”

Team: “Zeitgeist was a good suggestion, but we’ll go with meme.”

While my ideas helped the team, I could not get over the fact they did not go with my original idea.  Even worse, I would keep fighting for my idea after the team had obviously moved past it.  It slowed down decisions, made meeting more contentious, and caused our optometrist bills to skyrocket from excessive eye rolling.

All that changed when I learned how to trust my team and free fall during meetings.  Free falling (queue Tom Petty) is decoupling the problem from your idea of how it should be solved.  If you bring the problem to your team without a solution then you’ll get everyone’s brain working on ideas for the solution.  When I stopped being emotionally committed to the solution, I was much more ready to listen to other ideas.  More importantly, it was obvious to everyone else that I was more willing to listen so they were more willing to contribute and less interested in arguing.

When I started the discussion without having picked a solution, it was obvious to everyone that their ideas would be heard. 

We had more ideas, better discussion, and better results.  Generally, the team result was much better than my original idea and (bonus!) the team was always more willing to implement them after a free fall discussion.

Free fall takes some practice.  Find a buddy to help you stay on course by kicking you under the table when you’re reaching for your parachute.  Trust me – it’s like EPO for your team (and it’s legal!).