My Personalized Agile or What I have Learned from It

I complete exactly 3 months at ThoughtWorks today. While this has been a momentous career shift for me, I may not have written a blog post on it except for the learning. Needless to say, an understanding (albeit very rudimentary) of the Agile philosophy supersedes all other learning (and that has been plentiful too).

Coming from a very traditional, waterfall-driven background replete with all the drawbacks (what I perceive as drawbacks in comparison now), it took me quite a while to assimilate the philosophy—even the basics of Agile. A dictum like “Just deliver; don’t document unless the document is going to add value” would throw me into a tizzy. Don’t we need to document so that in case a point comes when the blame-game starts (I assumed it would), we have our backs covered? Apparently not because there is no blame game! There is no one to blame. Everyone is in this together—the team, the client, and all other remaining stakeholders. 

As I mulled over these rather shocking, almost blasphemous, aspects of Agile, I thought it would be a good idea to pen down my thoughts and put them forth for inspection and feedback. And to track my understanding over time…

The original Agile Manifesto, which is my source of inspiration, can be found here. 

My interpretation of the Agile philosophy

I am trying to acquire better ways of learning and building personal knowledge networks and helping others do it. Through this endeavor, I have come to value:

Adaptive over predictive

Collaboration over documentation

Continuous feedback over periodic reviews

Generalization over specialization

That is, while there is value in the items on the right, I value the items on the left more and have found them to be in synch with what is required today to build a learning organization, an organization of motivated, passionate individuals.

Unpacking each claim

Adaptive over predictive

Ruth Clark describes adaptive in relation to expertise in her book Building Expertise: Cognitive Methods for Training and Performance Improvement, and I think it reflects my understanding of Agile philosophy very well. Being adaptive means to be flexible, open to change, reacting to situations just as the situation demands. Adaptive expertise brings open-ended inquiry to the problem and not a pre-defined solution. Being adaptive is to be always ready. In this context, I am reminded of the phrase “a mind like water” by David Allen. Paraphrasing from Getting Things Done below: 

Water neither flinches nor ignores the impact when a huge boulder hits its surface. It welcomes a boulder just like it would a pebble. The ripples it generates are in direct proportion to the size and impact—neither more nor less. Water neither underreacts nor overreacts. And very soon, water goes back to its natural state—open and clear—ready for the next impact. 

This is the state of being truly adaptive and agile. With the unknown and the complex becoming the norm in knowledge work, adaptability is the key to dealing with challenges, to be comfortable with ambiguity, and to move to a state where we are constantly learning.

As Eric Hoffer very aptly says (the highlights are mine):

We can never really be prepared for that which is wholly new. We have to adjust ourselves, and every radical adjustment is a crisis in self-esteem: we undergo a test, we have to prove ourselves. It needs subordinate self-confidence to face drastic change without inner trembling.

Collaboration over documentation

Going back to my roots in traditional organizations where documentations supersede communication, conversations and listening, I can appreciate the value of collaboration. Please note that I am not advocating doing away with documentation, but documenting only what adds value and when it adds value—to the project, to the team, to the stakeholders or to oneself. I am using the Minutes of Meetings (MOMs) as an example to make my case. 

Coming from a culture where minutes of meetings were more important than the meeting participants, I can truly appreciate the need for collaboration. Unlike any of the methodologies that fall under the umbrella of Agile, in traditional orgs most meetings are conducted as rote and many of the crucial stakeholders are missing. Hence, a stringent documentation is required to capture what transpired and to keep everyone in the loop (so to speak). Needless to say, many of the subtleties of discussions are lost, and the minutes become more of a “save our backs in the future” documents with little of value coming out of them.  

Let me take this a little further. When I claim that under the aegis of Agile philosophy, collaboration is more valued, this is what I imply. First of all, collaboration for me implies disciplined collaboration—a term popularized by Morten T. Hansen in his book Collaboration: How Leaders Avoid the Traps, Create Unity, and Reap Big Results. Disciplined collaboration is to collaborate for results. And this is precisely what the philosophy of Agile supports. Some of the quotes from the book that supports my understanding of effective collaboration are:

1. The idea of disciplined collaboration can be summed up in one phrase: the leadership practice of properly assessing when to collaborate (and when not to) and instilling in people both the willingness and the ability to collaborate when required.
2. Disciplined collaboration requires that organizations be decentralized and yet coordinated. To build this model, leaders need to detect the barriers to collaboration and overcome them without reducing the benefits of a decentralized structure.
3. Collaborative companies run on networks, those informal working relationships among people that cut across formal lines of reporting. If the formal org chart shows how work is divided into pieces, networks reveal the informal organization-how people actually work together.

Finally, a collaborative company can do away with unnecessary documentation, remain lightweight and agile because the concerned people are all in it together. Everyone is in the loop, always!

Continuous feedback over periodic reviews

This is my biggest learning from Agile. The very environment and processes—pair programming, TDD, retrospectives, continuous integration, whatever else you will—support continuous feedback, one of the keys to learning. In this environment, a mistake becomes a stepping stone to excellence. A philosophy that   centers on feedback also encourages mistakes by default. I think of these as bunkos where a “bunko” means - “to make a mistake from which the benefits of what you learned exceed the costs of the screw-up” as described in The Adventures of Johnny Bunko. Because one knows that feedback will be immediate, one is not scared to experiment, think big and explore. Imagine the reverse of this—where feedback comes in the form of yearly appraisals that tell you how many times you have screwed up far removed from the time and the context of the screw up itself. It leaves one mentally screaming, “Why didn’t you tell me earlier? How does it help now?”

Here’s one of my sources of understanding and clarity on the purpose of feedback and the way to deliver as well as receive it: Tightening the Feedback Loop by Patrick Kua.

Generalization over specialization

With the edges of our roles and jobs disintegrating, it is of utmost importance to be able to wear multiple hats. While we will definitely have our specializations (that after all is what we were hired for), this should not make us incapable of playing multiple roles. Generalization helps in a number of ways (I am referring to generalization around one’s core skills).

In a world and world economy where situations throw us into unpredictable circumstances and poses unknown problems, being a specialist with crystallized intelligence can be a bit of a hindrance. Ruth Clark in the aforementioned book talks about this at length. I have described it briefly here. To remain adaptive and responsive to changing situations, it is important to develop a fluid intelligence, one that enables us to take on the role of inquiring novices when required, which in turn helps to view a problem from different perspectives. 

To quote Ruth Clark: 

Fluid intelligence is the basis for reasoning on novel tasks or within unfamiliar contexts; in other words, it gives rise to adaptive expertise. In contrast, crystallized intelligence is predicated on learned skills…and is the basis for routine expertise. 

It is clear that adaptive expertise is the basis of being a generalist. A generalist, according to me, is one who can explore, venture into unknown territories and domain, learn from new experiences and apply that in areas beyond one’s specialization.  

My sources of inspiration and knowledge:

1. thekua.com@work

2. The Agile Warrior

3. The Learning Generalist

4. The Agile Samurai: How Agile Masters Deliver Great Software

5. Martin Fowler: The Agile Guide

6. Making software is about making people