Choice of Agile Product Development Model

Republishing from my old blog...  I note that there are contrary points of view, but my observation below was unique given the circumstance I was in, at that point of time...
--------------------------------------------------------------------

I often wonder what kind of software product/project is a best-fit for Agile development model. While the answer lies somewhere in the product architecture, customer feedback loop, team structure, geographical distribution of teams and various other aspects, I am starting to realize that the "Delivery Channel and Mechanism" will actually provide a good decision box to start the algorithm. "Ends justify the Means" seems very appropriate here.

If your product version (or project) needs to be delivered very frequently, or your product is only hosted (not premised/licensed), you will obviously have some sort of iterative model in place already. Agile would be a no-brainer in such a circumstance.

On the other hand, if you had a 9-12 month long release cycle, would you move to Agile Development? An engineering-only decision will involve some deliberations along the points I mentioned in the first paragraph resulting in a downplay of implications across the rest of the enterprise ecosystem.

There are usually a lot of changes required in the other departments of the enterprise (outside the Engineering teams, let alone the extended enterprise) associated with a move to a frequent delivery model than one can imagine. The problem of having to release, sell/host, service, support, train, invoice etc is the much tougher nut to crack than the act of building the product itself. In other words, Agile development directly and heavily impacts the way rest of the enterprise thinks and acts.

A big bang approach to switch seems to be in-vogue when quick turn-arounds are expected. However, for an enterprise with diverse cultural/technical makeup and multiple geographical boundaries, a gradual adaptive model is probably the only wise choice. I strongly believe that the net goal of "efficient high frequency releases" will be achieved in just about the same timeframe as a big-bang approach, and the gradual transition will cause much less angst amongst the team members. In this hot market an unsatisfied team is a huge cost to pay for. A stepwise change from 9 to 6 to 4 to 3 monthly release (A total of two years) will provide enough time to exercise all the nuts and bolts of the new process.

In conclusion, the choice of agile development model is not that of the engineering organization, but is one that must be driven by the business goals, in response to the needs of the market with full cognizance of the ripple effects across the entire extended enterprise.

Criticality of the Venture Team - An experiential observation

An online dictionary defines "Venture Team" quite simply as:

ven·ture team (plural ven·ture teams)

noun

Definition:

team to start up business: a management team put together to establish a new business, secure financing, and execute a business plan Investors focus on the Team, the Idea, the Market and the Proposition (ofcourse ROI). While rest of the critical factors can be triangulated and planned upfront with data and minimal gut instincts, the TEAM factor is least predictable (even if the team has worked together in multiple successful ventures). In my experience, key cause of team divergence is the varying priorities among team members. It is tough to expect all members of the venture team to have the same financial backing and propensity to face lifestyle and societal challenges. It is almost impossible that the team receives equal support from friends and family. Motivational factors are also critical - With changing conditions, motivational needs of the individuals may start diverging. Extended team members are also critical to the success of a venture. Every venture depends on a variety of advisors, promoters, champions, enablers to keep the machine cranking at all times. If any of the critical path individuals drag their feet, the whole team gets slowed down if not derailed. A resilient team is one that plans backup for all critical path tasks and people (although that eats up into short-term efficiency). A successful venture team is like a flock of geese, each member playing its role to perfection and continuously rotating the formation to maintain efficiency and consistency. Easier said than done, this requires a team with an "us" EGO not "I".

Does 360 degree feedback actually work ?

Personally, I am a fan of the 360 degree feedback process. It is a wonderful way to keep pulse on the team ecosystem and to ensure that individual behaviors that hamper objective progress are adjusted along the way. However, there are factors that make this amazing process meaningless. Here are a few...

1. Open and Trusted participation of individuals undergoing 360 is absolutely critical. Most 360 processes fail because of passive conduct from participants. Feedback receivers start building defense shields (with managers, peers and reports) as soon as this process is initiated. Feedback providers see absolutely no value in providing useful feedback and hence resort to filling the blanks as a checklist

2. Absolute trust and understanding between feeback receiver and manager is paramount. There could be some comment(s) (from reports or peers) that criticize certain action or behavior without full knowledge of the circumstance/situation that the individual faced. In these cases, manager and employee are the only ones who can fully understand the background and evaluate the comment appropriately. This assumes there is a good relationship and understanding apriori, a precondition that fails most often.

3. Process (not content, ofcourse !!!) needs to be transparent to the participating group. Feedback receivers and their managers must have a choice of selecting providers. The questionnaire should be unambiguous and allow for free-form provision of supporting data. This process can be run semi-annually to gather feedback and measure corrections

4. Finally, there should be substantial period (2 to 3 cycles) of consistency in teams and reporting relationships to get correct and actionable data.

Power of Pause

A few weeks ago I thought how powerful it was to PAUSE, especially in tough or tight situations. Upon googling, as expected, there is a complete book on this specific topic. Nevertheless, let me jot my thoughts here...

Given any situation - customer meeting, discussion with your manager, complex conversations with your reports, a tricky situation in the team meeting, potential argument within family - the Pause button (henceforth refered to as '', also called 'Hmmmm') is an important tactic. The other option would be to let your intuition go beserk. The goal of is to give yourself the extra second(s) required to weigh your intuiton versus other choices that may exist.

Another important value of is the opportunity it provides to refrain from reacting to the situation. The simple act of pausing, changes a "Reaction" to an "Action". Isn't it wonderful to act instead of react? Doesn't it feel more controlled?

The next time you are cornered in a spirited discussion, try using "hmmmmm.." and observe the reaction of the adversary. I would not be surprised if that person gets completely subdued or further enraged :-)