Friday, January 13, 2012

Realize how others perceive you

Considering we don’t really change personality-wise over the years, it comes as no surprise that our communication style often remains essentially the same as we grow in our careers. I recently realized however that the role we play in the organization has a great impact on how people interpret our messaging. Consider how the same brisk but honest statement from junior engineer “we have to do better, our UI is too clumsy” would come across very differently from a senior manager...

Have you noticed how as people move up the organizational ladder their written communications become sparser, particularly when addressed to multiple recipients, ultimately disappearing completely or becoming outsourced to professional aids? Could this be driven by the fear of being misinterpreted?

Sunday, January 8, 2012

Are we there yet !?!




With almost any sufficiently important project executives (or investors) want to keep a close eye on the progress made. As the project nears completion and the product launch looms ahead tensions may raise as uncertainty of successful outcome builds. See if you recognize this inquiry Product Managers may be responding to near the project end:
"As the owner of the backlog, how do you evaluate the priority? Do you have things such as must have vs wish for? Each time I have released a new product to market, there are always more things to do...it's a universal constant.

What I am looking for is a report that tells me how much of the backlog is customer driven/validated (required to be competitive in the market) vs. what folks desire. If we had a report that could provide insight into the health of the offering....not sure what metrics I would want to see, but I am sure I would like to know if the epics we started out to build, are creating the value we envisioned (i.e are market ready)."

 
In traditional requirements management, requirements are often categorized at 2-3 levels (e.g. Must/Important/Wish or High/Medium/Low). In Agile we are taught to rank them (user stories) from 1 to N, so if you have say 100 requirements ranked from 1 to 100, you may have only 10 show-stoppers - requirements that you believe absolutely prevent you from launching your product, or you may have 80 show-stoppers. In one case you are very close to be able to confidently launch your product, in another case you are probably quite stressed out.

So how do you know when you are truly ready to launch? Are you getting closer to that point, seem to be standing still or are actually drifting away?

Agile forces us to worry less about "launch readiness" in favor of most efficient utilization of available resources. In other words, as long as our teams (fixed resources) always focus on top priority (as defined and adjusted by Product Owners in timely fashion) issues there is nothing we can do... other than recognizing when we are not ready to launch.

There lies one challenge many Agile projects have to deal with: when the launch date is "artificially" fixed in advance the product team is like an airplane crew forced to land irrespectively whether the landing gear is down or not, without regard to weather and airstrip conditions. Should the crew be able to decide when is the right moment to touchdown, or in response to 1st class passengers "Are we there?" just strap on the seat belts and hold tight?

So in recognition of the need for transparency, how can we indeed bring more clarity to our progress on the final approach, without causing unfounded panic in the main cabin? :-)