Why I dislike RACI

The tweet to the right is the essence of what makes some large organizations ineffective at delivering products. In gist, it tells us that the more we "officially" delineate our responsibilities the less likely we are to get stuff done.

I wasn't quite able to articulate why I didn't like the RACI. This tweet helped me. RACI permits people to abdicate their responsibility of team-work and collaboration. RACI robs its followers the opportunity to understand team work. RACI builds a culture of blame and excuses.

Paris Hilton and Management

Never pass a mirror without looking in it. This is Paris Hilton's philosophy.

The value of this mindset as a management technique, especially in Agile software, is immense.
"Never miss a chance to observe your work."
Imagine if we had this discipline to execute and manage our work. What if we extended the boundaries of our consciousness, just from ourselves, to also include the work we produce?

I am saddened every time I encounter an ecosystem that has little insight into progress/performance. Usually, there is a careless over-reliance on tools that don't paint the entire picture. A simple spreadsheet would do the trick, but the desire to be an "observer" doesn't exist. A corollary is that by the time this realization sets in, it is usually too late; fear of the upper management's wrath sets in. And, the death marches begin.

[Image taken from: http://www.timesunion.com/entertainment/movies/slideshow/Cannes-Film-Festival-Stars-in-black-and-white-86142/photo-6329074.php]

Key to Fearlessness

There're elephants in meeting rooms. There is environment of fear in organizations. And yet some seem unfazed by it and address the problems head on. They dare to have difficult conversations. I once heard a peer wonder about an individual, "Why is that some folks are fearless?" I have wondered about it myself at times. Is it their confidence in their skills? Are they suicidal? Do they not have career aspirations? I am not sure. However, there is a correlation I have noticed between their behavior and their ability to articulate. It is highly likely that the fearless amongst us are good at expressing themselves coherently. The underlying phenomenon, I think, is their ability to dissect a problem, just like peeling the onion, and the ability to make others comfortable during the process. The objectivity required in the process, which these people often demonstrate, is also the reason why they are able to get the airtime they have.

Ever since I have noticed this correlation, I strive to peel the onion. Articulation is required practice in parallel. 


[Image taken from: http://www.allposters.com/-sp/Holy-Roman-Emperor-Henry-IV-Arguing-with-Pope-Gregory-VII-at-Worms-1076-Posters_i9658287_.htm]

Project Retrospective - SOCCER format

Recently I conducted a project retrospective with a set of focus areas, which I abbreviated as SOCCER:

  • Storytime
  • Opportunities
  • Culture
  • Confusion
  • Emergency (ER)

The idea was to allow the team to focus on its strengths, gradually move to stuff that needed improvement, and close with identifying items that should be fixed right away.

Mechanics


After spending about an hour with the team building the project timeline, we summarized the project in about 10 mins. The team then dealt with each of the SOCCER categories one at a time for about a half hour each. To help generate ideas and conversation, I created a few sample statements/questions for each of the SOCCER items as under. Then the SOCCER categories were dealt in the following order.

Story-time

"When I tell a story about this project, I'll always remember …."

Opportunities

"I was productive and in flow when …"
"I would like to be included in …. "
"I think we should …."
"Why don't we …"

Confusion

"This confused me …."
"I am still confused about …."
"Why did I/we do that …."

Culture

"I was disappointed by …."
"We cheated when/because …."
"I lied or misinformed because …."
"I should have, but I didn't …."

ER

"I found this meeting wasteful …."
"In my role I struggled because …."
"Nobody seems to care about fixing …."
"I doubt that the leadership knows about …."
"I wish my leadership supported me in …."

As feedback the team suggested that I can improve the quality of questions. E.g. In the Culture my questions seem to seek only things that should be improved and not the things that are brilliant.

Verb to Noun

I mostly visualize concepts in pictures. Just as the lens in human eye inverts an image upside down, quite often this is also a reality in organizational change management. Agile adoption is a case in example. Executives want the organization to be agile (verb). Between several layers of hierarchy the vision is inverted to Agile (noun). Instead of being nimble, middle management incorporates bloat (heavy processes, templates, audits, and assessments). It is not a surprise then how many such initiatives fail to demonstrate any significant improvements. Even more painful is to see teams getting robbed of a chance to understand and experience what it really means to be agile (verb) and nimble. Rather, edicts that create more problems than it solves are abundant. Take for example the notion of less documentation. On several occasions I encounter teams that don't get what it means. Either someone is getting by without putting pen to paper (no user stories, on the fly analysis), or somebody is having to document eternal change (software design documents). I have found only one way to solve this problem. Abandon the noun approach, and adopt the verb approach. Understand the purpose of documentation and then follow some simple rules such as:
  • Document only when you can identify a consumer for the information and (s)he indicates that (s)he needs it.
  • Attempt to offload documentation to its consumer. Usually, it minimizes the need for it.
  • Maintain one and only one source for each kind of information. 
  • Make the source of information more accessible rather than create yet another incarnation.
  • In future try to do better, unless the situations warrants otherwise.
This is what being agile (verb) means. On the contrary, doing Agile (noun), would create a suboptimal ecosystem where somebody is working more than (s)he should, while the other person is not still getting what (s)he needs. And, a litmus test is when you get asked, "What is Agile's take on documentation?"


[Image taken from: http://photo.stackexchange.com/questions/21495/why-are-objects-far-away-inverted-through-a-lens-but-not-through-the-viewfinder]

Entrapments of Idealism

Have you heard of things such as "zero defect policy" and "100% unit test coverage"? Or things such as codification of every step of the process; I'm sure you have been presented copious flow charts and documents that state the obvious. Take for example a group that I was engaged with. In their Definition of Done for a user story, which was about ten bullet list long, one item is 'Code Complete and Compiling'. I call this situation the entrapment of the ideals. These idealisms are taking joy out of work. Not that they are incorrect. It is that they generate emotions, which sooner or later breed cynicism, kill improvisation, and create bogus work that is sometimes euphemistically knows as diminishing return. Environments that don't take corrective action to curb such tendencies create a culture of pluralistic ignorance. Individuals are aware of these absurdities but stay silent to avoid being tattooed as bigots. The operating delusion is that this idealism is helpful in strengthening the capabilities of an organization. 

In the bunch of things I'd like to mix in a workplace stew, pragmatism would be my number one choice.


[Image taken from: http://ryandow.com/ic/2012/07/26/pragmatic-dreamer/]

My Interpretation of Agile Practices and Artefacts

Some of you who have heard my opinions on Agile practices, artefacts, and mindset have asked for the slides. As much as I hesitate to share without being able to tell the story, I understand that you probably remember some of my views. With that caveat, here are the slides:

   Hello Agile    User Stories    Agile Estimation
   Release Planning

If you are unable to access these, please don't hesitate to drop me a comment. 

In the Crucible of Learning


In an Agile adoption program, who do you think is socially affected the most? I would say it is the Scrum Master. This role is exposed to the most variety of topics; areas as diverse as social, political, technical, product, tooling, and administrative. Using crucible as a metaphor, it is usually the Scrum Master who is to be found in it.

A well-executed adoption, usually, leads to a transformation. At least it becomes a poster child for the transformation that may follow. In rare cases where transformation has happened, there has been one more group in the crucible. It is the middle management. In one of my previous posts I mentioned how management tries to avoid pain of change programs like Agile adoption. 

The reason Scrum Masters and middle management gets dragged into the crucible is straightforward. For the Scrum Master it is the focus and scrutiny of the team(s). It requires an elevated level of maturity, self-awareness, self-confidence, and sense of security to be able to withstand constant scrutiny and absorb rapid feedback. In case of management, it is the pressure to placate and insulate the drivers of change (team) from the believers in status quo (upper management). Perhaps it is the pressure to deliver instantly on the investments in Agile. The notion that teams will pay an initial toll in velocity/throughput as they learn, implement, practice and relearn new concept is unacceptable to the senior management.

It is valuable to be aware of this dynamic. It helps you plan the learning cycles. But more interestingly it provides some litmus tests to see you if you have the right people as Scrum Masters and sponsors. If Scrum Masters can't adapt fast enough and managers avoid coaching, then the writing is on the wall.

Image taken from: http://en.wikipedia.org/wiki/File:Melting_crucible.jpg

Got Strategy? Sense the Shift?

What services, products, and innovation do we need to sustain a business in the future? Usually, these kind questions are a bailiwick of Strategy within a corporate. What organization skills do we need to make Strategy relevant and effective in an organization? Ahem! Is the CSO around?


Avoid a Strategy of Imitation

Many organizations are knee-jerk reactionary. They sweep into action because a competitive situation has gained significant momentum. A good example would be the movement to have 'Social' presence. How you will monetize it, you don't know that yet. 'Big Data' is treading the same path. Beware!


Strategy is Social

Most workplaces have low tolerance for seemingly irrational thoughts. The reality of markets that these organizations play in, however, are indeterminate, delimited, and sometimes arbitrary. This juxtaposition is frightening. Those who are aware of it design organizations that are unconventional and innovative. A significant difference I have noticed in such organizations is that strategy is not confined to a department. That doesn't mean somebody doesn't have a title with "Strategy" in it. The point is that the energy, awareness, responsiveness, and the entrepreneurial spirit are at a much elevated level compared to the rest of the industry. Some refer to such organizations having a different DNA.

Choose the Contradictions

How is the blueprint of these organizations different?
  • Employees understand how the reality of the future will mutate much faster than today, and embrace it.
  • These folks think in terms of "what if" and "why not'.
  • The organization has built a tolerance for spending time in seemingly "wasteful" activities such as some-work-some-play, sustainable pace, innovation games inspired meetings, etc. 
It is surprising to me how many leaders are unable to take the very first steps to experiment with these contradictions. Of many a things hard to comprehend from the books, this one would make it to the top of my list, a sea change in thinking.


The more time I spend in consulting, the more I realize that Technology won't be a differentiator for the organizations in this decade, especially for large companies. The onus for success has rapidly shifted to Business and management style. In the complex relationship between the two, the ball is in Business' court.

[Image taken from: http://www.brandingstrategyinsider.com/images/2013/03/Brand-Strategy-And-Social-Media.jpg]

A Gift of Obamacare Rollout

Like many technologists, I too delivered my share of smirks and sarcasms at the failure of the
Healthcare.gov website. As somebody who has experienced such service roll-outs first hand, it is unimaginable that a vendor would be so careless/reckless with an initiative as significant. How could that have happened? In this day and age when software can land a rover on Mars, a website buckling under its design load should outcast every technology "expert" involved. This poor design should have been disclosed earlier in the website's existence. As comical and theatrical as the senate hearings on the subject were, there's an element of sincerity in them. I wouldn't have reacted too different from how the lawmakers did.

In all of this mess, there is a silver lining. In the last two or maybe even three decades this has probably been the only time when Capitol Hill has summoned, on it's floor, a hi-tech company and reprimanded it. This was a much needed course correction. I think, it will improve the quality of solutions built for the government of United States, albeit at the cost of cost. History will remember this fiasco as the turning point for quality of government IT services. Not a bad bargain for $400 million, if you ask me.

Image taken from: http://www.foxnews.com/politics/2013/10/28/obamacare-developer-cgi-federal-also-won-bid-to-help-with-federal-sandy-funds/#

Drill Sergeant in Corporate America

If we had drill sergeants in some of large corporations, here's what, I believe, their admonition will be:

You're doomed and here's why.
  1. You are aware of the People, Process, Technology trifecta. Why don't you have a people development backlog?
  2. You're thinking of scaling Agile when you should be focused on scaling creativity. 
  3. You seem clueless when I tell you that your business is about to go bust in the next decade.
  4. Your customer is looking for a product and you can't seem to get out of your collegiate departmentalized organization model; quality assurance, development, and business analysis. Your mobile organization still thinks in terms of devices - Android, iPhone, etc.
  5. You don't consider your IT to be a partner in managing the P&L. But you expect the 'ITcians' to be a better custodians of your dollars and understand value.
  6. You seem to believe that you have learned all you could. Your daily schedule has put you in a place where you have ceased to learn. No wonder you choose command over conversation.
  7. You're biased for conventional success. So are your managers. 
  8. Speaking of managers, that individual is exploiting your being. (S)he is not interested in what you want to become.
  9. Your boss got you an Agile trainer. But you didn't suggest that your boss get an executive coach. You didn't, right? So you don't even provide feedback. Guess what you aren't getting from your team. 

One more thing - pull down those credentials from your office walls. That's a good School of Business but you didn't register for the right classes. So, next time you see your friends and family, tell them you're doomed. And now you can get back to placating your nemesis and pleasing your bosses.

Is your Mechanic ASE or I-CAR?

You don't know, do you? It, probably, doesn't determine your choice of a mechanic.

That's an important commonality between you and the Ozone (CxO) at corporate, when it comes to decision making. They don't care if you use Agile or Waterfall in your shop, just as you don't about your mechanic's choice of methodology. It is important to be at peace with this reality. I recently participated in a LinkedIn discussion, where quite a lot of folks clearly didn't understand this mindset of executive management.

Ozone is primarily occupied trying to figure out how their organizations can:
  • Deliver more,
  • React and respond to markets better, and
  • Build a competitive advantage.
Quit selling Agile and start solving their problems.

[Image taken from: http://www.claudereynoldsinsurance.com/img/~www.ClaudeReynoldsInsurance.com/Blog/finding%20trustworthy%20auto%20mechanics.jpg ]



Political Infrastructure of Change

Leaders and managers involved in change programs cherish the notion that merits of their new vision will speak for itself. More often than not, change requires more than just its merits. Neither the effectiveness of technology nor the promise of its empowerment guarantees success. Matter of fact is that cognition of merit, like experiences and learning, is subjective. ( Rob Legato discusses how he experienced it while recreating the Saturn V launch sequence for 'Apollo-13'. ) No wonder sometimes others don't agree with our insights. We expect truth and facts to prevail, but the triumph of insanity and imprudence is a story repeatedly told. Moments like these are frustrating. An eerily familiar comment sighed, "It's politics." I believe that political infrastructure should get as much of a leader's attention as technical. Given the lack of exposure to it, I'd even go as far as to say that development of the following capabilities should take precedence for a leader:

  • Politicking. Political and organizational talent is a must to successfully implement change. We, usually, learn skills and trades like software technology and operations management. Seldom do we learn about politicking. Concepts such as trust, hope, suspicion, and despair aren't in any high school curriculum, as far as I know. Let alone illusion, delusion, disillusion, and wisdom. Interpretation of optimism, content, and pessimism is another area of deficit commonly observed in executives. In my experience of working with some effective leaders, I have clearly noticed the link between their sharp politicking abilities and an awareness of the concepts mentioned above.
  • Story Telling. The art of story telling is widely admired in leaders. A lack of it is often the first thing people point out when they talk about lack of leadership. Steven Denning has written extensively about it in his book The Art of Radical Management. Stories that promote optimism, a desire for drive, add context and perspective to situations, define reality, tell the truth and, paint a future are the grease of a  good enterprise. Story telling is key to building the flexibility for change in an organization.
  • Reasoning. This one is the most surprising of the three. Not because of the lack of it, but because of lack of time for it. Reasoning to build right mental models is an imperative. These mental models serve as memes, which fuel the engine of change. An example of lack of a weak mental model would be confusing unity with uniformity. It is a common trap most change managers fall into. Subconscious expectations include, amongst many, a desire for uniform application of vision across the board. That often rubs the 'subjects' of the change the wrong way. It appears to insult the intelligence and curtail freedom at work. There's not much freedom left in a modern large organization. It seems to me that most change agents end up fighting over uniformity when they should be focused on building a unity for their vision. This is an example of a poor mental model that leads to a wasted opportunity. So, take time to think yourself and promote reasoning in your staff. Mental Models are the equivalent of genes in an organization. Spread good ones around.

[Image taken from: http://workplacepsychology.net/2010/02/05/implementing-change-and-overcoming-resistance/]

Psychology of Pseudo-Agile

At every encounter with a struggling and sullied Agile stroll, I have seen a group of managers trying to look good. Their troubles began with the rising social pressure of adopting Agile. Or, an edict from top management. Around them Agile exists in name only. The obvious dis-ingenuity raises a question, "What drives the improvident behavior?" In the composite of emotions, the following stand out:
  • Fear and stigma. Accepting and tolerating failures is not everybody's disposition. With failure comes stigma. Agile doesn't bear fruits day one or even in the first attempt. Combine the two, and avoiding (a change to) Agile makes sense. Rest is self-explanatory.
  • Pain avoidance. Middle management is often the point of friction within an enterprise. It's the layer that tries to insulate the drivers of change from the believers in status quo. It is emotionally painful. Remember, change provokes sensations of physiological discomfort?
  • Strong Beliefs. Humans have strong beliefs. We also have information. However, we an uncanny ability to pick beliefs over information.
These emotions lead to an environment of:
  • Defensiveness. A reluctant and half-hearted pursuit of Agility usually draws a ton of criticism. It's just how humans behave, specially as a change seeking mob (software development teams). This puts the managers on the defensive. Ironically, defensiveness is recursive. 
  • Distortion - Often the tactics managers employ to keep the opposing interests of their teams and their bosses under control.
  • Cognitive Dissonance and Bigotry - Distortion slowly widens the gap between the beliefs, messaging, and actions within the management circles.
  • Herding - Negative outcomes of cognitive dissonance eventually lead to embarrassing state of affairs. Denial prevails and the brave choose to coverup. Risks are hedged and the "like-minded" coalesce. Panic breeds packs.
  • Political Jostling - Groups start to joust, which then inflicts its punitive tax on Agile adoption. 

Final Thought

Any large group of people (organization) is fraught with political challenges. A lot of us disapprove of the politics; some shy away, others dismiss it. Meanwhile politics doesn't stop its play. It frustrates even the best of us. What if we dealt with politics like any other problem? Could it be that politics is a veneer of some underlying and innate fears? That would change your perspective, wouldn't it?


Image taken from: http://www.buzzle.com/articles/branches-of-psychology.html

Agile and Beyond 2012


Agile and Beyond 2012 was a sold out event with about 650 attendees. Great Keynote by Steve Denning.My session on 'Agile Pathologies: Backyards of Agile Shops' was well received. The slides are available on Slideshare here or you can see it embedded below.

I was surprised to see the vibrant Agile community in Detroit. Had no idea, it is so big. Thanks to the organizers for a fabulous event. Well done!

Practices or Mindset: An Observation for Agile Adopters

"These practices are not suitable for our environment". "Let's shoot for as well formed backlog as we can". The difference between the two individuals is that the former is thinking of practices and the latter has the mindset.

What's the big deal, you ask? The subtle difference results in an order of magnitude difference in morale during execution. Your metrics, very likely, are a reflection of this nuance. And, in case you have ever wondered, these metrics then become the perfect medium of spreading the culture around; both good and bad. The "practices" crowd also worries about if they are executing as per the "textbook" or not. The differences are analogous to 'one size fits all' versus 'one size fits none'. Dogma and pragmatism are the other polar pair that come to my mind.

I intend to keep a log of how the practice-mindset subtlety manifests. Expect an update coming. Please don't confuse this topic with my earlier blog on Lean and Agile.

[Image taken from: www.smallbiztrends.com]

Signatures of Distrust in Agile Teams

Trust is one of the key attributes of any successful agile team. Its lack hurts the velocity and increases the stress level in members. This, in most cases, is unsustainable. I would recommend a thesis titled, 'The role of trust in strategic alliances' (Michaela Weinhofer, June 2007. Baltic Business School, University of Kalmar, Sweden). Two simple definitions of trust from the references in the thesis are:
  • Combination of credibility, predictability, and straightforwardness, and
  • Decision to rely on another party under the condition of risk.
The cooperative relationship required to achieve a common goal can hardly ever be built with distrust. The reason I say "hardly" is because experts (referenced in the above thesis) think cooperation and trust are independent entities. The relationship may be cooperative but not productive. I would also highly recommend The SPEED of Trust: The one Thing That Changes Everything by Stephen M. R. Covey.

For an agile team, how will you know that you are in a distrustful relationship? Here are some symptoms:
  • Perpetually prioritizing new functionality over defect fixes.
  • Continuous scrutiny of velocity, deep interest in individual developer velocity, pressure to sign-up more points than velocity.
  • Questioning story estimates beyond a reasonable limit.
  • Avoiding story splits fearing 2 plus 2 won't add up to 4.
  • Comparing actual effort to estimated effort.
  • Key leadership (technical and non-technical) entrusted to non-team members
  • Attempt to pile-on stories mid iteration in the interest of getting more done.
There are many reasons contributing to above situations. It could be lack of awareness or lack of experience with Agile. But don't discount the possibility of distrust as a driver.

[ Image taken from: http://www.rockwerxclimbing.com/3292.xml ]

Guilty of a Process Diagram - Don't be, just be Smart

"Let's not get this process too heavy", "We'd prefer lightweight over the traditional heavy". Everybody has got process diagrams, even in the Agile sphere. You don't believe me? Ask any Agile manager and you'll get at least two; a defect triage process diagram and an iteration lifecycle diagram.


Replacement for Common Sense
You probably have a process diagram that you loathe and scoff at. Usually processes are proposed and adopted to replace common sense and then, even worse, compliance is monitored. If you have to have them, processes should be guidelines to remind folks of the steps and sequences in case there are doubts. The idea should be to provide support to those who need guidance; beginners or occasional troubleshooters.

Analogous to an Elevator Pitch 
Based on observation (haven't come across a research on it), I have concluded that most people prefer simple processes but fall in the trap of creating complicated ones. That calls for a couple of rules of thumb:
  • Start so simple that you void the decision box. If you are using decision boxes, chances are you are in the realm of questioning people's common sense. 
  • Expand a process area only when team members are missing the boat. If team members repeatedly fail to execute a certain step, question its need first. 
In gist, a process diagram should be a very high level happy day path free of clutter designed to handle unhappy day scenarios. An analogy for a good process diagram is to an effective elevator pitch; crisp, clear, and simple.

It is important to understand the 'why', specially if you have to innovate. And if the 'why' is clear, there's no reason you'd ever stand complicated process diagrams.

[ Image taken from: http://www.basement.org/2005/12/weird_naked_white_collar_guys.html ]

A Case for Enhancing the Agile Triangle

The Iron Triangle (Project Management Triangle) is an antithesis of Agile mindset. Jim Highsmith recognized it and proposed the Agile Triangle. It seems that the value vertex, releasable product, is still narrow in its focus. It is talking just about product/service value. It is restrictive to only customers and shareholders. How about Employee/Team Value? Or, even intermediary value focused on enhancing the core environment and sharpening the saws. For better software, we ought to think of empowerment, leadership and mentorship.


I want to make a slight modification to Jim’s triangle and add Intermediary/Internal value to the Value vertex. We just can’t ignore that anymore. That’s how continuous improvement happens. That’s when you take time out and act on retrospective tasks. That’s when functional product ownership balances itself out with technical product ownership.


An Agile approach to product delivery encompasses enabling the people and infrastructure. We just can't think at the project level anymore. We ought to start focusing on the whole organization. It is untenable to continue delivering external value without investing in internal value. The risk of not doing so is to put continuous improvement on the back burner.

A new normal, but a bad normal

In the last few years, I have been focusing on Agile Pathologies. My thesis is that as individuals we exhibit certain patterns of thinking, reacting, and politicking that usually impede Agile adoption. At times it is outright contrary to what Agility is all about. We can blame the tools, spaghetti code base, team distribution or whatever else you have, but Agile adoption is a people challenge.

A few in the industry discounted my views. Some examples:
  • "People behave in fairly predictable ways."
  • "That's within the realm of normal human response."
  • "80% of projects fail because of lack of attention upfront."
We are considered knowledge workers and supposedly can intelligently deep-dive to fix our problems. Under this misconception, we have built a culture of band-aiding the broken bones when it comes to people issues. This is the new normal, but it's a bad normal. 

With Agile manifesto, the software development community for the first time officially declared people to be more valuable. If we really believe that, we have to try hard to identify a pattern in people problems, and address their root causes. Or else the debate will not cease, “Is Agile the best way to write software, or is it the way best people choose to write software?”

Just as any good constitution or a body of law isn't of much consequence without understanding the basic principles and right execution, so is Agile. By execution, here, I mean responses to emerging problems and situations. Good Agile environments need relentless focus on improving people issues. More importantly, they require that we are hawk-eyed in spotting pathologies.

[Image taken from: http://www.zimbio.com/pictures/UXs56SKql2q/Italian+Team+Training+Session/3EfoOAs1Rqt/Marcello+Lippi ]