Tag Archives: Strategy

Self-Exposure: Hidden Influencers become OpenStack Product Working Group

Posted on by
6

Warning to OpenStack PMs: If you are not actively involved in this effort then you (and your teams) will be left behind!

ManagersThe Hidden Influencers (now called “OpenStack Product Working Group”) had a GREAT and PRODUCTIVE session at the OpenStack (full notes):

  1. Named the group!  OpenStack Product Working Group (now, that’s clarity in marketing) [note: I was incorrect saying “Product Managers” earlier].
  2. Agreed to use the mailing list for communication.
  3. Committed to a face-to-face mid-cycle meetup (likely in South Bay)
  4. Output from the meetup will be STRATEGIC DIRECTION doc to board (similar but broader than “Win the Enterprise”)
  5. Regular meeting schedule – like developers but likely voice interactive instead of IRC.  Stefano Maffulli is leading.

PMs starting this group already direct the work for a super majority (>66%) of active contributors.

The primary mission for the group is to collaborate and communicate around development priorities so that we can ensure that project commitments get met.

It was recognized that the project technical leads are already strapped coordinating release and technical objectives.  Further, the product managers are already but independently engaged in setting strategic direction, we cannot rely on existing OpenStack technical leadership to have the bandwidth.

This effort will succeed to the extent that we can help the broader community tied in and focus development effort back to dollars for the people paying for those developers.  In my book, that’s what product managers are supposed to do.  Hopefully, getting this group organized will help surface that discussion.

This is a big challenge considering that these product managers have to balance corporate, shared project and individual developers’ requirements.  Overall, I think Allison Randall summarized our objectives best: “we’re herding cats in the same direction.”

Open Source Vision, Strategy & Execution: The Community Garden Analogy

Posted on by
1

I’ve been working on a white paper series about open source culture and projects based on my experience with at Dell with Crowbar and OpenStack.  I’m hoping to show off the first result of that collaboration soon, until then I’m glad to share some ideas that we’ve been throwing around to help explain the fundamental shift that we see taking place in the technology community.

It’s obvious that executing a collaborative open source project is fundamentally different than a either a licensed or an open single contributor project.

However, we have yet to describe the culture, process and success criteria needed to drive a collaborative open source project.

I am not saying that projects are not being successful – there are many great examples (OpenStack, CloudFoundry, Apache). My point is that we I do not have articulated the vision, strategy or execution needed for people grounded in traditional software delivery to understand why these projects are different and how to navigate the differences. Lack of alignment within the lead delivery team can be highly disruptive to the project.

Community gardening is all about people working together to produce something tangible that is bigger than they could accomplish individually. Each participant has an expectation of return – a garden is not a charity, it must produce; however, there is a community drive rewards a garden wide focus.

  • You could just pull weeds from your plot, but doing extra means that the garden as a whole will prosper.
  • Fixing the fence keeps the “MQ” rabbits out of your carrots and your neighbors lettuce
  • The person growing the mint also keeps out the ants and so helps the entire garden.
  • The oddball that wants inverted chinese radishes may also be an expert vermiculturist who nurtures the whole worm population as a side interest
  • While everyone may want tomatoes, they may not want to same variety or amount. You may want a small batch of heirlooms for your salad while someone making pasta sauce wants

For a community garden, like an open source project, the specific objectives of the participants do not have to be identical for the garden to florish. In fact, the very diversity of intent is what makes the garden successful. A single gardener may only plant watermelons and corn, but the community group will likely have a complete crop.

But the analogy does not end with the gardeners. A community garden is also strengthened by the cooks and dinners who enjoy the food because they are the audience.

This post was designed to plant some seeds of understanding.  I know it does not get to the meat of the vision, strategy or execution for open source, that will come in future posts.  Specifically, I’m planning to discuss how OpenStack and Crowbar measure up as they near their respective second and first anniversaries.

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

Posted on by
1

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”

Posted on by
Reply

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