Pathology is a strong word and a bold one to use to deliver the idea I intend to. An interview candidate at ThoughtWorks at the time pointed it out to me during our one on one. He said, "Do you really use that word in front of your clients?" The idea behind the use of this word is to focus on the emotional and behavioral challenges that are frequently observable during Agile enablements and transformations. For lack of a better word, it is 'pathology'. Although pathology indicates existence of a science behind its eradication, I consider it an art. A presentation on the topic is available at the end of this post..
Exhibited by individuals:
- ScrumMasters don't speak in Daily Scrum or Standup: In a few of the coaching engagements I encountered ScrumMasters who didn't give any insights into what they were doing for almost a week at a stretch. In one instance the ScrumMaster said to me, "I am a ScrumMaster, I am not supposed to speak in a Standup; it's a Team's meeting".
- Lone Wolf Syndrome (anti-pairing): Pairing comes across as an invading concept to many. It seems to threaten some and slow down others (even though only for a short while). Egos are hurt and disagreements on implementations arise. In a short duration experiments with pair programming evokes all the reasons why most software developers are lone wolves; there's too much talking, difficult questions are asked about the design decisions, peer pressure to delivery something everyday is sustained and flexibility during the work hours to indulge in non-programming work is substantially reduced. Most importantly, the glory of having delivered a piece of code single-handed and a chance to be a hero doesn't exist any more. All these are good reasons that further fuel the lone wolves.
- Ineffective neuro-linguistic tendencies: How many times have you encountered someone in a meeting was asked an open ended question that triggered a rambling from the other side? How frustrated have you been when a key decision maker asked a closed question and did not assess the root cause of a problem? Have you witnessed a meeting which dragged on just because no one asked reflective questions? Have you ever read user stories or requirements that are sprinkled with nominalizations or generalizations or unspecified nouns and verbs? I have, over and over again.
- Emotional block to learning new concepts (e.g. metrics, estimation scale): Some external influence has set an expectation that there is a test or a quiz following the introduction of this new concept. To some it is disappointing that there is usually none. To others it's the anxiety of using a new approach in their routine work and an expectation to succeed with it. There's also a third category where some reject the notion of a new ideas because they don't see a problem with whatever they currently use or simply latch on to old ideas a little too tightly.
- Fear of Analytics and Usage Statistics: This is easily to spot in the Product Owner (PO) group. It is not uncommon to find requests for features that are a 'pie in the sky' with few indicators that justify the demand. Quite often it is not difficult to access these statistics, but they are deliberately hidden by POs. There's a fear of embarrassment, "How would I look in the face of poor usage statistics of the features that I fought for tooth and nail a few releases ago?" or, "I don't want IT to question my PO skills with software usage statistics".
- Broken Windows: I use this term metaphorically for an imagery. Broken windows theory suggests that if problems are not fixed as they occur or corners are cut and not corrected they will become examples for others and further deterioration will ensue. In software development this may mean writing poor quality of unit tests or avoiding them or bypassing them during build development. It may mean poor quality of narratives or constant rework for developers if critical feedback loops are short circuited. Unfortunately, all of these examples are real-life that plagued their teams.
- Acceptance of Technical Debt: Technical Debt is an acceptable notion on Agile teams. The slope, however, gets slippery when technical debt is ignored. In the race to get releases out on a predetermined schedule or to now lower the throughput of software to production teams seldom take a break to get rid of this debt or even refactor.
- Release planning without Analysts: The ivory tower thinking of most program managers and project managers come to visibility on topics related to project finances and resource management. I always wondered where it all started and zeroed in on release planning. Who contributed to the software release map? It doesn't surprise me anymore to know that quality and business analysts were not involved. PM ran the show there with a few high-level stakeholders and agreed to a fictitious timeline with some events sprinkled over it under pressure from authorities up top.
- Squirrel Agile: Imagine a squirrel crossing a street. Imagine undergoing an Agile adoption. There are, in some instances, similar patterns - let's do this new thing, keep doing it, don't do it, OK do it, NO get back to what we did earlier. Halfhearted, uncertain, knee-jerk driven, fear instigated decisions that lead to a hodge-podge environment are too common. The stink over the mess is a proud declaration by some managers that they have their own flavor of Agile. That's a problem. Command and control tendencies, assignment of resources to multiple teams, setting up teams that are function specific (analysis, development, and testing), tracking capacity utilized are often the the first signs of squirrel agile.
- ScrumMaster Certification: The newest emerging trend is to hire certified scrum masters and professionals. There's nothing wrong with it except that most of the Agilists that I have worked with and talked to don't care for these certifications. On the flip side, a lot of certified scrum masters haven't even once been on Agile projects. These certifications, in my opinion, are dangerous; they create an illusion of experiential knowledge and arm the attendees (that's what most so called trainees are) with enough vocabulary to make them a risk. Yes, risky, because the traditional mindset is prevalent and practices are rampant under the guise of Agile.
- Seeking an Agile Playbook/Cookbook/Rulebook: As an Agile Coach one of the requests often made to me is, "Can you leave us with an Agile Cookbook?" A steadfast belief that Agility will flourish if there's an Agile operator's manual warrants a discussion. But believing that Agile is esoteric and a rulebook as opposed to actual practice will help adopt and sustain Agile is an untenable notion.
- Agile without being Agile: I once consulted to a client that had a regimented release calendar - two releases a year. Their entire technical, political, and bureaucratic infrastructure was designed and tuned to serve these two releases. The discouragement and hindrance in this environment was that all but two of the stakeholders perceived a great threat in exploring ways to redesign or tweak the processes. Even the optics of trying to do so, to some, was a risk too big to take in the institutionalized environment where adherence to these processes was rewarded.
- Strong Identity (e.g. "We are a metrics company."): Who doesn't love metrics and who doesn't have a strong identity? Some enterprises have a strong folklore culture that propagates such fanciful identities. Management gurus may argue that these are must have characteristics to build a successful enterprise. I agree! Let them, however, not become roadblocks to change. The problem occurs when strong identities become roadblocks to pragmatic and rational change of mindset that Agile predominantly is. Metrics is a good subject. Some organizations and project managers are obsessed with them. Too much time is spent on tracking indicators that really don't indicate much. If someone is trying to plot a polynomial regression graph for a burn-up trend projection when a linear regression usually suffices, you know you have a problem at hand.
- Nominal Product Owner: Recently I was working with a company that is designing a new product and has an aggressive schedule. Some of there people are new to Agile, including the President of the company. As we were presenting our findings and plans to the team the President interjected and asked us a lot of questions about the level of details we came up with, our confidence in what we found out and understanding the domain and the intent of the product, roadmap and our ability to deliver on time. Those were all excellent questions and we are glad that he asked them. He then switched his attention to the product owner and asked her many questions. Those included questions around her comfort and confidence in working with us, product boundaries, depth of product exploration exercise that we did, etc. Gist of the story; the PO was the anchor in the situation. She was entrusted with a market leading product and the responsibility to get it out of the door in time. Period. That incidence made me realize how underpowered and untrusted some of the other POs were in their organizations when I worked with them. They were titular Product Owners.
Image taken from: http://farm1.static.flickr.com/191/480869012_f1493aceb2.jpg