We are planning to start having TWO weekly community sprint meetings.
NOTE: Times can still shift depending on community input! We are trying to a truly global community so we need your input.
The weekly design discussions will be on Tuesdays @ 10am Central (GMT -6). The topics will be relevant to the coming sprint and we expect dialog. The topics will be determined by Greg Althaus based on progress on the refactor. You’re welcome to contact him or the list with suggestions.
identify issues that need to be addressed in the next sprint
The weekly coordination meetings will be on Thursdays @ 8am Central (GMT -6). We want to respect everyone’s time and will strictly limit these to 1 hour. This meeting is in between our internal sprint review and planning so we have flexibility to adjust our plans based on your input. It is important to us that we make it possible for you to contribute and we need your input to make sure that you are not blocked!
The coordination meetings will be structured as follows (times approximate)
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.
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.
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.