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?
Similar to the 1992 US presidential race where Bill Clinton successfully defeated George H.W. Bush by creating the catchy slogan (“It’s the economy, stupid!”) to focus back on the economy, one could hold a similar sentiment with Scrum in that the majority of the focus is on the ScrumMaster, wherein at least from my perspective, all evidence seems to indicate that it’s the Product Owner who should be the focus.
In other words, it’s the Product Owner, stupid!
The reason for such a sentiment is the fact that the Product Owner is a key stakeholder of the project who’s vision of what’s to be developed and built correspond directly to what the Scrum team actually implements. This is the main person that drives the prioritization of the product backlog list.
But more important, this individual needs to have extremely strong business savvy skills and be able to communicate that in a manner that can be built to preciseness so as to reach a state of “done” at the end of a Sprint. Sure the ScrumMaster facilitates this and that role is important, but if the vision doesn’t match the end product, it’s really the Product Owner who’s accountable for this.
In my own experience and in discussion with Agile PM’s, the lack of having a true Product Owner is what usually causes Scrum projects to go south. Often times they will throw some business analyst type person into this role who has no real understanding of the product scope and is the person who is supposed to act as an intermediary to get requirements from a Product Owner type person in the first place!
So don’t be stupid. Make sure you get a real Product Owner, though I know it can be pretty darn difficult.
In this Wall Street Journal article, it points out the latest initiative of the retail behemoth Walmart in their attempt at being more “Agile”. Agile that is in the traditional sense of applying this to their giant IT division for software development that is spread over 130 “Agile” teams.
First of all, I don’t know what the size of the teams are, but if there’s 130 of them and they adopt the principle of keeping Agile teams at a reasonable size, that means a team is comprised of at least 5 people. Since it’s Walmart, let’s assume it could be a team of 10. That means there are around 1,300 groups of people all supposedly Agile. I wonder if Agile was used to deploy and mobile them? That’s definitely a Walmart sized group of Agile teams for sure!
Anyway, as the article further states:
Over the past two years, parts of Wal-Mart Stores Inc. have begun to embrace a methodology known as Agile for rapid and flexible software development. Still, the methodology, now gaining ground beyond its core base of technology company practitioners, can’t be applied to everything, said a Wal-Mart employee at a conference in Silicon Valley...
At least in Wal-Mart’s e-commerce businesses, using the Agile approach was a response to the increasing complexity and dynamic market conditions that require solutions to be delivered faster, according to a 2013 report. Wal-Mart competitor Amazon.com Inc. began using a particular Agile methodology called Scrum nearly a decade ago. The conventional approach to building software, known as the waterfall method, often takes companies a year or more to deliver a complete feature-packed product.
“I am a firm believer that Agile is just one tool,” said Mark Tallman, who has worked in project management at Wal-Mart, speaking at the Strategic Execution Conference in Santa Clara. Mr. Tallman, who now works in disaster recovery at Wal-Mart, said that an Agile approach doesn’t work very well for building data centers. “There are things that have to be done waterfall,” he added.
So the article doesn’t go into if Walmart has witnessed any tangible evidence of faster delivery of their software projects, but it does seem as though initially they looked at the “Agile methodology” (why do people keep on perpetuating the idea that Agile is a methodology?) as a “one size fit all” approach and did not think more strategically where it could be used best, how to introduce it iteratively and incrementally (so as to be more Agile, ironically) and especially how this would impact a monolithic culture that’s trying to shoehorn a modular method that needs a modular corporate culture to thrive.
This outlines what I wrote about previously, in that as a movement such as Agile grows in popularity, so does the rigidity with which it is applied. People look to incorporate tools and techniques quickly without the deeper thought as to what the underlying principles are and how to really use that to effect change.
It’s about creating a culture of agility not just “doing” Agile!
According to a study by Edureka and Global Knowledge, PMs with the PMI-ACP are making on average $123,000 USD which is about 15% higher than those with a PMP and 28% higher than those without any PM certifications.
Of course, the sample size is pretty small if you look at how many people responded to the Global Knowledge survey, you'll notice that the respondents were quite small in comparison with the overall respondents:
In addition, the Edureka (what a funny name) is a provider of PMI-ACP preparation courses, so both these studies violate all the criteria for good surveying such as proper sample size and in Edureka’s case, no real evidence to back their claims.
In my completely anecdotal experience, I have seen practically no adoption of the PMI-ACP cert in any organizations in the So California area and Los Angeles in particular. Most organization don’t know what it is and really don’t care.
This indicates to me that there’s still a lot of PM certification mania being bandied about by certification providers and people probably getting duped into thinking getting one will land them their dream PM job.
I took the exam and found it to be a good way to review a broad overview of Agile tools, techniques and practices and to see which areas I may need to learn about more. The credential validates that I did some study and have some discrete multiple choice based knowledge of Agile and if that’s how you approach this, then I think you have the right expectations.
But if you think it will get you that awesome job as Agile PM guru or that it will increase you pay by up to 30%, then I think you need a reality check! As they say, “Caveat Emptor” or buyer beware!
I can't help but to notice that the more popular and commonplace Agile has become, that the more rigid it is becoming. The whole point of this movement and their popular progeny such as Scrum, XP, etc. was to overcome the rigidity of traditional project management and software development methods. Unfortunately, its popularity and explosive growth has kind of been its own enemy in that now you have competing bodies of knowledge, terms and definitions and stringent certification programs all claiming to train you in the “proper” methods and practices of Agile.
Someday Agile as we know it will disappear, but the need for “agility” will never go out of date. In fact it is the opposite, in that there will be a need for hyper-agility! Nevertheless, let’s not forget that whatever you want to call it (I like the idea of “Anti-FrAgility” as the next evolution myself) don’t forgot the need for agility.