Tag Archives: feedback

All About That Loop. Lessons from the OpenStack Product Mid-Cycle

Posted on by
2

OpenStack loves to track developer counts and committers, but velocity without A Feedback loop to set direction is unlikely to get us anywhere sustainable.

LoopLast week, I attended the first day of the OpenStack Product Working Group meeting.   My modest expectations (I just wanted them talking) were far exceeded.  The group managed to cover both strategic and tactical items including drafting a charter and discussing pending changes to the incubation process.

OpenStack needs a strong feedback loop from users and operators back to developers and vendors – statement made during the PM meeting.

The most critical wins from last week what the desire for the PM group to work more closely with the OpenStack technical leadership.  I’m excited to see the community continue to expand the scope of collaboration.

Why is this important?  Because developers and product managers need mutual respect to be effective.

The members of the Product team are leaders within their own organization responsible for talking to users and operators.  We rely on them to close the communication loop by both collecting feedback and explaining direction.  To accomplish this difficult job, the Product team must own articulating a vision for the future.

For OpenStack to succeed, we need to be listening intently to feedback about both how we are doing and if we are headed in the right direction.  Both are required to create a feedback loop.

After seeing this group in action, I’m excited to see what’s next.

Want to read more?

Get involved!  Join the discussion on the OpenStack Product mailing list!

Forward-looking Reviews: Feedback loops essential for Agile success

Posted on by
4

To keep pace with cloud innovations, my team at Dell drives aggressively forward.  Agile is essential to our success because it provides critical organization, control and feedback for our projects.  One repeating challenge I’ve had with the Agile decorations (aka meetings) is confusion between the name of the meeting and the process objectives.

The Agile process is very simple:  get feedback -> decide -> act -> repeat

People miss the intent of our process because of their predisposition about what’s supposed to happen in a meeting based on it’s name. 

Some examples of names I avoid:

  • Demo – implies a one-way communication instead of a feedback loop
  • Post-mortem – implies it’s too late to fix problems
  • Retrospective – implies we are talking about the past instead of looking forward
  • Schedule – assumes that we can make promises about the future (not bad, but limits flexibility)
  • Person-Weeks – focuses on time frame, not on the use cases we want to accomplish

Names that work well with Agile

  • Planning – we’re working together to figure out what we’re going to do.
  • Review – talking over work that’s been done with input expected.
  • Roadmap – implies a journey in which we have to achieve certain landmarks before we reach our destination.
  • Story Points – avoids time references in favor of relative weights and something that can be traded.
  • Velocity – conveys working quickly and making progress.  Works well with roadmaps.

We have recognize the powerful influence of semantics for people participating in any process.   If people arrive with the wrong mindset, we face significant danger (IMHO, soul numbing meetings are murder) from completely missing critical opportunities to get feedback and drive decisions.  Since We rarely review WHY we are meeting, so it’s easy to have people not engage or make poor assumptions based on nothing more than our word choice.

The most powerful mitigation to semantic confusion is to constantly seek feedback.  Ask for feedback specifically.  Ask for feedback using the work feedback.

Does this make sense?  I’d like your feedback.