I Think Therefore I Am and Other Terrible Anti-Agile Ideas

I was listening to a podcast this morning that was talking about the concept of original error, which is the idea of tracing a philosophical belief back to its origin.  The purpose, then, is to build the case against that thing that started all of the problems in the first place.  I will not bore you with all of the psychological and philosophical stuff TOO much but this will need some context.  At a point in our history, formally called “The Enlightenment” (which the more I study the more I think it wasn’t too enlightening), a guy named Rene Descartes had WAY too much weed and started to contemplate his own existence.  As many people who disregard any kind of Providence do, all focus settled back onto them – the individual – to answer their own existence questions.  In a very famous quote (which some argue was never found in his books), he stated “cogito ergo sum” which, when translated from Latin, says “I think therefore I am.”  This sounds all normal to us now (even though we don’t quite understand it) but it was actually a full rejection of reality.  Reality states that I think because I am, or more properly “I am, therefore I think;” so Descartes’ quote could be considered “Inverted Reality.”

Now, I know what you are thinking – “when the heck are you going to get to the ra, ra, agile, ra, ra part?”  Well, now I guess.  Just like Descartes flipped the concept of reality on its head, many organizations going through an agile transformation are accepting and creating their own inverted reality.  Let me give you a few examples:

Create a team and then tell that team they are self-organizing and self-managing

I understand that in most large organizations, creation of teams cannot be like playing a game of school yard dodge ball, however, the enterprise cannot pick the team, put a manager over that team, and then tell the team what they are going to work on but fully expect a cutting edge implementation of innovation and blazing speed of delivery.  Recently, a program I was working with was told they were going to go agile – in the middle of working on releasing a 6 month project.  In addition, the manager was told to split the group into two teams, equally dividing ability and tenure down the middle.  One of the problems was that this was not as easy as it sounded.  This concept “sounded” like it made sense, but it was actually “inverted reality” and left way too many variables out of the equation – how the individuals work together, their work ethic, cross-functional readiness, exposure to technologies, influence, etc.  It also was counterproductive because there was actually three different functional bodies of work that the program was going to be working on.  While I don’t suggest that a team can’t work on different features within a product, for this team, it should have been left up to the team(s) to figure out if two or three teams are most effective.  When we start out with implementing agile in a waterfall method (big up-front requirements, design, etc.) I believe we are sending the wrong message about agile reality.

Using velocity as a KPI (Key Performance Indicator)

First, I hate the acronym KPI.  I once interviewed with a company that spoke in industry-specific acronyms and they kept throwing them out at me, to which I would have to ask them to define.  Toward the end of the interview, one of the project managers asked, “what do you think the most important KPIs are?”  By this time, I was not thinking standards, but industry specific.  This poor guy’s chin about dropped when I asked what a “KPI” was. . .  Anyway, agile teams in infancy (more on this in another post), can be fragile – especially those that are transitioning away from more traditional command and control ways of working.  They are already leery of anything that smells like a metric that can be used to track failure (that would be a good blog too – “How not to track failure”) and so velocity begins to worry them.  It takes some coaching to reaffirm that velocity is not comparative across teams, that it is a planning tool, etc.  With all that being said, leadership must fight the instinct to see a metric and use it to measure the team’s quality.  If the only metric that can found to tout the value of an agile team is velocity, then something is wrong.  But if we are using velocity to show team failure then this, again, is an inverted reality.  It can be used to show team health or as a starting point to talk about impediments, but it is just that – a starting point for discussion – not the end-all, be-all indicator.

Only using new teams for agile transformations

On past engagements and with some individuals, I have heard it said that they will only implement agile (another inverted reality statement, if you ask me) on new teams; leaving the existing teams to stay with traditional methods.  While this is easier, does it address the problems or organizational impediments within an organization?  Are we working toward a transformation for business improvement or to be able to put another notch on our proverbial resume belt?  Several years ago, when the War in Iraq was starting hot and heavy, I heard a politician from Poland remark strong backing for the effort.  When questioned about how they could feel this way, the rebuttal went something like this – “We, in Poland, know what it means to be under the strong-arm of a regime and now that we have tasted freedom, we will defend it.”  Now, please don’t quote me on the exact language, but the sentiment was that they valued their freedom more because of their past experiences.  Also, I am not likening waterfall to communism so seriously don’t reply about that! 🙂  However, the point remains that teams which have struggled with failing project after failing project or have had to deal with “black box syndrome” and then have an active product owner generally don’t want to go back.  They become your greatest agile evangelists.  Only focusing on new teams does not improve your overall organization!  And it can actually create more stress in the environment.

We, as agilists, need to begin to look at the fact that because we are who we are as humans agile makes sense and fits.  This is the reality – we don’t become agile, we are agile in nature and need to have ways of working that support our ability to succeed.  And I am curious to hear what you guys think!  Let’s start a discussion!