Four stages of work

My friend and I were talking about our work at lunch today. He told me about a grid that he has come up with to clearly define 4 stages of the work. This is what the grid looks like.

Four stages of work

	Trying hard	Not trying hard
Making swift progress	Jamming	Cruising
Making slow progress	Grinding	Slacking

Most people are stuck in the 4th quadrant where they are neither trying hard nor making swift progress. My initial assessment was that the most productive quadrant is Jamming but you can’t sustain trying hard for a long period of time. The key is to be in Cruising quadrant. It’s much better for your endurance. The only problem is that it’s very easy to slip from Cruising to Slacking. The other paradox is that if you try hard not to go from cruising to slacking, you might risk getting into Jamming. The key is to make a healthy balance between not trying too hard and still being focused. It’s really difficult to that especially so many interesting things going in the workspace. Some of them are shown below


Conflict Resolution Is this really a release blocker bug ??



Enthusiasm of your colleagues



Your own desires to find your inner self

Cruise Bio

Each year my company goes on a weeklong cruise trip to the Caribbean - Mexico (or Alaska if the HR Manager is really pissed at us). Before the trip all employees are asked to prepare short bios about themselves. These bios are compiled into a small book, which is distributed among the employees as a memento of the trip. Here is my bio for this year’s trip.

---

Name: Abhishek Agrawal.

Birth city:
Etawah, UP - India. It is an overgrown village of a half a million people in the middle of nowhere

Prone to:
Frequent spells of selective amnesia

Convicted of:
2 speeding tickets and 1 for jumping a red light (and also for trying to drive through the wall). Oh yeah, once reprimanded for stealing 2 year olds ice cream.

Claim to fame:
$3000 phone bill

Talents:
Still trying to find one

Dreams of:
Making a product so efficient that customers don’t even need to buy it.

Believes:
Life is an angry bull and you are a stupid matador. You stand in its path, grab the bull by its horn and try to bring it down. The bull hurls you in the air and you land with the control of a helicopter with no gas. Even though your body is badly scratched and there is blood dripping down your face you don’t give up. You stand up once again and charge back towards the bull. The result is no different this time. You keep fighting until you are tired, exhausted and your motivation becomes that of a wet noodle. Beaten to submission you don’t know where to go and what to do. You loose all hope and THEN you make the decision of your life, YOU MARRY IT!

PIO unveiled

For people who missed the BPO wave - "Be ready for the new one!"

Extreme Programming:

Almost everyone who has ever been a part of a software development team has experienced a sense of anger, frustration and helplessness at how “things just get out of control”. Unlike manufacturing, software development process grants each person the potential to completely wreck the product cycle with an unwitting minutest intervention. Is this a person or a process problem? Why do software development projects fail? How can we alter the process of development to make it less sensitive to the actions of the people involved in it?

Appian sponsored Java Users Group (AJUG) decided to find answers to these questions by looking at the alternate software development methodologies. We started with looking into details of Extreme programming – first proposed by Kent Beck. His book, "Extreme Programming Explained" is broadly divided into three parts – The Problem, The Solution and The Implementation, each of which is about 50 pages. On a Saturday afternoon it will take you less 3 hours to go through the whole book.

Kent recommends paradigm shift in software development process. The emphasis is on designing little, implementing, testing and repeating the process as fast as possible. This is completely antagonistic with the most technology team’s emphasis on designing early and thoroughly. The book strongly recommends use of XP methodologies like pair programming, unit and functional testing, which definitely have a lot of positive points. Kent also provides a rather simple yet remarkable way of cost benefit analysis of adding a new feature during the various stages of product life cycle. Unfortunately in one and half pages the idea is bit under sold but then this is not a book about pricing software.

One of the most intriguing ideas put forth is the concept of common ownership of code. Most technology projects have core of their architecture closely guarded under the watchful eyes of their most senior programmers. Kent makes a strong case for allowing every member on the team to make any change they deem necessary to any part of the system. At first this seems completely illogical and fraught with risks, but he explains that with pair programming, automated testing and refactoring its not as perilous as one would wonder. The left liberal in me is convinced but the pragmatic one tells me that the risk involved are highly dependent on the ability of every member of the team to understand the architecture and also on the quality of the automated tests. Weakness in any of the two can end in some disastrous consequences. I have spent sleepless nights (not quite) thinking about this, but I am still not convinced. Common ownership is highly depend on the XP methodologies and cant be put to practice unless other XP stuff is working very well for the team.

Overall this book is worth every penny of its value. You might not agree with any of its ideas, but it does provide some fresh insights on tackling problems we face on a daily basis. It’s not a fast paced suspense thriller - DaVinci code, but it’s closest to that in the world software engineering. I will specially recommend it to the people who are disturbed by the chaos and confusion surrounding development of software products and are looking for more repeatable and predictable processes.

I do agree with the Kent about this -- Embrace change!

Strategy and Strategic Planning: (Henry Mintzberg)

I really like Henry's work in strategy and planning. These are the excerpts of some intersting points he made in an article I read recently.

Most successful strategies are visions not plans.
Strategy making process - capturing what managers learn from personal experience and experiences of others and the hard data from market research, and synthesizing that learning into a vision of the direction that the business should persue.
Does not involve formanl techniques.
Planning represents calulating style of managment and not commiting style of mangment.
Learning plays the most crucial role in the development of novel startegies.
Business unit managers should take full and effective charge of strategy making process.
Planners: Ask the right question ? Dont try to find out the right answer.
Strategy making process should not and cannt be formalized. Formalization hinders creative thought process, which is the the most essential part of Strategy making.

"Location" - Clusters and Competition: Michael Porter

Michael's take on Locations. This is definitely interesting. May be companies competing in close affinity is not that bad afterall.

Clusters suggests that much of the competitive advantage lies outside a given company or even outside its industry, residing instead in the locations of its business units. eg: Odds of building a world class mutual fund company are much higher in Boston than in any other location or a textile related companies in North Carolina (although I would rather move them to China).Clusters attract foreign investments. (You can build world class facilities, but without presence of conducive clusters its difficult to attract industries. This explains why efforts by governments to divert industries to specific locations has failed so often -- Butibori in Nagpur)