Portrait of Agility

Pockets of Agility Numerous Agile adoptions are identical but few bear success. Reasons are simple; change agents ignore the "humanics" and are often reluctant to make Agile the central philosophy of the enterprise. Pockets of experimental runs produce some compelling results that can be attributed to the purposeful rigor that Agile instills. Some observations about Agile:

• Its rigor is almost an asperity to some,
• The "just do enough" philosophy seems counter intuitive to software "engineering", and
• Its lightweight nature makes the optics of Agile ad-hoc.

For the above mentioned reasons, it is sometimes difficult to scale. To make matters worse, several Agile adopters still lack the will to formulate a strategy to scale. Organizational momentum of multi-year product development plans and cultural inertia are formidable challenges. (Interestingly enough, it is these very environments where I have also seen Centers of Excellence and Communities of Practice on Lean. This goes back to the problem of disconnect that still exists between Agile and Lean.)

The root of the problem, I think, is that Agile proponents haven't clearly answered the question "What's in it for me? Why should I conform?". The business case for Agility attempts to leverage the "better quality working software faster and frequent to market" and "adaptability" propositions. So What? What's in it for me if I belong to a testing organization in a ten thousand people organization that is regulated and has little competition? Why should I care about Agile? This is purely a "humanics" issue. And, it shouldn't be a surprise that even the C-suite has the same question. They didn't "grow-up" with Agile, afterall.

A critical insight that Agilists, including me, get into and grasp a little late is the desired composition of stakeholders to succeed. This vulnerability has single-handedly and more definitively caused more Agile adoption failures than anything else. The pithiness of Agile value proposition hasn't reached the board rooms yet, as Lean in manufacturing has. It'll be a while before Agile recommendation are dusted off and looked at seriously. In the interim, the Agile community is focused and busy honing the mechanics of Agile. It is steadfastly employing the technical infrastructure of Agile in project teams and training the minds of future. Projects are still aborted and hopes are still dashed. The onus on the Agilists now is to come clean on the extent to which Agile can provide benefits and what to realistically expect in absence of or inadequate "air-support".

As mentioned in one of my previous posts, Agile has ceased to be a technical challenge. Growing aspects of its social challenge pose a bigger uncertainty and pale the technical complexities. The current frustrations aren't as much around the capability development and mechanics of Agile as they are about the value system. Discussions on scaling are heavy on the people side of issues. We are slowly seeing a trend where sustaining Agile is becoming a psychological art. There are some people who are cut out for Agile, others simply are not. "Agile is not a skillset, it's a mindset", as one ThoughtWorker says it. With that lay of the land the question becomes even more important - how do we scale? What's the people strategy for those who don't have the Agile disposition? A good deal of intelligent and responsible attention has to be given to why some hold an unfavorable disposition to Agile and how can they be favorably persuaded. The answer, it seems, lies in self-awareness of the teams. 'Self-directed Team' has been a long standing notion in the Agile community, albeit somewhat confusing and misunderstood. Before being self-directed we need the teams to be self-aware of what's unfolding around them; their impact on project(s), where's their stock with the management, and their contribution to long-term technical capability-development. Without answers to these questions teams cannot be self-directed.

• Connect team's vision with the corporate vision and tie team members' aspirations to the vision. This would answer the question, "What's in it for me?". Managers should complement the Scrum Masters in ensuring that they clearly communicate to team members what they stand to gain from the transition and the skills they'd build.
• Next up, I'd recommend an old trick that works most of the times. Stop selling Agile. Instead, start asking why Agile would not work. Ask it often and induce people to think about it. Focus their attention on Agile as much as possible.
• Teach people something about Agile at every opportunity you can find. Remember, focus is power, expectation shapes reality, and attention density shapes identity. Use the powerful conduit of education (conferences, guest speakers, etc.) as a means to persuade. A word of caution here though. There's a stark difference between education and training. Don't undercut your returns by mere training people; it won't last long. To create an environment of learning and bring a lasting change engage industry experts who see themselves as instruments of cultural indoctrination as opposed to just trainers.
• There always are some who don't absolutely embrace new concepts and systems. Then there are also a few who just don't get it; like I don't get Quantum Physics. Find these people something else to do. Get the ones who understand and are passionate about Agile on your teams. Yes, teams are formed; they don't happen by chance. Don't be timid about team formation. This is a controversial thought employed too often and creates havoc for so many careers. More on it in later post(s).
• Don't go piecemeal with Agile Adoption on a project. There's no such thing as setting up the right Agile management structure (Scrum) first and then introducing the engineering practices (if at all on a project). This will frustrate people and signal a half-hearted and fearful leadership style.

This list is far from all-inclusive. A cursory study of the partial list is sufficient to support the argument that planning for success should prepare the participants to deal with variety of mental states, outlooks, and behaviors and not just tools, technologies and processes.

Agile has come a long way in the last decade. It now has a foothold in the mind of leaders, innovators, and strategists. It's popularity is growing, but so is the list of failures with Agile adoptions. The long trial-and-error phase is over and we are entering into a phase of trial-by-masses. Soon (5 years) the polarity of Agile acceptance will increase manifold - a quasi-official product development approach at some places and banished from others. Illusions and myths will follow. Humanics will, very likely, emerge as a pivotal factor. Agile adoptions with a pure-play technical focus will languish unless the change agents demonstrate good knowledge of the accumulated humanics lessons and leverage them. Image taken from: http://designbivouac.typepad.com/designbivouac/images/dresden_8.jpg