Has Scrum outlived its usefulness? Should Scrum just go away?
| It has been some time since I've posted on this blog as I've taken a break from PM social media and am transitioning and pivoting to a new career direction (what I refer to as an "A.P.E.E." - see my profile for an explanation). After taking some time off and looking at "Agile" again, I'm not impressed. In fact, it is getting tiresome. I discuss this in the video podcast below with with Samir Penkar of The Future of Project Management site: That is not to say that the principles, methods and frameworks are bad per se (with the exception of things like SAFe, which has become an even bigger bloated mess!), but with the industry, proponents and evangelists pontificating their same old platitudes about how great it is and how it will save us from the evils of Waterfall (The original paper by Joyce published in the 1970's, who is credited with the genesis of the Waterfall method, in fact acknowledged its limitation and advocated breaking things down as requirements change and iterating through them... Agile proponents are ignorant of this and think that their way of thinking originated in the mid-90's with the so called "manifesto". What a joke!) In any event, I think "reflective" agility is what we need, so as to obtain true agility and project leadership through a process of philosophical reflection to think, learn and grow in work and for that matter, life in general. Nothing is more important than the project of one's life! I'll be posting on this topic here regularly. |
The rise of Agile’s SAFe is like a bad episode of the movie Groundhog Day
|
Unfortunately, the recent rise and popularity of the Agile SAFe (Scaled Agile Framework “for the enterprise”) makes me feel as though I’m like the Bill Murray character but without the ability to get it right but still feeling as though I’m stuck in a déjà vu like experience. But let me preface this by stating that I don’t want to diminish the hard work of the people who outlined this framework nor the “ideological” basis of it, which sounds pretty good on paper.
Yet I can’t help but feel as though this movement (and this isn’t the first proposal of scaling Agile… remember the “Scrum of Scrum” idea?) has many parallels with the traditional PMO/PPM model from the traditional community. When the traditional prescriptive-oriented model started getting a hold in the workforce and done with a modicum of success, people had the bright idea to try and scale it up so that the organization as a whole could start benefitting from doing standard PM practices. But from my own anecdotal experiences as well as studies I’ve read from PMI and various other sources, this did not really work out so well. The idea was to create project center of excellences, but instead just ended up slowing people down as they got drowned in processes, governance and standardization methodologies and documents telling them how to do everything with the possible exception of tying their shoes! But in this process heavy prescriptive model, you have a framework that could at least support projects being delivered collectively in a mediocre McDonald’s like consistent way. But let’s face it, as I’ve mentioned it on this blog some while ago, Agile is light because it assumes that your people are heavy. This means your team, project manager and some person who is acting as an ambassador for providing your well-defined and meaningful business requirements (a.k.a., the Product Onwer in Scrum lingo) are heavy duty, high skilled “can self-organize” types of people. Without kick-butt people, this whole Agile shindig will fail. And if I’m not mistaken, very few companies have a whole bunch of these types on their payroll. So the while the idea of scaling Agile is great, in practice I think it will be super freaking hard to nearly impossible. Whatever the case may be, it’s not going to stop people from trying and creating more frameworks, training programs, consulting and certifications (Is the SAFe certification like PMI’s OPM3 certification but done faster?). As Einstein once said, “insanity is doing the same thing over and over again expecting a different result!” Is this a fair assessment, or am I just being overly glib and facetious? Let me know! |
There was this great movie back in the early 90’s staring Bill Murray who plays a weatherman covering the annual Groundhog Day event (which is an odd tradition in the US wherein the emergence of a groundhog supposedly predicts when spring arrives early or not). He gets stuck in a snow storm and gets smitten by the lovely Andy MacDowell but turned down cold in the pursuit of her. Of course the most interesting thing about this move is that he gets stuck in some weird time warp and has the ability to re-live each day up to his pursuit of his love focus until he gets it right. Lots of laughter and hijinks ensue making for a highly entertaining and fun filled movie!
Marcel Proust’s recursive novel: Why the concept of iteration in Agile is shortsighted
|
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?
|
Forecast for 2015: The beginning of the end of Agile?
| 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! |
Google considered the best US company to work for due to HR agility
|
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.
|
