Since many readers of this site come from an IT background, it is probably safe to assume that many graduated with a computer science degree and/or taken computer programming classes. One big topic in that field is how to loop through a sequence of data points continuously that either terminates or branches in another direction based on a selection criterion. One way to do that is iteratively and another is recursively.
Both methods come out with the same solution, but the means in which they do so is quite different. When you iterate, you set the number of loops and circulate through them until the set number is exhausted. When you recursively loop through it, you set a base condition and have the functional call itself until it reaches the base condition and terminates. This is not a computer science post, so I won’t dive into details or nuances of these approaches, but for the sake of this post in terms of project management, Agile as you all know is focused on iterations but what about recursion?
While there’s a clear dichotomy about iterating though a loop as opposed to recursively circulating through it in computer science, I will argue that how we plan and execute an Agile iteration, though on paper looks iterative, is entirely recursive from the cognitive perspective. We do not think in nice linear sequential iterations, but rather recursively loop through thoughts within thoughts were past and present meld through memory to make assertion about the future.
No better example of this than a passage from Marcel Proust’s incredible novel “À la recherche du temps perdu” (English: “In Search of Lost Time”) in the very first volume titled “Sway’s Way” where the protagonist of the story tastes a piece of madeleine cookie dipped in tea:
No sooner had the warm liquid mixed with the crumbs touched my palate than a shudder ran through me and I stopped, intent upon the extraordinary thing that was happening to me. An exquisite pleasure had invaded my senses, something isolated, detached, with no suggestion of its origin. And at once the vicissitudes of life had become indifferent to me, its disasters innocuous, its brevity illusory – this new sensation having had on me the effect which love has of filling me with a precious essence; or rather this essence was not in me it was me. ... Whence did it come? What did it mean? How could I seize and apprehend it? ... And suddenly the memory revealed itself. The taste was that of the little piece of madeleine which on Sunday mornings at Combray (because on those mornings I did not go out before mass), when I went to say good morning to her in her bedroom, my aunt Léonie used to give me, dipping it first in her own cup of tea or tisane. The sight of the little madeleine had recalled nothing to my mind before I tasted it. And all from my cup of tea.
There can be and has been multiple ways to interpret this from a deep philosophical, psychological and literary perspective, but for my purpose this passage highlights the fluidic, dynamic and recursive nature of how human’s loop through thoughts recursively that is juxtaposed from past episodic events to formulate in present time our future direction. Past, present and future move as one in a complex but orchestrated melody of consonant cognitions that allow us to plan our actions.
I think this is why our project plans never quite adhere to the plans in our thoughts because they are static and permanent, whereas life and thoughts are dynamic and constantly in flux. This is profound and paradoxical yet intriguing… something to ponder and explore again (and again).
What are your thoughts? More importantly, did you arrive at them sequentially, iteratively or recursively?
My forecast for 2015 is that Agile, or rather the term “Agile” as we all know it, starts to fade away. The reason isn’t so much that it has not met up to its promises, but rather that it becomes redundant to add a moniker to a term that should already lie at the heart of how we all do projects and business in general. It is like saying we should do projects better in the future, but of course we should be them better because the converse is to not do them better and lose our jobs, businesses and organizations!
But this is not to say that individuals and organizations will not need more training, education and knowledge of Agile, rather the contrary, because one could argue that it is redundant and even contradictory to call “common sense” common, since if it were already so common why would we even need to identify it? Shouldn’t it already be so common that it becomes redundant to tell people to use it? I think that is because despite sentiment of the commonality of certain common sense ideas, very few people follow them commonly! Many people seem to do the contrary and are why for example, the self-help genre with all its books, seminars, workshops, etc. still prevail. Likewise, all the books, seminars and workshops for Agile will prevail.
I guess what I’m really saying is that the hype around Agile starts to fade away if it hasn’t already. But that’s a good thing since it now becomes part of the genre for which anybody involved in project management should know about.
So with that I conclude my year end forecast and I wish you all a prosperous 2015. I look forward to more interesting discussion on agility and beyond!
Glassdoor.com has just released its report on the 50 best places to work in the US (and pretty much abroad since most companies these days are global) and not surprisingly, Google came out on top. It sound from the report that this is due to all the perks employees receive, but what was pretty interesting was an article by Insider Monkey that outlines how Google utilizes an Agile form of HR management:
Glassdoor’s CEO, Robert Hohman talked about what makes Google the best in business in this category... “[...] What Google Inc (NASDAQ:GOOGL) has done is that they have sort of borrowed the agile development methodology and applied it to HR. They are interviewing their employees frequently and they are trying to respond very rapidly to what they need, and what they heard Googlars needed as the employee base ages is more support in work-life balance [...],” said Hohman.
This greater support for employees that Hohman talked about was found lacking in Apple Inc. (NASDAQ:AAPL) and Facebook Inc (NASDAQ:FB) at least to the extent that Google Inc (NASDAQ:GOOGL) showed commitment for that cause. The measures involving facilitating its workforce included increased maternity leave, introduction of maternity leave, and revamped onsite day care, according to Hohman.
Although Google has made it to the list seven times in a row, this is the first time that the tech giant has secured the number 1 spot. Facebook Inc (NASDAQ:FB) dropped from the fifth position to number thirteen this year. Hohman mentioned that as the company is growing in size it is becoming harder for the company’s management to address the issues plaguing its staff.
I wouldn’t get too carried away by the Agile metaphor, as I don’t think they deployed Scrum on their HR practices (or who knows?), but rather they maintained agility with respect to how they monitored the employee satisfaction and changed quickly when things worked and didn’t work. They are known for their ability to experiment constantly, measuring results and changing rapidly when needed. This is a great recipe for any company to follow. As I mentioned before, it’s more about agility than being Agile.
There’s no doubt that Agile has been beneficial to the development of software and industries beyond, but one thing I have noticed is that people who get deep into it can have a tendency to oversimplify both the problem and the solution to which they are looking to apply Agile. Just look at how complex many software systems are these days. Many have millions if not billions of lines of code all strung together and these software applications interact with multiple other complex software applications often in real-time. To facilitate this requires large, interconnected hardware infrastructure and storage of data that also requires you keep track of security, governance and compliance with rules, regulations and policies both private and public.
Can such complexity really be reduced down to simple user stories or prioritized backlog list then implemented in short iterative burst sessions? Only once you have thought through and developed a solid object oriented design that incorporates things like patterns, re-useable software, and modular components… this requires you go through a process of structured and system oriented thinking that guess what, means you do some upfront design and requirements gathering! Only then can you come up with well planned and defined iterations that will result in working software and software that you know will be modular and maintainable, rather than something that just “works”.
Do you think many who do Agile have a tendency to oversimplify? Agree or not?
The second doctrine of Agile is having “working software over comprehensive documentation” which drives much of the obsession with being “done” in the Agile community. In other words, the whole reason for doing Agile is so that you have something workable at the end of each iteration. This makes perfect sense as the justification for breaking large chunks of work into smaller pieces is so that you can get a better handle on it, build subsequent pieces upon previously built items and change rapidly if needed. This should foster better creativity and to respond the changes and feedback quicker.
Unfortunately, this doesn’t seem to happen much in the real world as even one of the co-founders of the movement, Jeff Sutherland discusses in the Q&A on the launch of his new book “Scrum: The Art of Doing Twice the Work in Half the Time” that was just recently published, that this is often not the case:
Recently I visited 12 of the largest and most successful companies in Silicon Valley on a book tour. They average number of Scrum teams in these companies was more than 200, many much larger than that. I was impressed at the scale at which Scrum is being implemented...
Unfortunately, over 80% of these teams do not have tested, working software at the end of a sprint. This creates huge delays and many problems. Scrum becomes slow, hard, and painful. It is a gross violation of the second value in the Agile Manifesto ["Working software over comprehensive documentation"]. Therefore, it is “Bad Agile.” The Product Owners and customers cannot count on anything except being late.
I want to communicate to all teams, that for Scrum to be fast, easy, and fun as at the Ashram college, you must have working product at the end of the sprint.
My feeling is that it is because of the obsession with being “done” that causes this continuous dysfunction since it compounds the problem in an opposite direction. Let me clarify what I mean: As was just mentioned, the ideal situation is to have a working deliverable at the end of each iteration (or “Sprint” in Scrum lingo) which would drive the improvement of subsequent iterations into a form of continuous improvement we all assumingly acknowledge. This would create that whole idea of teams that gel and self-organize and at some point the customer would get what they want and stop.
But let’s look at this from an opposite direction: If we take Jeff Sutherland’s metric that 80% do not achieve the condition of being “done” at an iteration's end, it stands to reason that this problem would have the opposite effect and each failed iteration would cause more failed iterations into a detrimental cycle of continuous dysfunction. Though the ideal situation is to allow failures, my feeling is that the majority of executive management bought into the idea of Agile to avoid failures in the first place so that no failures are tolerated at all, even though failures can sometimes lead to breakthroughs. This situation would be made worse if you adopted Agile in an environment that is really not meant for it: e.g., if it was introduced into a large compartmentalized organization (note that it was metioned in the Sutherland quote that Scrum teams number 200 and above!).
So these Agile teams that fail to produce a working deliverable work even harder and as anyone knows, they would inevitably hit a point of diminishing returns and end up like that famous quote on insanity “where you do the same thing over and over again expecting a different result!” And if Silicon Valley startups are failing 80% of the time, the non-startups which mean regular companies not doing cutting edge software and technology, probably have a fail rate in the upper 90th percentile. Yikes, than that means there’s some serious dysfunction out there!
So what’s the solution? Maybe be less rigid about being “done”, but than that kind of defeats the whole agility thing. Perhaps a bit more planning to make sure the iterations produce something done? But do this too much and you end up with waterfall done in prolonged chunks. Maybe waterfall is better since you fail big and start over again. It’s the proverbial choice of whether you want to die instantly but painfully, or by being poked a thousand times which is not as painful but agonizingly prolonged.
What do you think? What's been your solution?