Beware of Next in Line

Agile teams typically follow one of the following three patterns during their daily standup; randomround robin, and story-time. I would guess most do not find randomness productive. When it comes to choosing between round robin and story-time, most of us choose round robin.

In round robin pattern every individual on the team answers three questions; "What did I do yesterday?", "Where am I stuck?", and "What do I plan to do next?". Round robin has a hidden cost; stitching up the individual daily progress narratives to understand an individual story's progress. Recently, I discovered a way to express another reason to not like round robin as much; next in line effect. People have diminished recall of words of others who spoke immediately before or after them. If A, B, and C are standing next to each other then B won't listen to A because B is mentally getting ready to speak next. A won't retain what B said because A is likely to be still processing the feedback (s)he just got, and analyzing if (s)he shared all what (s)he had to.

That is the reason I prefer the story-time format. In the story-time pattern, each story on the board is discussed daily for its progress. Visit each story on the board in the order of priority. If it is a pairing culture then the pair speaks up. Otherwise it's the individuals.

What other patterns have you found useful?

[Image taken from:]

The Lost Sailors

One of the biggest differences between good sailors and lost sailors is their ability to read the compass, and react.

Agile coaches wonder why most managers don't get it. Is it illiteracy of the compass or the lack of discipline to look at it? 

On a bright sunny day I was playing with my toddler son. It was insightful. He'd wait for the ball with his hands on the ground, and the ball would pass by within inches of him. He'd then look back at it speeding away, surprised. After about 15 mins of play that behavior changed. He still waited in the catching position, but started to visually track the ball as it passed by him almost until it stopped. On the other hand 5-6 year old kids in the group not only visually tracked the ball, but also reoriented themselves real-time.

There's a strong analogy, in my mind, between the above scenario and what I notice in a lot of managers. We know our stuff, but fail to play it out. We can read the compass but are not able to react to it.

There's an intermediate stage between reading and reacting to the compass. Fear of a panic attack. The Quartermaster of the Deck notices the ship heading in the wrong direction. Helmsman finds out. But, (s)he insist not to share that with the Officer of the Deck. Fear of potential panic on the ship or Captain's wrath cripples them both. The situation only gets worse from there on as the perception of panic becomes higher with the passage of time. Sounds familiar?

This last scenario is quite potent. In it, it carries the power to catapult you (or an organization) from the ranks of sailors to that of explorers. The confidence in being able to digest (bad) news and course-correct is what, very likely, nudged the explores to discover new lands.

[Image taken from:]

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:]

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:]

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.


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.


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


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


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


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


"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:]

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:]

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:

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:]

A Gift of Obamacare Rollout

Like many technologists, I too delivered my share of smirks and sarcasms at the failure of the 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:

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: ]

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:]

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:

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:]

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: ]

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: ]