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.