Portrait of Agility

Tuesday, January 26, 2010

Building an Agile Ship - A Taoistic Approach

Big challenges in building agile teams, in my recent experiences, have come not from lack of Agile knowledge on team's part. They have come from a lack of co-operation that the team members have demonstrated within the team. Seemingly unrelated frustrations like team member's tuning out of critical meetings, not being able to learn new concepts, and even bigotry can be attributed to lack of co-operation. Strategies that I have successfully utilized to increase cooperation, which comes at premium, are:

Focus for Agile education and practices should be on all the roles including managers. By design, most focus of education and coaching should be on hubs that have the most nodes connecting to them. Those are typically managers in teams. In addition to setting the right precedent of leading by examples, managers then set the reciprocation cycle in motion.
Select an Iteration Manager (IM) who sees the role as a challenge, views it as a progression, and is an early adopter of new concepts in general. This will keep the energy level high in the team, and catalysis will keep the team going.
Choose a person that is closest to the team and is liked the most in the team as the IM. In cases where outsiders are the IM, the role should be transferred to one of the team members as soon as possible.
Keep the team size as small as possible. Small teams are most likely to exhibit voluntary cooperation, which increases as communication increases.
Consider a person's personal threshold to adopting a new mindset. It is usually difficult to enable a team of 15 people for Agility with one Agile coach. A few coaches interacting with the team as opposed to just one or two is likely to be compelling enough for potential adopters to give Agile a try. Teams should be seeded with enough critical mass of Agilists who can weigh in on Agile topics, demonstrate the benefits, and convince the skeptics.
It is critical to recognize that learning is a co-operative activity. I have discussed the importance of Socratic methods to enable Agile teams in one of my previous posts. If there's not enough bandwidth of coaches, satisfying Agile adoption in a team is unlikely.
Assemble a good team to start on the Agile journey and learn the right lessons; good or bad. It is extremely important to "design" the Agile team as opposed to starting with just any. This is in line with Maslow's "growing-tip statistics". Maslow asserted that it is the growing tip of the plant where the greatest genetic action takes place. He leaned towards studying and focusing on the best. I paraphrase:

"If we want to answer the question how tall can the human species grow, then obviously it is well to pick out the ones who are already tallest and study them. If we want to know how fast a human being can run, then it is no use to average out the speed of a "good sample" of the population; it is far better to collect Olympic gold medal winners and see how well they can do. If we want to know the possibilities for spiritual growth, value growth, or moral development in human beings, then I maintain that we can learn most by studying our most moral, ethical, or saintly people."

These strategies will solve a few key problems that we observe in environments starting to practice Agile. These are environments where the propensity for Squirrel Agile is high. Bad and selfish proclivities like wanting to be Agile without being Agile are common. Other such common regressive behaviors often include:

Free Riding - Some team members get by without participating or working to make teams agile
Lack of commitment - Dismissing Agile from the get go or losing faith too early
Lack of discipline - Teams cut corners and don't follow the agreed upon practices
Lack of initiative - No one steps forward to carry out tasks, e.g. daily standups not held because Iteration Manager was out
Contingent co-operation - I yield this much of my "comfort zone" to you, you cede some of your Agile practices to get my co-operation

Some design principles addressing the above issues that I have followed for Agile teams are:

Define clear boundaries. On one of my projects at a large corporation we drew a virtual garden wall around the project teams. It was clear to every stakeholder which people were in an Agile project and which were not. The folks within were to a large extent insulated from the business-as-usual outside of the garden wall. Ideas still permeated through the wall and people from outside could peek over to see what the Agilists were doing. But it was evident to everyone the teams withing the garden were different and they were experiment with news approaches of operating.
Rules should match the team's needs and conditions. Agile teams should be able to adapt the rules of the game to match their needs and organizational environment. On a project that had unsustainable meeting schedules, we reduced the frequency of some meetings, recommended increasing the details of some documents so that distributed teams can get more of their questions answered. The latter goes against the conventional wisdom of Agile, but it suited the needs of the team.
Individuals affected should be able to change the rules. Agile teams should be able to form the rules for themselves. Changing rules should be a mutually co-operative endeavor; not a decree from senior managers or external consultants. External authorities should respect rights of the team members to devise their own operating principles.
Leverage reputations. Reputations are often the most powerful tool to utilize. On one of the teams that I worked with, I went out of the way to find out who's respected and valued for what in the teams. The next obvious step was to connect their passions with project tasks that needed to be accomplished and had them sign-up for these task in the team's and stakeholder's presence. This practice was then transitioned to the retrospectives and sustained there for iteration level tasks.

The temptation of changing a team and radically altering how it works is too great for the Agile coaches to resist. It gets complex as the purview of a coach increases and the size of the organization gets bigger. There has to be a reason, almost always, why seemingly bureaucratic processes exist and are followed in client organizations. Often such elaborate "processes" are the communication mechanisms and the eyes and ears for the leadership into what's going on in the company. Such processes are central to governance. It is wise to acknowledge the fact and evaluate how it can be adapted (not rooted out) to accommodate Agile projects. An approach to introducing and experimenting on Agility with this mindset is better suited to generate co-operation from the traditionalists in large environments. Image taken from: http://commons.wikimedia.org/wiki/File:Tao_character.svg

Monday, August 31, 2009

Humanics - The Next Frontier of Agile Adoption

Agile is a reusable and, for most part, a transplantable strategy. It's easy to replicate, simple to understand and well socialized. It is comforting to those who have successfully adopted it. Yet, to others it is elusive, at best. The discrepancy between adoption rate and success rate is stark.

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.)

What's in it for me?

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.

Success requires Heterogeneous Audience

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".

The Psychological Art of Agile

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.

Conclusion

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

Thursday, January 8, 2009

Mindful Change - Beyond Behaviorism and Humanism

My last post discussed steps to sustain the goodness introduced by a transformation. As an abstraction, introducing Agility is an organization transformation (OT) process - an important one in software industry. The famous trifecta of any OT initiative is People, Process, and Technology. People first!

Leading people to change in order to transform an organization into a more efficient, productive, profitable, pragmatic, and agile business is tricky and often left for the very last. At best, I have seen managers read and recommend literature that deals with behavioral science - psychology, organization theory, and sociology. I always felt that this is not enough, although far better than not being cognizant of or sensitive to people issues or using brute force for business transformation or in OT.

Recently, I read The Neuroscience of Leadership , which is an excellent primer on the next frontier in organizational transformation - cognitive science. This writeup concludes that, and I quote:

Change is pain. Organization change is unexpectedly difficult because it provokes sensations of physiological discomfort.
Behaviorism doesn't work. Change efforts based on incentive and threat (the carrot and the stick) rarely succeed in the long run.
Humanism is overrated. In practice, the conventional empathic approach of connection and persuasion doesn't sufficiently engage people.

The next three points, which can be treated as prescription are significant. Again, I quote:

Focus is power. The act of paying attention creates chemical and physical changes in the brain.
Expectation shapes reality. People's preconceptions have a significant impact on what they perceive.
Attention density shapes identity. Repeated, purposeful, and focused attention can lead to long-lasting personal evolution.

What does this mean for OT practitioners?

The first message is that behaviorism and humanism can be and should be leveraged only so much. Second, if change is pain then it should be done as fast and as quickly as possible. I prefer an orderly big-bang; a carefully spreaded out step-by-step rollout will not only delay the reap but agonize the people too.

Onboard OT teams with 'right' people. There's those who can see themselves operating in a new and better environment, and then there's those who are extremely comfortable with status-quo. The latter are a detriment to change initiatives.

How could change be lead by people who don't know why they are changing and for who? OT leaders and participants should also nurture a vision to make their services/products more competitive. The expectation to make services/products more appealing for consumers and the business more efficient and productive is essential for OT success. Also, include people from different functions of the business - marketing, accounting, project management, customer service, to name a few.

It takes multiple sessions/workshops for people to understand and remember concepts. The root cause is not participant's IQ but their lack of focus and sometimes the learning material not being insightful enough. 'Induce others to focus their attention on specific ideas, closely enough, often enough, and for a long enough time.'

I don't know of any successful transformation that was a one man show, even if it was glorified as such by media. Transformations and turn-around are executed by teams that have a critical mass, the appeal within the organization, and the know-how of the business. Hence, OT initiatives will not be successful unless change is perceived to be necessary by others. Therefore, embarking on a OT journey can be a decision that a CXO can take, but the demand has to be generated from the bottom first. Invest in creating an environment where this demand gets generated. A good consultant would know how to get there.

Image taken from: http://watarts.uwaterloo.ca/~celiasmi/images/brainclimb.jpg

Thursday, December 11, 2008

Recipe for Agile Sustainability - Don't Forget Process Irreversibility

So, you adopted Agile in the past. It was also a success by your yardstick. Sustaining Agile transformation, however, has proven out to be a challenge. There's also challenges with scalability.

It's not an unusual challenge. As with any change process, Agile transformation requires checks and balances with an eye on building process irreversibility. Only then would I consider an Agile transformation/adoption to be really successful.

Balanced Teams

Amongst the building blocks of Agility are Teams. An often overlooked component of teams are people and their inclinations. There's often members in Agile teams that are of traditionalist persuasion (some of my colleagues call them Skeptics, although I disagree with the term). They can't be convinced and changed despite overwhelming evidence (which distinguishes them from Skeptics); that's what makes them traditionalist in the first place. The idea is to balance the Agile teams out with Generative Thinkers - those who can model their business and processes with innovative practices.

Balancing teams out is the first step towards process irreversibility. Some other steps are:

Individual Retrospection: In one form or the other a question I often encounter is, "What'd you focus on in a team that is already Agile?" Individual Retrospection is always top on my list and is an offshoot of sustainable pace. It is not the same as team retrospectives. If a team has a sustainable pace, its members will have time think about what they are doing and how they can improve it. Individual retrospection is highly undervalued in the industry and often has a negative connotation. Traditionalists interpret it as underutilization of resources. It is considered elitist and a privilege of managers.
Meeting Facilitation Training: Sliding back into old ways of doing things is common. Teams often loose steam which results in bad behavior creeping back in. Meetings are the first to suffer. Lack of attendance, lack of focus, too many meetings, and a general confusion about the objectives of meetings are some of the first signs of old ways creeping back in. Team members trained in meeting facilitation skills and techniques prevent this backsliding.
Metrics and Reports: As in any change management system, there's got to be reason why Agile was considered. Those reasons should be tracked using some metrics by the management. Agile also recommends some metrics that should always be tracked, even if they were not on management's radar. Success of Agile adoption should be measured by these metrics and nothing more and these should form the Agile Dashboard by which business should be run.
Agile Evaluations: A good management practice associated with Agile rollouts is periodic Agile evaluations. The focus of the such an evaluation is on different aspects of Agility, e.g. Responsiveness, Simplicity, Configuration Management, and many more. .
From Flavor of the Month to Business As Usual: The more seasoned a team member is the more compelling it is for them to continue being who they are and to follow practices that have made them successful. There's quite a few other team members who want to be like these successful Einsteins. Emulating their stances is only natural for the less experienced. That's the DNA of a corporate culture. Convincing the Einsteins that Agile is not a flavor of the month but here to stay and soon to become a norm, is paramount. This message should be loud and clear.

Agile allows team members to participate and control their course. At the same time it requires discipline. There's no magic in Agile that makes it ceaseless, unless process irreversibility is intentionally designed for its adoption.

Monday, November 24, 2008

Consulting Tools - Thinking, Modeling, and Inquiry

Ever wonder what tools make a consultant effective? It may be a long list. If you read The Opposable Mind - How Successful Leaders Win Through Integrative Thinking, it is obvious that consultant would benefit from most of the process techniques that Roger Martin talks about in this book. The three that stood out for me are:

Generative Thinking - Pondering along the lines of 'what might be'
Causal Modeling - What causes Something, and what's the purpose of that Something
Assertive Inquiry - Asking questions that encourages dialog, rather than shut it down

The Process of Thinking and Deciding is a good revelation of how a lot of us reach decisions. Recollecting my interactions on past engagements, it is quite obvious that these patterns have serviced me well. I was, until now, unaware of their interdependence and collective power.

Going forward, it'll likely serve me as a good framework for interviewing candidates who aspire to be consultants. I have never been subjected to an interview myself where someone tried to assess these skills. That clearly demonstrate how much little we understand and value the utility of these tools in our professional lives, or so it seems.

Image from: http://www.childcareaware.org/images/category_icons/tools.gif