11 October 2013

process: sequencing and ownership


I was reading an Agile blog this morning. I know I shouldn't, but I did.

The author was complaining about a product manager coming to the group with fully thought out requirements and stories that were too long and complex. And again, I thought... is this about control and making requirements up as we go along?

For any project to be somewhat efficient and effective we must have some sequencing and some expertise that drives decisions. Group think is aggregate. If you understand statistics you know that there really is a very minimal amount of understanding that comes from averages. Similarly, group or aggregate thinking renders severely compromised decisions. Higher levels of expertise should be allowed to take responsibility and make final calls. Further, some level of individual work (divide and conquer) must exist. A team does not always need 5 or 6 people standing at the whiteboard to execute the simple or most detailed of functionality.

There is an element of sequencing that makes sense as a project progresses. Requirements come before solutions. Sketches come before code... it’s critical in any process... even agile and lean.

In most software development work... 50-85% is fairly standard and doesn’t require huge efforts of innovation. Many times meeting expectations (quick adoption) is more important than improving process.

02 October 2013

The agonizing downslide...

We are still witnessing an agonizing fall from mobile supremacy. Reading yet another article about the demise of the Research in Motion (RIM) I was struck by what seems obvious. Their quick rise was due primarily to a happy accident... the post 911 logjam of the traditional telecom networks. Days after 911, the US government began to distribute thousand of Blackberries to government officials because RIM had built their own network that was under utilized and had plenty of available bandwidth. That market advantage wasn’t bound to last. 

The perception of Apple (RIM’s primary predator) having the audacity to build a phone was seen as very high risk. It was sooo outside of their expertise... they weren’t part of the sanctioned club. It’s interesting how many people, and especially people driving strategy, perceive risk. Risk is not reckless... it’s not guess work, and it’s not typically without extensive calculations and homework. Most interpret skydiving, scuba diving, rock climbing as risky endeavors. Yet ALL of the people I know that undertake these hobbies are as careful, skilled, studied, and prepared professionals I’ve ever worked with. They are way way aware and cautious about their approach (to everything frankly) and the possible outcomes.

But the real story here is how hardware and software need to work together. Blackberry fell in to a trap that Motorola had long honed... developing hardware in a vacuum and sharing the ‘thing’ to their software development team once it was near completion so that they could design software. They saw it has a platform rather than an integrated product offering. Motorola designed and manufactured incredible hardware... for years and years. Where they fell down repeatedly was in the development of not only good user facing software, but how it integrated with their hardware. 

Every time I stand in front of an ATM or a grocery store checkout I am reminded of this conundrum. Software must be integrated with the hardware development process. The teams need not only to talk, but to sit side by side.

01 October 2013

The inherent problem of ‘locking down’ product requirements.


Many managers, in a struggle to accomplish completion of projects insist that product requirements be locked down prior to the process of solutioning. Often this is a symptom of a disconnect between product management and design. 

Locking down requirements moves a problem from one that is complicated... to one that is either complex or merely simple. It reduces the variable nature of problem solving from one of multiple solutions to the potential of a ‘right’ solution. But, it does that using unreal or arbitrary constraints. Things change. Our understandings change. And the ‘locking down’ of product requirements ignores that. It isolates the definition of the problem we are trying to solve to an instance... an instance that may pass us by as a mere blip on the path we travel.

I’ve been quoted as saying that, “locking down product requirements is lazy management”... and I stand by that. Reducing the problem to a non changing situation, and reducing our solutions to a stagnant state of understanding reduces out ability to solve the problem optimally. It changes the entire focus from finding the best solution, to getting the job done. That, is not an optimal compromise.