I still continue to be amazed (thought ‘shocked’ and ‘dumbfounded’ will be more appropriate words here) by the amount of dogma in agile circles. Do this! Don’t do this! Wasn’t agile meant to liberate us from the tyrannies of the so-called big monolithic non-agile white elephant processes, and create a more nimble mindset, flexible culture and adaptive process framework where ‘inspect and adapt’ was valued more than ‘dogma and prescription’? I sometimes think the poor old waterfall, for whatever it was worth (and I do believe it was worth a lot more than most people are willing to give it credit for!), was more open-ended and invited innovation simply because it was not perfect enough, and was very clumsily built for a rainy day, and depending on how sunny your day was, you were allowed (rather encouraged and expected) to pack only that much ration that you felt might be needed for the jungle trip.

For example -

  • You could have had any team size.
  • You could choose to locate your team members anywhere they wanted to be.
  • You could tailor your process in whatever way that made sense for you.
  • You could choose to slice your functionality in any which ways that made sense.
  • You could stagger the releases in whichever way you felt offered better yield.
  • and so on.

In several ways, such innovation required one to master the nuances of software development. And for those who would apportion reasons behind failure of such project on the method, my response would be – when there is so much flexibility in the system, why blame the system for being so ‘rigid’?

I have experimented more with waterfall methods in my career than with agile methods (which also I continue to do, much to purists chagrin :)), and here’s a small list of key exeriments that I remember doing – something that gave me immense joys because I had the liberty to try out stuff to see if that solved my problems better –

  • In 1995, when we realized that we are in a technologically evolving and complex domain (Asynchronous Transfer Mode switches), we didn’t build castles in air with the ‘non-negotiable’ waterfall-based product development process that the company had mandated, but decided to build an early prototype what would allow us to validate some key assumptions about our architecture. Yes, the company’s process didn’t support us, but yes, we broke the rules :).
  • In 1997, when we ‘discovered’ that standard waterfall won’t help us speed up the development cycle while we wait for the previous phase to complete, we didn’t blame the process for it, we simply ‘invented’ sashimi model and kept going.
  • In 1998, when conventional estimations didn’t work out in a domain that was completely new and unknown to us (digital set top boxes), I was not obligated to follow some obsolete standard process (though we were a CMM Level 5 company), but encouraged to try out estimations using complexity weights using methods like PROBE to mitigate the risks in estimations.
  • In the same project in 1998, when the project’s technology was new to us, I was able to home-brew and define a process with five increments that recognized the experimental nature of the problem we were solving and the learning curve of the team rather than sticking to a one-size single-release process.
  • During 2000 to 2003, I liberally experimented with waterfall methods to build teams that delivered large products in telecom and datacom domains with high success rates. At one time, I had 190+ engineers on a single product in my team organized around 14 parallel projects running on a common timeline and delivered on-time product in complex 3G Softswitch space. Yes, all in waterfall :). At that time, we were ranked last in global market. Today that company is global leader in that space, and I can proudly say some of our efforts were behind that turnaround.
  • In 2004-05, I experimented with our conventional enterprise service pack release model by liberally adding the weekly cadence from Gilb’s Evo process to create a weekly delivery model, and by accidentally stumbling on the concept of limiting work in progress to create one of the world’s first kanban implementations without knowing kanban – to be fair, it didn’t exist at that time – all without any prescriptions but just with a liberal dose of enthusiasm and undying spirit of experimentation.
  • …and the journey continues.

And what has been my take on the agile theory and practice? Not so open to experimentation or innovation. Sad, but true. Take some simple things for a start:

  • Agile methods recommend a small team size. That’s good common sense, and backed by scientific studies and acendotal data from ages, and is a generally good advise. What’s no so good is then we insist that agile teams can only be in a certain numerical range, and any team size more than that is blasphemy! In fact, my extreme view is that the best team size is what you have right now and not an ideal something from the literature, howsomuch backed by data that might be! In several ways, it is same as the ideal body weight – most of us will never have it, but what we have ‘here and now’ is the most important number to start with. So, why waste time over building an ideal team and lose all precious learning opportunities in that process? If my team has a true ‘inspect and adapt’ DNA, irrespective of where I start, I will get to the finish line. Somehow. Isn’t’ that more important and being truly agile rather than finding the perfect take-off point?
  • Take user stories. The notion of moving to user stories makes lot of sense give the constant pace of world around us. PRDs could never cope up with documenting such copious amount of details – and if anything, they would only succeed in documenting history of what customer wanted a year back! Now on one end we want our user stories to be ‘negotiable’ (from the acronym INVEST) so that we can create meaningful conversations between product owner and the development team. This again makes a lot of sense in an imperfect world where documenting every single requirement with its myriad corner conditions might be practically impossible, and has diminishing rewards beyond a point. So, if we can create a quick and cheap way to get started and have both, the process and the humility to listen to development team come up with more questions and options, then this premise holds very high promise. However, as a philosophy, something that is non-negotiable might not be so good in the same spectrum. For example, the Scrum process that we want them to follow must be non-negotiable. Why is that? If Fosbury had listened to the best way of high jumping, he might have never broken the proverbial sound barrier in high jumping.

Hey…what happened to the big promise of team being allowed to figure out its own ways and means? Once we ‘tell’ them, shouldn’t we step aside and let the team find its true north? Do I hear you mention ‘Shu-Ha-Ri’ thingy? Do yourself a favor – go and find a student (even better – try it on a second-grader) and then keep telling him/her that they are still a ‘Shu’ and hence must obediently listen to whatever you are telling them. They are supposed to follow your instructions to the hilt and not even think of wavering a bit. Good. Now take a deep look at their reaction. Count yourself lucky if they choose to ignore you and decide to move on, for there are far more violent ways they could have chosen to respond to such dogmas. In short – this is not the time and age for dogmas. Kingdoms, Colonies and Communism are all long dead. Accept it and change your own coaching methods, if you want to be counted.

To me, agile is a state of mind that tells me how to proceed in an imperfect world. Not to somehow make a ‘perfect’ world and then proceed. To me, a successful agile implementation is not about finding the perfect team + perfect process + perfect customer + perfect timeboxing + perfect sprint planning + perfect retrospectives + perfect product owner + perfect scrummaster + perfect

When does experience get ossified into dogma?

When does experience get ossified into dogma?

engineering practices + many more perfections = perfect landing. To me, a successful agile means starting with team that you have at hand, with the process that you have under the constraints you have, with the requirements that you have on a best effort basis and a many such real-world realities that works under a mindset of taking things one after other and improving the journey with the hope to get to the destination better than without such effort. Remember, we are being melioristic, not idealistic. We are being adaptive, not laying down pre-conditions for take-off. And in that pursuit, the most important guide for decision-making is our own judgment. Everything else is just that – everything else, and while it might work at times, it might not work at other times. So, like the Swiss Army manual that says – when there is a gap between map and the terrain, trust the terrain, go ahead boldly and experiment. In the worst case, you will lose some time and dollars, but if your DNA is built on the premise of self-improvement, you will quickly recover and eventually find your own path. If you are not able to ‘find’ it, you will ‘build’ it. Even better…

In many ways, there were no royal guards so zealously guarding waterfall model that made it sexy enough to be experimented with and experimented upon. On that same scale of flexibility, I don’t find agile methods sexy enough. It appears to be a lot like dogma on steroids. And I think that’s a serious problem.

Is your agile still a lot like dogma on steroids?

  • S M Kripanidhi

    So very well said, Tathagat.

    Ask someone who is talking about Agile as to what are they trying to accomplish by “doing Agile”. They only have “motives”, they do not seem to have “goals”. If they were trying to achieve something by being agile, they would be more focussed and be able to figure out how to use agile concepts to their advantage in accomplishing their goals quickly.

    Being agile is a default start-up culture. More often than not, larger enterprises are more comfortable making a mockery of it and are unable to figure out the common sense behind agile.

    As you rightly point out, agile concepts tell you how to beat complexity, unpredictability, volatality and risks in software development, in an imperfect world. The agile strategies are very strightforward :

    1. Increase Employee Engagement: so that we are able to create an environment of trust and empowerment, so that people enjoy what they do and therefore increase their “productivity” in whatever they do. This this the theory of what is called “positive psychology” , “happiness advantage” or “flow”. It is like a “commando culture”, who are willing to risk their lives for accomplishing their goals.

    2. Accelarate Learning : while working in an imperfect world, we need to learn to build our capabilities fast, to do the right things right in a given context. We need to therefore learn to manage our learning, so that it happens quickly. Collaboration, the PDCA loop, Retrospectives and Fast Feedback are key to fast learning. This should result in a true Inspect-Adapt culture working in an imperfect world.

    3. Incremental Innovation: Accelerated learning should result in enhanced capability that enables us to cause continuous improvements to the ways we do what we do, by learning and discovering newer and better ways to do the right things right the first time.

    4. Increase Speed: All the above enables us to increase our speed of continuous delivery of value to our customers, thereby increasing the ROI of our work. We also on a continuous basis learn to identify and elimate waste to prevent us from slowing down.

    As far as Agile is concerned, if we see the above results in a project endevour, they would surely be harnessing agile concepts to their advantage. If not they would be doing Agile as a ritual, a dogma process, without knowing why they do, what they do, the way they do it.
    That’s the unfortunate part of doing Agile.

    • http://managewell.net Tathagat Varma

      Thanks Kripa (had been meaning to reply to you for over a month!). To me agile was supposed to be a philosophy but had ended up being a religion. And we all know once we have a religion, what comes next…

      • S M Kripanidhi

        That is so ture. What should we do to maintain the integrity of Agile as a philosophy so people can benefit from it ? and what can we do to prevent Agile from becoming an other dogma or ritual as in a cermony moderated by a religious priest ?

        • http://managewell.net Tathagat Varma

          From my interactions with practitioners, the reality is that no one really cares about the ‘pure agile’ theory. Everyone is freely blending agile methods with whatever works for them (and even things that don’t work!). I think this is a great news – and perhaps the only real hope. Reality in the trenches will always trump vision hiding inside powerpoint decks. So, over a period of time, I think the forces of free market and Darwin will collectively ensure that only the ideas that are perceived as pragmatic, efficient and effective will go on to evolve in the long run…

  • Pingback: In the News: 2013-08-18 | Klaus' Korner

  • http://kurthaeusler.wordpress.com Kurt Häusler

    What specifically is this in response to? It could be you have a legitimate complaint about genuine dogma, but without providing solid examples it sounds more like a rant against agile because it requires discipline and isn’t simply the free for all that some people think.

    • http://managewell.net Tathagat Varma

      Hi Kurt – this blog post is my take on the prevailing mindset that I am (steadily if not increasingly) seeing in the agile training, coaching and thought leadership community at large. Instead of helping people how to open up our minds and discover newer ways to solve problems, we are telling them that agile as we know today is pretty much the done deal, and if you ‘deviate’ from expert advise, you are committing the biggest sacrilege of our times! Discipline is important, but it can’t come at the cost of curbing my freedom to experiment and think outside the established line of thought – how so much flawed and immature my ideas might be (didn’t we all start like that some day?). Like I wrote in the blog, my view of agile is the problem-solving approach that helps me get started irrespective of wherever I am, rather than putting pre-conditions for success by creating a utopian make-believe world, which I might never have.

      I would rather have an ounce of free thinking than a gallon of canned thinking…

%d bloggers like this: